Vor sechs Monaten saß ich mit einem CIO eines mittelgroßen Versicherers zusammen. Sein Unternehmen wollte eine neue Plattform für die Schadenabwicklung einführen.
Technisch machbar. Business Case klar. Management an Bord.
Aber dann kam die Frage, die in jedem regulierten Umfeld kommt: »Wie lange brauchen wir für Compliance?«
Sein interner Compliance-Verantwortlicher hatte geschätzt: sechs Monate. Datenschutz-Prüfung, BaFin-Abstimmung, IT-Sicherheitsaudit, Betriebsratsanhörung.
Der CIO war frustriert. »Sechs Monate, nur für Freigaben. Das bremst uns komplett aus.«
Ich habe ihm eine andere Perspektive angeboten: »Wenn Sie Compliance richtig einbinden, sparen Sie vier Monate — statt dass sie sechs Monate verlieren.«
Er hat mich angeschaut, als hätte ich gerade etwas Unmögliches gesagt.
Aber genau das ist passiert.
Das Standardmuster: Compliance als Bottleneck
In den meisten Unternehmen läuft es so:
Man plant ein Transformationsprogramm. Man entwickelt das Konzept. Man baut die Architektur. Man testet das System.
Und irgendwann — meistens kurz vor dem geplanten Go-live — holt man Compliance dazu.
Datenschutz schaut sich das System an und sagt: »Das geht so nicht. Ihr speichert personenbezogene Daten in einer Cloud-Umgebung, die nicht DSGVO-konform ist.«
IT-Sicherheit testet die Architektur und sagt: »Das erfüllt nicht unsere Standards. Ihr braucht zusätzliche Verschlüsselung und Zugriffskontrollen.«
Die BaFin wird informiert und sagt: »Das müssen wir prüfen. Rechnen Sie mit drei Monaten bis zur Rückmeldung.«
Das Programm steht still. Die Kosten laufen. Die Frustration wächst.
Das ist das Standardmuster. Und es ist der Grund, warum Compliance als Bremsklotz wahrgenommen wird.
Aber das Problem ist nicht Compliance. Das Problem ist der Zeitpunkt, zu dem Compliance eingebunden wird.
Die kontraintuitive Wahrheit
Hier ist, was ich in 25 Jahren in regulierten Umfeldern gelernt habe:
Compliance beschleunigt Programme — wenn man sie früh genug einbindet.
Nicht trotz der Anforderungen. Sondern wegen der Anforderungen.
Es gibt drei Mechanismen, die das erklären:
Mechanismus 1: Frühe Klarheit verhindert späte Umbauten
Das größte Risiko in jedem Programm ist nicht, dass etwas schiefgeht. Es ist, dass man es erst spät merkt.
Wenn Sie sechs Monate in eine Architektur investieren — und dann stellt sich heraus, dass sie nicht anforderungskonform ist — müssen Sie von vorne anfangen.
Wenn Sie Compliance von Anfang an einbinden, wissen Sie in Woche 2, was funktioniert — und was nicht.
Beim Versicherer aus dem Beispiel haben wir das konsequent gemacht:
Woche 1: Kick-off mit Datenschutz, IT-Sicherheit und Betriebsrat. Frage: »Welche roten Linien gibt es?«
Die Antworten waren klar: Cloud-Speicherung nur in EU-Rechenzentren. Verschlüsselung nach BSI-Standard. Keine automatisierte Entscheidungsfindung ohne menschliche Überprüfung.
Das waren harte Anforderungen. Aber wir kannten sie in Woche 1 — nicht in Woche 24.
Ergebnis: Die Architektur wurde von Anfang an compliant gebaut. Keine späten Umbauten. Keine Verzögerungen.
Frühe Klarheit kostet zwei Wochen Planung. Späte Umbauten kosten sechs Monate Neuaufbau.
Mechanismus 2: Erzwungene Priorisierung verhindert Scope Creep
Compliance zwingt Sie, Prioritäten zu setzen.
Das klingt wie eine Einschränkung. Aber in der Praxis ist es ein Geschenk.
Denn das größte Problem in Transformationsprogrammen ist nicht, dass zu wenig gebaut wird. Es ist, dass zu viel gebaut wird.
Scope Creep ist der stille Killer. Jedes Feature, das »noch schnell dazukommt«. Jede Anpassung, die »ja nicht viel Aufwand« ist. Jede Integration, die »eigentlich logisch« wäre.
Compliance stoppt das.
Beim Versicherer gab es eine Diskussion über ein zusätzliches Feature: automatisierte Risikoeinschätzung für Schadenfälle.
Technisch machbar. Business Case positiv. Das Team wollte es bauen.
Dann kam Datenschutz und sagte: »Das fällt unter automatisierte Entscheidungsfindung. Ihr braucht eine zusätzliche Rechtsgrundlage, eine Datenschutz-Folgenabschätzung und eine BaFin-Freigabe. Rechnet mit vier Monaten.«
Das Feature wurde gestrichen.
War das ein Verlust? Nein. Es war eine erzwungene Priorisierung.
Denn dieses Feature hätte das Programm um vier Monate verzögert — für einen Zusatznutzen, der nicht kritisch war.
Compliance zwingt Sie, sich auf das Wesentliche zu konzentrieren. Das ist keine Bremse. Das ist Fokus.
Mechanismus 3: Externe Autorität löst interne Blockaden
Der dritte Mechanismus ist der subtilste — aber vielleicht der wirkungsvollste.
Compliance gibt Ihnen eine externe Autorität, die interne Konflikte lösen kann.
In jedem großen Programm gibt es Stakeholder, die unterschiedliche Interessen haben. Ein Geschäftsbereich will Feature A. Ein anderer will Feature B. Beide können nicht gleichzeitig priorisiert werden.
In der normalen Governance führt das zu endlosen Diskussionen. Jeder argumentiert, warum seine Priorität wichtiger ist. Das Steuergremium kann sich nicht einigen. Die Entscheidung wird vertagt.
Compliance beendet diese Diskussionen.
Beim Versicherer gab es einen Konflikt über die Datenhaltung. Ein Geschäftsbereich wollte alle historischen Schadendaten migrieren — zehn Jahre zurück. Ein anderer wollte nur die letzten drei Jahre.
Die Diskussion lief im Kreis.
Dann kam Datenschutz und sagte: »DSGVO verlangt Datensparsamkeit. Ihr müsst nachweisen, warum ihr Daten länger als fünf Jahre braucht. Wenn ihr das nicht könnt, müsst ihr sie löschen.«
Die Entscheidung war getroffen. Fünf Jahre. Nicht als Kompromiss — sondern als Compliance-Anforderung.
Das hat eine monatelange Diskussion beendet. Und das Programm konnte weiterlaufen.
Compliance ist die externe Autorität, die interne Blockaden auflöst — ohne dass jemand sein Gesicht verliert.
Wann Compliance wirklich bremst
Ich will nicht behaupten, dass Compliance nie bremst. Sie kann bremsen — in drei Situationen:
Erstens: Wenn sie zu spät eingebunden wird. Dann wird aus einer Planungsanforderung ein Umbauaufwand.
Zweitens: Wenn sie nicht verstanden wird. Compliance-Anforderungen sind komplex. Wenn das Programmteam sie nicht versteht, entstehen Missverständnisse und Verzögerungen.
Drittens: Wenn sie politisch instrumentalisiert wird. Wenn Compliance als Argument genutzt wird, um Programme zu blockieren, die aus anderen Gründen unerwünscht sind.
Aber all diese Situationen sind vermeidbar.
Binde Compliance früh ein. Baue Verständnis auf. Halte Compliance politisch neutral.
Wenn du das tust, wird Compliance vom Bremsklotz zum Katalysator.
Wie man Compliance richtig einbindet
Konkret: Was bedeutet »früh genug«?
Hier ist meine Regel:
Compliance muss in den ersten zwei Wochen eines Programms eingebunden sein. Nicht als Zuschauer — sondern als aktiver Stakeholder.
Das bedeutet:
1. Datenschutz, IT-Sicherheit und relevante Regulierungsstellen sind beim Kick-off dabei.
2. Die Frage »Welche Compliance-Anforderungen gibt es?« wird beantwortet, bevor die Architektur definiert wird.
3. Compliance-Vertreter haben ein Veto-Recht in der Governance — aber nur für Compliance-Fragen, nicht für Business-Entscheidungen.
Wenn diese drei Dinge erfüllt sind, beschleunigt Compliance das Programm.
Beim Versicherer haben wir das konsequent umgesetzt. Ergebnis: Das Programm wurde vier Monate früher fertig als geplant — nicht später.
Warum? Weil wir keine späten Umbauten hatten. Weil wir fokussiert geblieben sind. Weil interne Blockaden schnell gelöst wurden.
Was das für Entscheider bedeutet
Wenn Sie gerade ein Programm in einem regulierten Umfeld planen — Banking, Versicherung, Gesundheitswesen, Energie — dann stellen Sie sich eine Frage:
»Wann binden wir Compliance ein?«
Wenn die Antwort »kurz vor dem Go-live« lautet, dann wird Compliance Sie bremsen.
Wenn die Antwort »in den ersten zwei Wochen« lautet, dann wird Compliance Sie beschleunigen.
Compliance ist kein Bottleneck. Sie ist ein Filter. Und Filter beschleunigen — wenn man sie richtig einsetzt.
Die Frage ist nicht: »Wie vermeiden wir Compliance?«
Die Frage ist: »Wie nutzen wir Compliance als Hebel?«
Wenn Sie diese Perspektive einnehmen, werden Ihre Programme schneller — nicht langsamer.
Über den Autor:
Rainer V. Hiller ist Senior Program Manager mit 25 Jahren Erfahrung in der Steuerung komplexer Transformationsprogramme in regulierten Umfeldern — spezialisiert auf Banking, Versicherung und Gesundheitswesen. Er ist ab sofort verfügbar für Interim-Mandate.
Kontakt: rainer.hiller@dxb-41.consulting | www.dxb-41.consulting