Wenn ein Finanzinstitut beschliesst, einen regulierten Workflow zu automatisieren, stellt sich die Beschaffungsfrage meist in einer irreführenden Form: Sollen wir einen Entwickler einstellen oder eine Agentur beauftragen, als wären beide bloss die günstigere und die teurere Variante desselben Einkaufs. Das sind sie nicht. Ein Entwickler und eine Implementierungsagentur sind zwei verschiedene Verpflichtungen, und der Unterschied liegt nicht in der Kopfzahl oder im Stundensatz, sondern darin, wo die Verantwortung für den fertigen Prozess zu ruhen kommt. Ein Entwickler führt eine Spezifikation aus, die Sie liefern; ein Implementierungspartner verantwortet ein Ergebnis, das Sie definieren. In einem unregulierten Umfeld kann die Unterscheidung verschwimmen, weil ein grober Build, der grösstenteils funktioniert, oft genügt. In der FINMA-regulierten Finanzwelt verschwimmt sie gar nicht, denn die Teile, die ein Entwickler nicht berührt (der Prozess, die Daten, die Nachvollziehbarkeit, die Freigabe), sind genau jene, die entscheiden, ob die Automatisierung ihre erste Prüfung übersteht.
Beginnen Sie mit dem Entwickler, denn das ehrliche Argument für einen ist real und verdient, benannt zu werden. Ein Entwickler, ob freischaffend oder ein kleines Build-Team, verwandelt eine klare Spezifikation in funktionierende Software. Geben Sie einer kompetenten Entwicklerin einen kartierten Prozess, eine definierte Datenquelle, eine vereinbarte Erfolgskennzahl und eine für Compliance verantwortliche Person, die bereits in Ihrem Institut sitzt, und sie wird die Sache gut und oft schnell bauen. Das ist die Bedingung, unter der ein Entwickler die richtige und günstigere Wahl ist: wenn das Denken bereits getan ist und nur eine echte Programmieraufgabe bleibt. Der Fehler entsteht, wenn man die Lage verkennt. Die meisten Institute, die nach einem Entwickler greifen, haben das Denken tatsächlich nicht abgeschlossen; sie haben eine Vorstellung vom Ergebnis und nehmen an, die Spezifikation werde sich unterwegs ergeben, und ein Entwickler, der fürs Programmieren bezahlt wird, hat weder den Auftrag noch den Anreiz, ihnen zu sagen, dass sie es nicht hat.
Eine Implementierungsagentur, oder ein Partner, verkauft etwas strukturell anderes: nicht einen Build, sondern den ganzen Bogen von der Diagnose bis zum verantworteten Ergebnis. Die Arbeit beginnt vor jedem Code, indem der Workflow von Anfang bis Ende kartiert, die Daten, auf denen er läuft, geprüft und repariert und die Baseline etabliert werden, an der das Ergebnis gemessen wird; erst dann folgt der Build, und nach ihm die Integration über Systeme hinweg, die nie dafür gebaut wurden, miteinander zu sprechen, und die Revisionsbereitschaft, die dem Ergebnis erlaubt, danach einer Regulierungsbehörde Antwort zu geben. Das ist ein breiteres Können, als eine einzelne Person trägt, und es ist der Grund, weshalb das Agenturmodell existiert: Der grösste Teil einer regulierten Automatisierung ist Prozess, Daten und Compliance, und nur eine Minderheit davon ist Code. Ein Partner bringt den Mix als Selbstverständlichkeit mit, während ein einzelner Entwickler eine Scheibe davon gut abdeckt und den Rest improvisiert.
Der Test der regulierten Finanzwelt trennt die beiden sauber. Fragen Sie, was an dem Tag geschieht, an dem die Automatisierung eine falsche Zahl erzeugt: wer sie abfängt, bevor sie einen Investor erreicht, wie der vorherige Prozess innerhalb einer Stunde wiederhergestellt wird, wer benachrichtigt wird und wo die Aufzeichnung liegt, die einem internen Prüfer erlaubt, die Entscheidung Monate später zu rekonstruieren. Ein Entwickler, der zu einer Spezifikation baut, hat keinen Grund, all das gestaltet zu haben, weil die Fehlerbehandlung nicht in der Spezifikation stand; ein Implementierungspartner behandelt sie als die Spezifikation, denn in einem kontrollierten Prozess ist die Gestaltung des Fehlerfalls die eigentliche Gestaltung. Dieselbe Asymmetrie zieht sich durch Datenhaltung und Besitz: Ein Partner, der für ein reguliertes Ergebnis geradesteht, kann Ihnen genau sagen, wo Ihre Daten liegen und wer sie berührt, während die Arbeit läuft, und kann Ihnen einen Prozess übergeben, den Sie ohne ihn betreiben und prüfen können. Ein Entwickler, der für eine Aufgabe engagiert ist, denkt selten in diesen Begriffen, und wird selten danach gefragt.
Die besseren Implementierungspartner lösen eine alte Spannung in diesem Markt, jene zwischen der Seniorität, die ein reguliertes Mandat verlangt, und der Breite an Händen, die ein Build erfordert. Die tragfähige Form ist eine senior, verantwortliche Leitung, die die Beziehung, den Umfang und die Antwort auf jede Compliance-Frage besitzt, im Zusammenspiel mit einem breiteren Team dahinter, das die Build-Kapazität liefert. Was einem regulierten Institut zählt, ist nicht die Grösse dieses Teams, sondern zwei Dinge, die es überprüfen kann: dass eine einzige benannte Person für die Lieferung geradesteht, und dass die Regelungen zu Datenhaltung und Zugriff hinter der Arbeit dokumentiert und gerade sind. Ein Partner, der Ihnen dieses Bild zeichnen kann, mit einem Diagramm, bevor ein File den Besitzer wechselt, hat Ihnen gesagt, dass er ein reguliertes Ergebnis bereits verantwortet hat. Einer, der es nicht kann, verkauft Kapazität, nicht Verantwortung.
So gelesen, verdichtet sich die Entscheidung zu einer Regel über das, was Sie bereits besitzen, statt über den Preis. Wo Ihr Institut das Denken wirklich abgeschlossen hat (der Prozess ist kartiert, die Baseline ist gemessen, Integration und Compliance sind intern verantwortet) und nur ein eng gefasster, gut spezifizierter Build bleibt, ist ein Entwickler die effiziente Antwort, und eine Agentur darum herum zu bezahlen heisst, für Arbeit zu bezahlen, die Sie bereits getan haben. Überall dort, wo das Ergebnis selbst von Anfang bis Ende verantwortet werden muss (ein regulierter Workflow, eine systemübergreifende Integration, eine revisionssichere Aufzeichnung, ein Prozess, der weiterlaufen und lange nach dem Go-live aktuell bleiben muss), ist das Agenturmodell nicht die teure Option, sondern die einzige, die Ihnen ein Ergebnis hinterlässt, das Sie verteidigen können. Der Fehler ist, den Build eines Entwicklers zu kaufen und festzustellen, dass Sie den Besitz eines Partners gebraucht hätten, meist bei der ersten Revisionsanfrage.
Die Disziplin unter der Wahl ist eine vertraute: Grenzen Sie die Arbeit ein, statt sie zu weiten, und lassen Sie einen bewiesenen Fall den nächsten verdienen. So wurde das Reporting über 39+ Fonds bei der IST Investmentstiftung aufgebaut, ein messbarer Workflow nach dem anderen, jeder durch Diagnose, Build, Integration und Übergabe geführt, bevor der nächste versucht wurde. Wenn Sie einen Entwickler gegen einen Implementierungspartner abwägen und es auf Belege statt auf den Bauch stützen möchten, ist eine KI-Standortbestimmung der Ausgangspunkt: Sie kartiert den Workflow, die Baseline und den echten Umfang, sodass sich die Beschaffungsfrage von selbst beantwortet. Es ist dieselbe Disziplin, die sich durch alles zieht, was wir bauen.