Low-Code- und No-Code-Plattformen erlauben es, eine funktionierende Automatisierung durch Konfiguration statt durch Code zusammenzusetzen, und das ist eine echte Fähigkeit, kein Spielzeug. Für ein FINMA-reguliertes Institut lautet die ehrliche Frage nicht, ob Low-Code funktioniert, denn das tut es oft, sondern wo seine Grenzen liegen. In einem kontrollierten Prozess treffen diese Grenzen genau die Teile, die entscheiden, ob eine Automatisierung eine Prüfung übersteht: die Daten, die sie berührt, die nachvollziehbare Spur, die sie hinterlässt, und wer sie besitzt an dem Tag, an dem die Plattform ihre Bedingungen ändert. Lesen Sie die Grenzen falsch, wird aus der schnellen, günstigen Option still Ihr Risiko.
Beginnen wir mit dem, wofür sich Low-Code wirklich eignet, denn das Argument dafür ist real. Leichte Integrationen zwischen Systemen, einfache interne Automatisierungen, ein Prototyp, der beweist, dass ein Workflow einen vollständigen Build überhaupt wert ist, bevor sich jemand darauf festlegt: Für eine klar abgegrenzte Aufgabe mit unkritischen Daten und einer Person, die das Ergebnis weiterhin prüft, ist eine Low-Code-Zusammensetzung schneller aufgesetzt und günstiger zu ändern als eigener Code, und dort einen vollen Engineering-Build zu verlangen, ist Überkonstruktion. Der Test für den Sweet Spot ist schlicht: geringes Volumen, einfache Logik, gutmütige Daten und ein Mensch, der kontrolliert. In diesem Rahmen ist Low-Code kein Kompromiss. Es ist das richtige Werkzeug.
Die erste Grenze ist Volumen und Logik. Wenn die Zahl der Fälle steigt und die Logik Verzweigungen bekommt (die Ausnahmen, die eine Person früher nach Urteil behandelte, die Abstimmung, die nicht aufgeht), wird ein Flow, der bei zehn Fällen elegant war, bei zehntausend brüchig. Die visuelle Logik der Plattform, eine Stärke bei einem einfachen Pfad, wird zur Last, die niemand mehr ganz lesen oder testen kann, sobald die echte Komplexität eines regulierten Reporting-Prozesses eintrifft. Was im Prototyp Zeit sparte, beginnt sie zu kosten, denn jede neue Ausnahme ist ein weiterer Kasten, der an ein Diagramm geschraubt wird, das nie dafür gebaut war, diese Last zu tragen.
Die zweite Grenze sind regulierte Daten und Nachvollziehbarkeit, und sie ist jene, die in der Finanzwelt am härtesten beisst. Eine Low-Code-Plattform verarbeitet Ihre Daten typischerweise auf einer Infrastruktur, die Sie nicht kontrollieren, unter Bedingungen, die Sie nicht geschrieben haben, mit einer Herkunft, die Monate später schwer zu rekonstruieren ist, wenn eine interne Prüferin fragt, wie eine Zahl entstanden ist. Zu benennen, wo die Daten liegen, wer sie berührt hat und wie eine Entscheidung zurückverfolgt werden kann, ist in einem FINMA-regulierten Prozess keine Zugabe; es ist die Anforderung. Und es ist genau das, was eine konfigurationsgetriebene Plattform, gebaut, um ihre Verrohrung im Namen der Einfachheit zu verbergen, am wenigsten beantworten kann.
Dann sind da die Kosten, die in der Vorführung nicht auftauchen: der Besitz. Der oberflächliche Reiz von Low-Code sind Tempo und ein scheinbar niedriger Preis, doch die eigentliche Rechnung kommt später und in drei Teilen. Die Automatisierung läuft nur, solange Sie das laufende Abonnement der Plattform weiter bezahlen; die Logik lebt in der Umgebung des Anbieters in einer Form, die Sie nicht sauber exportieren können; und an dem Tag, an dem Sie sie überwachsen, oder der Anbieter die Konditionen ändert oder eine Funktion abschaltet, bauen Sie neu, statt zu migrieren. Ein Low-Code-Flow ist gemietete Fähigkeit. Zu mieten, was wirklich entbehrlich ist, ist vernünftig. Zu mieten, was still tragend geworden ist, ist der teure Fehler.
Die Entscheidung ist also nicht abstrakt Low-Code gegen Custom, sondern eine Lesart des Workflows, der vor Ihnen liegt. Mieten Sie mit Low-Code, was wenig Volumen hat, wenig sensibel und wirklich vorübergehend ist, und bezahlen Sie dort nicht für eigenes Engineering. Besitzen Sie, mit einem richtigen Build, was hohes Volumen hat, logikschwer ist, regulierte Daten berührt oder einer Prüfung standhalten und über Jahre weiterlaufen muss, denn das sind die Automatisierungen, bei denen die gemieteten Grenzen zu Ihrem Risiko werden. Der Fehler ist, das anfängliche Tempo eines Low-Code-Builds über die Architektur eines Prozesses entscheiden zu lassen, der ohnehin immer tragend sein würde, und die Lücke erst bei der ersten Revisionsanfrage zu entdecken.
Diese Lesart ist das Erste, was eine Standortbestimmung klärt, bevor irgendein Werkzeug gewählt wird: welche Workflows entbehrlich und welche tragend sind, und folglich, was zu besitzen sich lohnt. So wurde das Reporting über 39+ Fonds bei der IST Investmentstiftung aufgebaut, als eine eigene Pipeline, die das Institut selbst betreibt und prüft, statt als gemieteter Flow, ein messbarer Workflow nach dem anderen. Wenn Sie eine Low-Code-Abkürzung gegen einen eigenen Build abwägen und es anhand der Gestalt der Arbeit statt des Tempos der Vorführung entscheiden möchten, ist eine KI-Standortbestimmung der Ausgangspunkt: Sie kartiert den Workflow, die Daten und den echten Umfang, sodass sich die Frage nach dem Bauansatz von selbst beantwortet. Es ist dieselbe Disziplin, die sich durch alles zieht, was wir bauen.