Compliance ist kein Anhängsel

Ein Prüfer sitzt vor zwei Dokumenten. Links das BPMN-Modell des Kreditvergabeprozesses, sauber gezeichnet, mit einer Aktivität «Bonität prüfen». Rechts die IKS-Kontrollmatrix in einer Tabellenkalkulation, in der eine Kontrolle «Zwei-Augen-Prinzip bei Bonitätsentscheiden» steht. Die Frage, die im Raum steht, ist banal und trotzdem heikel: Gehört diese Kontrolle wirklich zu genau dieser Aktivität — und ist das noch die Version, die letzte Woche angepasst wurde? Wer die beiden Dokumente einzeln pflegt, kann diese Frage nicht mit einem Klick beantworten. Er muss vergleichen, nachfragen, rekonstruieren. Und genau in dieser Lücke entstehen die Probleme, um die es hier geht.

Zwei Wahrheiten, die auseinanderdriften

Das Grundproblem ist keine Nachlässigkeit, sondern eine Strukturentscheidung, die selten bewusst getroffen wird. Prozesse werden in einem Modellierungswerkzeug beschrieben, das interne Kontrollsystem in einer Tabelle. Beide beschreiben denselben Sachverhalt — was im Prozess geschieht und wie es kontrolliert wird — aber sie tun es in getrennten Werkzeugen, mit getrennten Verantwortlichen und getrennten Aktualisierungszyklen.

Solange nichts geändert wird, funktioniert das. Der Ärger beginnt bei der ersten Prozessänderung. Wer den Kreditprozess umbaut, eine Aktivität aufteilt oder eine neue Freigabestufe einzieht, ändert das BPMN-Modell. Ob die zugehörige Kontrollzeile in der Tabelle nachgezogen wird, hängt davon ab, dass jemand daran denkt, den Verweis kennt und Zeit hat. Fehlt eines davon, entstehen zwei Wahrheiten: Der Prozess sagt A, das Kontrollsystem sagt noch B. Keine der beiden ist offensichtlich falsch, und deshalb bleibt der Widerspruch lange unentdeckt — bis der Audit ihn findet.

Die Fachliteratur beschreibt diesen Bruch nüchtern. Dumas, La Rosa, Mendling und Reijers halten in den Fundamentals of Business Process Management fest, dass ein Prozessmodell nur so viel wert ist, wie es den tatsächlich gelebten Prozess widerspiegelt; das Auseinanderklaffen von Modell und Realität ist eine der zentralen Herausforderungen des Prozessmanagements. Ein IKS, das an ein veraltetes oder abweichendes Prozessbild geheftet ist, erbt dieses Problem doppelt — es dokumentiert Kontrollen für einen Prozess, den es so nicht mehr gibt.

Was die Rahmenwerke tatsächlich verlangen

Es lohnt sich, an dieser Stelle nicht mit einer Meinung zu argumentieren, sondern mit dem, was die etablierten Rahmenwerke seit Jahren vorgeben.

Das Internal Control – Integrated Framework des Committee of Sponsoring Organizations of the Treadway Commission (COSO) aus dem Jahr 2013 definiert interne Kontrolle als einen Prozess, der auf das Erreichen von Zielen in den Bereichen Betrieb, Berichterstattung und Compliance ausgerichtet ist. Entscheidend ist die Denkweise dahinter: Kontrolle ist kein separates Register, sondern etwas, das in die betrieblichen Abläufe eingebettet ist und nachvollziehbar sein muss. Eine Kontrolle, die niemand einem konkreten Prozessschritt zuordnen kann, erfüllt diesen Anspruch nur auf dem Papier.

Das Three Lines Model des Institute of Internal Auditors (IIA), 2020 in überarbeiteter Form veröffentlicht, ergänzt die Frage nach den Verantwortlichkeiten. Es ordnet die Rollen: Die operative Führung verantwortet die Prozesse und die in sie eingebauten Kontrollen (erste Linie), Risiko- und Compliance-Funktionen unterstützen und überwachen (zweite Linie), die interne Revision liefert unabhängige Prüfung und Sicherheit (dritte Linie). Damit dieses Modell trägt, müssen alle drei Linien über denselben Sachverhalt sprechen. Wenn die erste Linie den Prozess im BPMN-Tool pflegt und die zweite Linie ihre Sicht in einer eigenen Tabelle führt, prüft die dritte Linie am Ende zwei Darstellungen, die niemand systematisch abgeglichen hat.

Beide Rahmenwerke laufen auf dieselbe Kernbotschaft hinaus: Compliance gehört an den Prozess, nicht als nachträgliches Anhängsel daneben. Nicht, weil das ordentlicher aussieht, sondern weil interne Kontrolle ohne den konkreten Bezug zum Ablauf ihre definierende Eigenschaft verliert.

Die Kette, die zusammenhängen muss

Wer Compliance an den Prozess bindet, denkt nicht in einer statischen Kontrollmatrix, sondern in einer Kette. Sie beginnt bei einer konkreten Aktivität und läuft bis zur Massnahme, die aus einer Prüfung folgt:

Diese Kette ist schematisch, aber sie zeigt das Wesentliche. Jedes Glied hat nur dann Bedeutung, wenn es an das vorige gebunden bleibt. Ein Risiko ohne die Aktivität, an der es entsteht, ist eine abstrakte Sorge. Eine Kontrolle ohne das Risiko, das sie mindert, ist Aufwand ohne Begründung. Ein Kontrolltest ohne die Kontrolle, die er prüft, misst nichts Bestimmtes. Und eine Feststellung, die zu keiner Massnahme führt, ist ein Befund, der versandet.

Wird diese Kette über zwei getrennte Werkzeuge gespannt — Aktivität und Risiko im Modell, Kontrolle bis Massnahme in der Tabelle —, dann bricht sie genau an der Nahtstelle. Der Verweis von der Aktivität auf die Kontrollzeile ist ein Textfeld, kein belastbarer Bezug. Er hält, solange niemand etwas ändert, und reisst bei der ersten Umbenennung, Aufteilung oder Neunummerierung.

Ein konkretes Beispiel: Die Aktivität «Bonität prüfen» wird aufgeteilt in «Automatische Vorprüfung» und «Manuelle Kreditwürdigkeitsprüfung», weil ein neues Scoring-System eingeführt wird. Im Modell ist das eine saubere Änderung. In der Tabelle steht die Kontrolle «Zwei-Augen-Prinzip» weiterhin bei «Bonität prüfen» — einer Aktivität, die es nicht mehr gibt. Greift das Zwei-Augen-Prinzip jetzt bei der Vorprüfung, bei der manuellen Prüfung oder bei beiden? Die Tabelle schweigt. Der nächste Audit wird die Frage stellen, und die Antwort wird eine Rekonstruktionsübung.

Wenn das Kontrollsystem am Prozess hängt: MESTRO

An diesem Punkt wird konkret, was «Compliance gehört an den Prozess» als Werkzeug bedeutet. MESTRO, ein KI-nativer Orchestrator für den BPM-Lebenszyklus, behandelt das interne Kontrollsystem nicht als separate Tabelle, sondern hängt es direkt an die Aktivität beziehungsweise den Prozess, zu der oder dem es gehört. Das ist der entscheidende Unterschied: Der Bezug zwischen Aktivität und Kontrolle ist keine Textnotiz, die reissen kann, sondern eine Verankerung im Modell selbst.

Damit lässt sich die vollständige Kette durchgängig abbilden — Risiko, Kontrolle, Kontrolltest, Feststellung, Massnahme —, ohne dass sie an einer Werkzeuggrenze zerfällt. Wird die Aktivität «Bonität prüfen» aufgeteilt, bleibt sichtbar, welche Kontrolle mitwandert und welche nicht mehr zutrifft, weil die Kontrolle an der Aktivität hängt und nicht an einer Zeilennummer in einem Zweitdokument.

Darüber liegt der BPM-Überbau, der diese lokale Verankerung erst governance-tauglich macht. Eine Portfolio-Sicht über alle Prozesse zeigt, wo Kontrollen sitzen und wo Lücken klaffen, statt dass jede Kontrollmatrix für sich in einem eigenen Dateiablage-Ordner lebt. Klare Rollen und Rechte sowie nachvollziehbare Freigaben spiegeln die Logik des Three Lines Model wider — wer modelliert, wer prüft, wer freigibt, ist im System hinterlegt, nicht in einer E-Mail-Historie. Und weil jede Änderung eine Version ist, entsteht eine lückenlose Historie: Man kann zeigen, wie eine Kontrolle über die Zeit aussah, wann sie geändert wurde und in welchem Zustand der Prozess zum Zeitpunkt einer Prüfung war.

Das Modellieren selbst bleibt dabei Standard: Der Design-Teil erzeugt reguläres BPMN beziehungsweise CMMN, wie es die Object Management Group in der Business Process Model and Notation spezifiziert — kein proprietäres Format, das man später nicht mehr los wird. Die Analyse liefert die durchgängige End-to-End-Struktur, an der die Kontrollen dann andocken. MESTRO ist hier ein Beispiel dafür, wie die Bindung von Kontrolle an Prozess technisch aussehen kann; der Massstab, an dem sich jedes solche Werkzeug messen lassen muss, kommt aber weiterhin von COSO und vom IIA, nicht vom Werkzeug.

Audit-Bereitschaft als Nebenprodukt

Der eigentliche Gewinn zeigt sich nicht im Alltag, sondern im Audit — und zwar dadurch, dass er unspektakulär verläuft. Wer sein Kontrollsystem am Prozess führt, muss vor einer Prüfung nicht zwei Welten abgleichen, weil es nur eine gibt. Die Frage «Gehört diese Kontrolle zu dieser Aktivität, und ist das die aktuelle Version?» beantwortet sich aus der Struktur selbst. Audit-Bereitschaft wird damit nicht zu einem Projekt vor jedem Prüftermin, sondern zum Nebenprodukt der täglichen Arbeit.

Das ist kein Versprechen auf weniger Kontrolle, im Gegenteil. Die Kontrollen werden nicht weniger streng, sie werden nur anders verortet — dort, wo sie hingehören. Der Aufwand verschiebt sich von der Rekonstruktion im Nachhinein zur sauberen Verankerung im Vorhinein. Das ist genau die Einbettung, die COSO meint, wenn es interne Kontrolle als Teil des betrieblichen Ablaufs beschreibt.

Fazit

Compliance als Anhängsel zu führen — das Modell hier, die Kontrolltabelle dort — ist verlockend, weil es beim ersten Aufsetzen einfacher wirkt und jede Fachfunktion in ihrem gewohnten Werkzeug bleiben kann. Der Preis fällt später an, in Form von zwei Wahrheiten, die auseinanderdriften, und einem Audit, das die Differenz sichtbar macht. Die etablierten Rahmenwerke geben die Richtung klar vor: COSO verlangt Kontrollen, die in Prozesse eingebettet und nachvollziehbar sind; das Three Lines Model verlangt, dass alle Verantwortlichen über denselben Sachverhalt sprechen. Beides ist nur zu haben, wenn die Kontrolle am Prozess hängt und die Kette von der Aktivität bis zur Massnahme nirgends an einer Werkzeuggrenze zerbricht. Werkzeuge wie MESTRO zeigen, wie diese Bindung aussehen kann — der Anspruch selbst ist älter als jedes Werkzeug. Wer ihn ernst nimmt, gewinnt Audit-Bereitschaft nicht als Kraftakt, sondern als Nebenprodukt.

Quellen & Weiterlesen

• Committee of Sponsoring Organizations of the Treadway Commission (COSO): Internal Control – Integrated Framework, 2013. https://www.coso.org/
• The Institute of Internal Auditors (IIA): The IIA’s Three Lines Model, 2020. https://www.theiia.org/
• M. Dumas, M. La Rosa, J. Mendling, H. A. Reijers: Fundamentals of Business Process Management, 2. Auflage, Springer, 2018.
• Object Management Group: Business Process Model and Notation (BPMN) Version 2.0.2, 2013. https://www.omg.org/spec/BPMN/2.0.2/