Die Fachabteilung baut selbst

Low-Code- und No-Code-Plattformen ermöglichen es Fachabteilungen, Prozesse zu digitalisieren, ohne für jede Anwendung ein IT-Ticket zu stellen. Statt monatelang auf die IT zu warten, baut die Fachabteilung ihre Lösung selbst, mit grafischen Werkzeugen statt mit Programmierung. Marktbeobachter wie Gartner erwarten, dass ein Großteil der neuen Anwendungen künftig mit solchen Werkzeugen entsteht. Die Entwicklung von Software ist damit nicht mehr allein Sache der IT.

Für Banken ist das zweischneidig. Einerseits ist es ein Effizienzgewinn, weil die IT-Engpässe umgangen werden und die Fachabteilung schneller zu Lösungen kommt. Andererseits ist es ein Kontrollrisiko, weil Anwendungen entstehen, die niemand in der IT überblickt, dokumentiert oder absichert. Genau diese Spannung zwischen Geschwindigkeit und Kontrolle ist die eigentliche Herausforderung von Low-Code und No-Code im regulierten Bankenumfeld.

Das bekannte Problem im neuen Gewand

Die Aufsicht kennt dieses Problem bereits, wenn auch unter anderem Namen. Selbstgebaute Anwendungen in Fachabteilungen, oft in Tabellenkalkulationen, sind seit Langem ein Thema der Bankenaufsicht, das unter dem Begriff der individuellen Datenverarbeitung geführt wird. Die Risiken sind dieselben: Anwendungen, die geschäftskritisch werden, ohne den Kontrollen zu unterliegen, die für die offizielle IT gelten. Fehler bleiben unentdeckt, das Wissen hängt an einzelnen Personen, und im Prüfungsfall fehlt die Nachvollziehbarkeit.

Low-Code und No-Code sind die moderne, mächtigere Variante dieses alten Problems. Was früher eine Tabellenkalkulation war, ist heute eine selbstgebaute Anwendung mit Datenbank und Schnittstellen. Die Möglichkeiten sind größer, und damit sind auch die Risiken größer. Wer die Lehren aus dem Umgang mit der individuellen Datenverarbeitung nicht auf Low-Code und No-Code überträgt, wiederholt einen Fehler, den die Aufsicht längst benannt hat.

Die richtige Abstufung finden

Der Schlüssel zur Governance ist eine kluge Abstufung nach Kritikalität. Nicht jede selbstgebaute Anwendung braucht dieselbe Kontrolle. Eine kleine Hilfsanwendung, die ein Team für sich nutzt und die keine geschäftskritischen Daten verarbeitet, kann mit leichter Hand behandelt werden. Eine Anwendung dagegen, die in regulatorisch relevante Prozesse eingreift, Kundendaten verarbeitet oder zur Grundlage von Entscheidungen wird, muss denselben Kontrollen unterliegen wie offizielle IT.

Diese Abstufung verhindert zwei Fehler zugleich. Sie verhindert, dass jede kleine Anwendung im bürokratischen Prozess erstickt, und sie verhindert, dass eine kritische Anwendung unkontrolliert bleibt. Die Kunst besteht darin, die Kritikalität früh und richtig einzuschätzen, damit die Kontrolle dort greift, wo sie nötig ist, und dort entfällt, wo sie nur bremst.

Sichtbarkeit als erste Pflicht

Bevor man etwas kontrollieren kann, muss man wissen, dass es existiert. Die erste Pflicht jeder Governance für Low-Code und No-Code ist deshalb, die gebauten Anwendungen sichtbar zu machen. Ein Verzeichnis, in dem erfasst ist, welche Anwendung von wem für welchen Zweck gebaut wurde, ist die Grundlage für alles Weitere. Ohne diese Sichtbarkeit bleibt der Wildwuchs unsichtbar, bis ein Fehler oder eine Prüfung ihn ans Licht bringt.

Wir helfen Ihnen, eine Governance für Low-Code und No-Code aufzubauen, die den Effizienzgewinn der Fachabteilungen nutzt, die kritischen Anwendungen kontrolliert und die Lehren aus dem Umgang mit der individuellen Datenverarbeitung berücksichtigt. Beginnen Sie mit einer Sprechstunde.

Governance statt Verbot

Die falsche Antwort wäre ein Verbot. Wer Low-Code und No-Code untersagt, verschenkt den Effizienzgewinn und treibt die Fachabteilungen in den Wildwuchs, denn gebaut wird trotzdem, nur dann im Verborgenen. Die richtige Antwort ist eine Governance, die den Einsatz ordnet: klare Regeln, welche Anwendungen die Fachabteilung selbst bauen darf und welche der IT vorbehalten bleiben, ein Verzeichnis der gebauten Anwendungen und Kontrollen für die kritischen unter ihnen.

Mehr zum Thema: Nearshoring als Antwort auf IT-Fachkräftemangel im Banking: Was funktioniert und was nicht. und RPA war ein Fehler. Hier ist, was stattdessen funktioniert..

Eine gute Governance erlaubt das Bauen, aber sie macht es sichtbar und kontrollierbar. Sie unterscheidet zwischen der unkritischen Anwendung, die ein Team für sich nutzt, und der geschäftskritischen Anwendung, die denselben Kontrollen unterliegen muss wie offizielle IT. Wir helfen Ihnen, eine solche Governance für Low-Code und No-Code zu entwickeln, die den Effizienzgewinn nutzt und das Kontrollrisiko beherrscht. Beginnen Sie mit einer Sprechstunde.