Entwurf einer Compliance-Architektur für Wachstum

Ein Finanzleiter sammelt an einem Freitagnachmittag immer noch aus E-Mails, Tabellen und drei verschiedenen Systemen, wer die Rabatte genehmigt hat. Das Lager verwendet seine eigene Bestandsliste, der Vertrieb eine andere, und die Rechnungsstellung erfährt erst am Montag den tatsächlichen Status einer Rücksendung. In solchen Momenten ist die Planung einer Compliance-Architektur kein ferner Auditbegriff. Es geht darum, ob das Unternehmen nachweislich, konsistent und betriebssicher arbeiten kann.

Compliance wird oft dann zum Thema, wenn eine Kunden- oder Behördenprüfung bevorsteht, neue Branchenanforderungen auftauchen oder ein Datenverarbeitungsfehler bereits unangenehme Folgen hatte. Dies kann jedoch ein zu später Ausgangspunkt sein. Eine gute Architektur baut keine nachträgliche Dokumentation um ein chaotisches Betriebsgeschehen. Sie regelt zuerst, wie Arbeit, Informationen und Entscheidungsverantwortung im Unternehmen fließen.

Was bedeutet eigentlich die Planung einer Compliance-Architektur?

Die Compliance-Architektur beschreibt, wie die Regeln, Prozesse, Systeme, Daten und Kontrollpunkte eines Unternehmens miteinander verbunden sind. Es geht nicht nur darum, welches Dokument aufbewahrt werden muss oder wer einen Vertrag unterzeichnen darf. Sondern auch darum, wer in der Praxis auf Basis welcher Informationen in welchem System und mit welchem Nachweis Entscheidungen trifft.

In einer funktionierenden Architektur bleibt eine Regel nicht nur ein PDF in einem freigegebenen Ordner. Sie erscheint im Prozess. Wenn ein Einkauf über einem bestimmten Wert nur mit Genehmigung gestartet werden kann, muss dies im System, bei der Aufgabenverteilung und in den Berichten sichtbar sein. Wenn nur bestimmte Mitarbeiter auf Kundendaten zugreifen dürfen, reicht es nicht, das Team daran zu erinnern: Zugriffe, Datenübertragungen und Ausnahmen müssen ebenfalls verwaltet werden.

Deshalb ist Compliance nicht nur eine rechtliche oder IT-Angelegenheit. Es ist auch eine betriebliche Frage. Fehlende Kontrollen können ebenso zu verspäteter Leistung, fehlerhafter Rechnungsstellung, umstrittenen Verantwortlichkeiten oder verlorenem Kundenvertrauen führen wie direkte regulatorische Risiken.

Die Planung beginnt dort, wo die tägliche Arbeit ins Stocken gerät

Unternehmen beschreiben das Problem selten so, dass ihnen eine Compliance-Architektur fehlt. Sie sagen eher, dass es zu viele manuelle Kontrollen gibt, unklar ist, wer entscheiden darf, oder dass die Bearbeitung bei Abwesenheit eines Kollegen stoppt.

Dies sind nicht unbedingt menschliche Fehler. Oft sind sie Anzeichen dafür, dass der Prozess die notwendigen Kontrollen nicht enthält. Die Menschen versuchen, den Betrieb mit E-Mails, Telefonaten und eigenen Tabellen zusammenzuhalten. Kurzfristig mag das flexibel erscheinen. Beim Wachstum produziert es jedoch immer mehr Ausnahmen, parallele Daten und schwer nachvollziehbare Entscheidungen.

Der tatsächliche Prozess muss aufgedeckt werden

Der erste Schritt der Planung ist nicht die Auswahl eines neuen Systems. Die tatsächliche Prozessabbildung vom Eingang der Bestellung über die Erfüllung, Rechnungsstellung und Reklamationsbearbeitung bis zum Abschluss. Wichtig ist nicht, wie der Prozess laut interner Richtlinien funktionieren sollte, sondern wie er an einem Dienstagvormittag funktioniert, wenn eine dringende Bestellung eingeht, eine Information fehlt und der zuständige Leiter in einer Besprechung ist.

Hier kommen die kritischen Fragen ans Licht. Wo wird dieselbe Information mehrfach eingegeben? Wer überträgt Informationen von einem System ins andere? Welche Genehmigung erfolgt tatsächlich mündlich? Wer kann erklären, warum eine Bestellung oder ein Produktionsparameter geändert wurde? Welcher Schritt hängt vom Wissen eines einzigen erfahrenen Mitarbeiters ab?

Das Ziel ist nicht, jeden Arbeitsprozess starr zu machen. Ausnahmen sind ein natürlicher Teil des Lebens eines Herstellers, Handels- oder Logistikunternehmens. Die Frage ist, ob die Ausnahme sichtbar, begründbar und nachvollziehbar ist oder einfach in einem E-Mail-Austausch verschwindet.

Verpflichtungen müssen nach geschäftlicher Auswirkung interpretiert werden

Die Compliance-Anforderungen unterscheiden sich von Unternehmen zu Unternehmen. Andere Kontrollen sind wichtig bei der Verarbeitung personenbezogener Daten, bei finanziellen Genehmigungen, im Qualitätsmanagement, in Exportprozessen oder in industriellen Produktionsumgebungen. Der gemeinsame Nenner ist, dass jede Vorschrift in die Sprache des täglichen Betriebs übersetzt werden muss.

Zum Beispiel ist die Verpflichtung zur Datenaufbewahrung nicht nur eine Archivierungsfrage. Sie bestimmt, welches System als zuverlässige Quelle gilt, wie lange Dokumente aufbewahrt werden, wer darauf zugreifen kann und was passiert, wenn eine alte Anwendung ersetzt wird. Die Trennung von Aufgaben ist auch keine Frage des Organisationsdiagramms: Es muss sichergestellt werden, dass dieselbe Person nicht unkontrolliert eine sensible Transaktion initiieren, genehmigen und abschließen kann.

Aus welchen Elementen besteht eine brauchbare Architektur?

Die Details hängen von der Branche und dem Risikoniveau ab, aber eine gut geplante Compliance-Architektur verbindet in der Regel vier Bereiche:

• Verantwortlichkeiten und Berechtigungen: klar, wer initiieren, genehmigen, ändern oder Daten einsehen kann.
• Datenlebenszyklus und zuverlässige Quellen: klar, woher die Daten kommen, wo sie verarbeitet werden, wer sie ändern kann, wie lange sie aufbewahrt werden und wann sie gelöscht werden können.
• Prozesskontrollen und Nachweise: Genehmigungen, Kontrollen, Abweichungen und Entscheidungen hinterlassen eine angemessene Spur.
• Betriebskontinuität: bekannt, was bei Systemausfall, fehlerhafter Integration, Ausfall von Schlüsselpersonen oder außergewöhnlichen Prozessen passiert.

Diese verstärken sich gegenseitig. Ein Berechtigungsmodell ist zum Beispiel wertlos, wenn die Mitarbeiter einen gemeinsamen Benutzer verwenden. Eine Protokollierung ist nicht ausreichend, wenn niemand weiß, welche Ereignisse untersucht werden müssen. Der dokumentierte Prozess schützt nicht, wenn die tägliche Arbeit tatsächlich über unkontrollierte Umwege abläuft.

Überplanung ist jedoch eine reale Gefahr. Ein Unternehmen mit 40 Mitarbeitern benötigt nicht unbedingt dieselbe Tiefe an Genehmigungs- und Dokumentationsprozessen wie ein streng regulierter Konzern mit mehreren Standorten. Auch die Kosten der Kontrolle zählen. Wenn für eine einfache Bearbeitung die Genehmigung von vier Personen erforderlich ist, mag das Unternehmen auf dem Papier geschützt sein, schafft aber gleichzeitig einen langsamen, frustrierenden Betrieb, der zu Umgehungen anregt.

Die Übergabe zwischen Systemen ist der häufigste Schwachpunkt

In vielen Unternehmen funktionieren die einzelnen Systeme für sich genommen einwandfrei. Der Webshop verwaltet die Bestellungen, das ERP den Bestand, das Abrechnungssystem die Belege und das Lagersystem die Kommissionierung. Das Problem beginnt dort, wo die Informationen von einem System ins andere übergehen.

Wenn ein Mitarbeiter täglich eine Datei exportiert, sie manuell bearbeitet und in ein anderes System hochlädt, wird er zur Integration. Gleichzeitig wird er zur Kontrolle, zur Fehlerbehandlung und oft zur einzigen Person, die die Regeln der Datenübertragung versteht. Dies ist kein nachhaltiges Compliance-Modell.

Integration ist jedoch nicht automatisch die Lösung. Zunächst muss geklärt werden, welches System die zuverlässige Quelle für die jeweiligen Daten ist, wann es von einem anderen System überschrieben werden kann, wie Fehler angezeigt werden und wer die Abweichungen behandelt. Eine schnell erstellte Verbindung kann die Verbreitung fehlerhafter oder unvollständiger Daten nur beschleunigen.

Hier zeigt sich der Wert der Architektur: Sie verbindet nicht einfach die Systeme, sondern regelt, welche geschäftliche Bedeutung die übermittelten Informationen haben. Der Status einer Bestellung kann beispielsweise für den Vertrieb, das Lager und die Finanzabteilung unterschiedliche Bedeutungen haben. Die Aufgabe der Planung ist es, sicherzustellen, dass diese Unterschiede nicht aus versteckten Annahmen, sondern aus gemeinsam akzeptierten Betriebsregeln resultieren.

Die Technologie kommt erst danach ins Spiel

Wenn die Prozesse, Verantwortlichkeiten und Risiken klar sind, kann entschieden werden, welche technischen Änderungen gerechtfertigt sind. Manchmal reicht es aus, die Berechtigungen zu ordnen, eine einheitliche Datenpflege-Regel einzuführen oder die Ausnahmebehandlung zu vereinfachen. In anderen Fällen sind Workflow-Systeme, Systemintegrationen, Protokollierungslösungen, Dokumentenmanagement oder eine schrittweise Modernisierung einer alten Anwendung erforderlich.

Automatisierung ist dann nützlich, wenn sie eine bereits verstandene und vereinfachte Regel konsequent ausführt. Es lohnt sich nicht, einen Prozess zu automatisieren, von dem niemand genau weiß, warum er fünf Genehmigungsschritte enthält. Das Ergebnis ist dann nur, dass dieselbe überflüssige Arbeit schneller produziert wird.

Eine gute Lösung erleichtert auch den Menschen die Arbeit. Sie müssen weniger Daten erneut eingeben, weniger Status telefonisch abklären und haben mehr verlässliche Informationen für echte Entscheidungen zur Verfügung. Compliance ist nicht ein Werkzeug zur Kontrolle der Mitarbeiter, sondern der Rahmen, um vorhersehbar gut arbeiten zu können.

Was sollte nach der Einführung gemessen werden?

Die Planung wird dann zu einem Geschäftsergebnis, wenn sie messbare Veränderungen im Betrieb bringt. Dazu gehören die Anzahl manueller Datenkorrekturen, die Durchlaufzeit von Genehmigungen, der Anteil unvollständiger Bestelldaten, die Zeit zur Aufdeckung von Systemfehlern oder wie viele Quellen und wie viel manuelle Arbeit für einen kritischen Bericht erforderlich sind.

Es lohnt sich auch zu beobachten, wie viele Ausnahmen auftreten und warum sie passieren. Viele Ausnahmen deuten nicht unbedingt auf Disziplinlosigkeit hin. Es könnte sein, dass die Regel zu starr ist, der Prozess nicht der geschäftlichen Realität entspricht oder die Qualität der Basisdaten unzureichend ist. Die Messung sollte daher nicht zur Bestrafung, sondern zur kontinuierlichen Korrektur dienen.

Die Planung einer Compliance-Architektur ist dann ausgereift, wenn die Einführung eines neuen Standorts, einer Produktlinie, eines Kundenkanals oder eines Systems kein separates Feuerlöschprojekt mehr ist. Die Organisation weiß, welche Daten sie schützen muss, wer Entscheidungen treffen kann, wie Ausnahmen behandelt werden können und woraus später nachgewiesen werden kann, dass der Prozess korrekt funktioniert hat. Diese Art von Ordnung bremst das Wachstum nicht. Sie verhindert vielmehr, dass Wachstum in unkontrollierbare Verwaltung ausartet.