Wenn ein Finanzinstitut fragt, wie lange eine KI-Implementierung dauert, ist die ehrliche erste Antwort eine Gegenfrage: welche Implementierung. «Wie lange» klingt nach einer einzigen Frage und ist in Wahrheit drei, denn die Arbeit hinter einem einzelnen automatisierten Factsheet und die Arbeit hinter einer eigenen Reporting-Pipeline unterscheiden sich um eine Grössenordnung, und ein Zeitplan, der für das eine passt, führt beim anderen in die Irre. Das regulierte Umfeld verschärft das zusätzlich. Ein Parallelbetrieb vor dem Umschalten, eine dokumentierte Freigabe, eine Rückfallebene und eine revisionssichere Aufzeichnung sind keine optionalen Zutaten, die sich wegkürzen lassen; sie sind die Teile, die dem Ergebnis erlauben, danach eine FINMA-Anfrage zu beantworten, und sie fügen echte Wochen hinzu, die ein unreguliertes Projekt nie einplant. Es folgen drei realistische Zeitpläne, jeder mit den Phasen darin, und die eine Strecke, die fast jedes Projekt unterschätzt.
Der schnelle Ersterfolg ist ein einzelner, klar abgegrenzter Workflow mit einer sauberen Datenquelle und einer verantwortlichen Person: eine monatliche Abstimmung, ein wiederkehrendes Reporting, ein heute von Hand erstelltes Factsheet. Realistisch dauert er 2–4 Wochen, und die Zeit teilt sich in vier Phasen statt in eine. Die ersten Tage kartieren den Prozess von Anfang bis Ende und messen eine Baseline, damit es eine Zahl gibt, die zu schlagen und später zu belegen ist. Der Build selbst ist oft die kürzeste Phase. Dann kommt der Parallelbetrieb, in dem die Automatisierung ihr Ergebnis neben dem bestehenden manuellen Prozess erzeugt, bis die beiden übereinstimmen: hier verbringt ein reguliertes Projekt Zeit, die ein unreguliertes überspringt. Das Umschalten geschieht erst, wenn diese Abstimmung hält. Grenzen Sie dies ehrlich ab, und der Ersterfolg verdient Vertrauen für alles danach; grenzen Sie ihn als Vorführung ab, und er erzeugt eine Zahl, auf die sich niemand zu stützen traut.
Das mittelgrosse Mandat spannt sich über mehrere Systeme, die nie dafür gebaut wurden, miteinander zu sprechen: ein Reporting-Prozess, der aus einem Portfoliosystem, einer Tabellenebene und einer Dokumentenablage zieht, zum Beispiel. Realistisch 8–12 Wochen, und die Verteilung der Zeit überrascht. Der grösste Teil ist nicht die Automatisierung. Es ist die Diagnose über die Systeme hinweg, die Datenreparatur (dieselbe Zahl in zwei Systemen mit zwei Werten, eine Herkunft, die niemand ganz rückverfolgen kann) und die Integrationsarbeit. Das Modell, oder die Automatisierungslogik, ist eine Minderheit des Aufwands. Der Rollout wird gestaffelt statt umgelegt: ein Team, dann das nächste, jedes auf seinem eigenen Parallelbetrieb. Die Institute, welche die Daten- und Integrationsphase als das eigentliche Projekt behandeln und die Automatisierung als den einfachen Teil, sind jene, deren Zeitplan hält.
Der Plattform-Build ist eine andere Verpflichtung: eine eigene, dokumentierte Reporting-Pipeline, die über Jahre läuft und revisionsbereit bleibt, während sich die zugrunde liegenden Systeme ändern. Realistisch 4–6 Monate, und die zusätzliche Zeit kauft Breite, nicht Politur. Die Phasen weiten sich und umfassen die Governance (wer gibt frei, wer wird benachrichtigt, wenn eine Zahl falsch ist, wie der vorherige Prozess innerhalb einer Stunde wiederhergestellt wird) sowie die Dokumentation und Übergabe, die Ihren eigenen Leuten erlauben, das Ergebnis ohne den Partner im Raum zu betreiben und zu prüfen. Das ist das Mandat, bei dem der Besitz das Ergebnis ist: Ihnen gehören der Workflow, der Code und die Dokumentation vollständig. Die Monate sind nicht der Preis der Langsamkeit; sie sind der Preis eines Ergebnisses, das Sie verteidigen und behalten können.
Über alle drei hinweg wird eine Strecke fast immer unterschätzt: der Einbruch im zweiten Monat. Die ersten Wochen laufen auf Neuheit und den einfachen 80 Prozent des Workflows; dann tauchen die harten 20 Prozent auf (die Randfälle, die Ausnahmen, die eine Person früher nach Urteil behandelte, die Abstimmung, die nicht aufgeht), die Begeisterung kühlt ab, und der Fortschritt scheint zu stocken, genau dort, wo ein Budget Schwung erwartet hat. Es ist kein Zeichen, dass das Projekt scheitert; es ist das Projekt, das auf den Teil trifft, der immer die eigentliche Arbeit war. Der Weg, dies einzuplanen, ist strukturell, nicht motivational: Legen Sie das Go-live nicht in die Senke, halten Sie den alten Prozess geradewegs hindurch im Parallelbetrieb, sehen Sie ein Pufferfenster im Plan vor, statt so zu tun, als wäre die Kurve eine Gerade, und benennen Sie den Einbruch beim Kickoff, damit niemand eine normale Phase für eine Krise hält.
Was einen Zeitplan tatsächlich bewegt, ist selten die Technologie. Es ist die Zahl der beteiligten Systeme, der Zustand der Daten darunter, die Klarheit des Prozesses, bevor jemand automatisiert, und die Taktung der Freigabe im Institut. Ein sauberer Workflow aus einer einzigen Quelle mit einer entscheidungsfreudigen verantwortlichen Person schliesst in Wochen ab; derselbe nominelle Umfang über drei Systeme hinweg, mit umstrittenen Daten und einer monatlichen Freigabesitzung, braucht Monate. Das sind die Hebel, die Sie steuern, und sie sind meist entschieden, bevor eine Zeile Code geschrieben ist. Deshalb misst ein ernsthafter Partner, bevor er überhaupt einen Zeitplan nennt: Ein Datum, das genannt wird, bevor der Prozess kartiert und die Daten gesehen sind, ist eine Vermutung, als Zusage verkleidet.
Die Disziplin unter jedem realistischen Zeitplan ist dieselbe: Grenzen Sie die Arbeit ein, statt sie zu weiten, beginnen Sie mit dem einen Workflow, dessen Baseline Sie beweisen können, und lassen Sie den bewiesenen Fall den nächsten verdienen. So wurde das Reporting über 39+ Fonds bei der IST Investmentstiftung aufgebaut, ein messbarer Workflow nach dem anderen; das bilinguale Factsheet-Mandat, das den Anfang bildete, ging in rund zwei Monaten live, nicht durch eine umfassende Transformation, sondern durch diese Folge, einmal ausgeführt und dann wieder. Wenn Sie einen Zeitplan möchten, der in Ihren eigenen Systemen verankert ist statt in einem generischen Versprechen, ist eine KI-Standortbestimmung der Ausgangspunkt: Sie kartiert den Workflow, misst die Baseline und erfasst den tatsächlichen Umfang, sodass das Datum, um das Sie planen, eines ist, das Sie halten können. Es ist dieselbe Disziplin, die sich durch alles zieht, was wir bauen.