Der schwierigste Teil jedes Automatisierungsprogramms ist nicht die Technologie, sondern die Reihenfolge. Für ein FINMA-reguliertes Institut ist genau der Instinkt, einen Geschäftsprozess mit KI in einem einzigen ehrgeizigen Anlauf zu automatisieren, das, was ein blockiertes Aushängeschild und einen nervösen Verwaltungsrat hervorbringt. Neunzig Tage genügen, um einen einzelnen Workflow von einer unordentlichen manuellen Routine zu einem gemessenen, auditierten Prozess in Produktion zu bringen — aber nur, wenn die neunzig Tage strukturiert sind. Die Struktur, die funktioniert, sind vier Phasen von je zwei bis vier Wochen, und jede endet nicht in einem Statusbericht, sondern an einem Entscheidungstor, das stopp sagen darf. Eine Phase, die sich nicht anhalten lässt, ist kein Tor; sie ist eine schiefe Ebene.
Die Tage 1 bis 14 sind die Prozessanalyse, und es ist die Phase, die die meisten Teams zu ihrem Schaden überspringen. Die Arbeit besteht hier nicht darin, ein Werkzeug zu wählen — sondern den Workflow genau so zu kartieren, wie er heute läuft, jeden Kontrollpunkt und die dafür verantwortliche Person zu benennen und die Baseline zu erfassen: die Durchlaufzeit, die Ausnahmequote, die Zahl der manuellen Eingriffe zwischen den Daten und dem Investor. Tun Sie das während einer parallelen Beobachtung, während der aktuelle Prozess läuft, damit die Zahlen echt und nicht erinnert sind. Das Ergebnis ist ein dokumentierter Ist-Prozess mit einer gemessenen Baseline. Das Tor ist eine einzige Frage: Können wir diese Baseline beweisen? Hat der Workflow keinen messbaren Ausgangspunkt, geht er zurück in die Discovery, bis er einen hat — denn ohne Baseline können Sie den Return nie belegen, keine Regression erkennen und die erste Frage nicht beantworten, die ein interner Prüfer stellen wird.
Die Tage 15 bis 30 gelten der Ansatzentscheidung und einem Proof of Concept. Entscheiden Sie zuerst Build versus Buy nach den Kriterien, die in der regulierten Finanzwelt zählen — Datensensitivität und Nachvollziehbarkeit, nicht der Preis — und prüfen Sie, wohin die Daten fliessen, bevor irgendetwas sie berührt. Bauen Sie dann einen bewusst eng gefassten Proof of Concept gegen repräsentative Daten, mit drei Erfolgskriterien und, ebenso wichtig, den vorab definierten Abbruchkriterien. Ein Proof of Concept prüft die Machbarkeit; er ist kein Pilot und keine Verpflichtung. Das Ergebnis ist ein POC-Urteil, gemessen an diesen vorab gesetzten Kriterien. Das Tor: Hat er die Latte übersprungen, die Sie am fünfzehnten Tag gesetzt haben? Wenn nicht, haben Sie zwei Wochen aufgewendet, um sechs Monate an einem Workflow zu sparen, der sich nie gerechnet hätte — ein guter Tausch, kein Scheitern.
Die Tage 31 bis 60 sind der Bau und die Integration, und hier trennt Disziplin einen dauerhaften Prozess von einer Vorführung. Bauen Sie in Ihrer eigenen Umgebung, auf dem Stack, den Sie ohnehin lizenzieren, mit einer Berechnung, die deterministisch und auditierbar bleibt, und mit dem Modell darum herum statt darin. Gestalten Sie zuerst den Parallelbetrieb: Der neue Workflow erzeugt seinen Output neben dem alten, nicht an seiner Stelle. Verdrahten Sie die drei Dinge, nach denen ein Compliance-Officer tatsächlich fragt — einen Prüfpunkt oberhalb eines Konfidenzschwellenwerts, ein Logging, das dem Prozess erlaubt, sich nachträglich zu rekonstruieren, und einen Rollback, den ein Mensch ohne Hektik auslösen kann. Das Ergebnis ist ein funktionierender Workflow im Parallelbetrieb. Das Tor ist die Abstimmung: Stimmt der automatisierte Output Lauf für Lauf innerhalb der Toleranz mit dem manuellen Prozess überein? Bis er das tut, geht nichts live.
Die Tage 61 bis 90 sind Rollout, Messung und Iteration — schrittweise, nie als einzelner Schalter. Weiten Sie von einer prüfenden Person zum Team in Etappen aus, halten Sie den Parallelbetrieb aufrecht, bis die Abstimmung trägt, und messen Sie das Ergebnis gegen die Baseline vom Tag null statt gegen ein Gefühl. Budgetieren Sie ehrlich den Einbruch im zweiten Monat: Es gibt eine vorhersehbare Strecke, in der Parallelbetrieb und zusätzliche Review mehr kosten, als sie sparen, bevor die Kurve dreht, und ein vorgewarnter Verwaltungsrat liest das als erwartet statt als Scheitern. Das Ergebnis ist der Workflow in Produktion, verantwortet von einer benannten senior verantwortlichen Person, mit einer gemessenen Verbesserung gegenüber der Baseline. Das letzte Tor: Schlägt das bewiesene Ergebnis die Baseline, und würde es eine Revision ohne Hilfe überstehen? Nur ein Ja auf beides beendet die neunzig Tage.
Die Entscheidungstore sind keine Bürokratie, die auf den Plan geschraubt wird; sie sind der Plan. Jedes gibt dem Institut einen sauberen, verteidigbaren Ort zum Anhalten — nach der Analyse, nach dem Proof of Concept, nach der Abstimmung — bevor sich die Ausgaben aufsummieren. Genau so wurde das Reporting über 39+ Fonds bei einer führenden Zürcher Anlagestiftung aufgebaut: nicht als eine einzige Transformation, sondern als ein eng gefasster Workflow, durch genau diese Tore geführt, seine verdichtete Durchlaufzeit gegen eine echte Baseline gemessen, und erst dann auf den nächsten ausgeweitet. Die Tore sind es, die ein reguliertes Institut schnell handeln lassen, ohne unbedacht zu handeln.
Nichts davon ist glanzvoll, und das ist der Punkt. Einen Geschäftsprozess mit KI in der regulierten Finanzwelt zu automatisieren ist kein Technologieprojekt mit einem Governance-Nachgedanken; es ist eine Governance-Disziplin, die zufällig Technologie einsetzt. Beginnen Sie mit dem einen Workflow, dessen Baseline Sie beweisen können, führen Sie ihn durch die vier Phasen, und lassen Sie jedes Tor das nächste verdienen. Wenn die neunzig Tage mit einem gemessenen, auditierten Prozess in Produktion enden, haben Sie nicht nur einen Workflow automatisiert — Sie haben eine Vorlage und einen bewiesenen Fall, der den nächsten finanziert. Es ist dieselbe Disziplin, die sich durch alles zieht, was wir bauen.