Low-Code ohne Leitplanken wird zur neuen Schatten-IT

Eine Low-Code-Plattform kann ein echtes Organisationsproblem lösen: Fachbereiche müssen nicht für jede kleine Automatisierung auf eine zentrale Entwicklungswarteschlange warten. Sie können Formulare, Workflows und einfache Anwendungen näher an dem Prozess bauen, den sie täglich kennen.

Dieselbe Stärke erzeugt jedoch eine neue Betriebsfrage. Was als persönlicher Helfer beginnt, kann innerhalb weniger Wochen von einem ganzen Team genutzt werden. Es verarbeitet Geschäftsdaten, löst Buchungen aus oder ersetzt eine bisher manuelle Kontrolle. Die Lösung ist geschäftskritisch geworden, ihr Betrieb hängt aber weiterhin an einer einzelnen Person, einem persönlichen Zugang und Wissen, das nirgendwo dokumentiert ist.

Das Problem ist nicht, dass der Fachbereich entwickelt hat. Das Problem ist der unbemerkte Übergang vom Experiment zur betrieblichen Anwendung.

Low-Code-Governance sollte deshalb nicht jede Idee vorab kontrollieren. Sie muss erkennen, wann eine Lösung ihren persönlichen Kontext verlässt – und welche Verantwortung dann hinzukommt.

Schatten-IT ist eine Frage der Verantwortung

Schatten-IT wird häufig über den Beschaffungsweg definiert: Ein Fachbereich nutzt Technik, die nicht von der IT freigegeben wurde. Für Low-Code greift diese Sicht zu kurz. Die Plattform kann offiziell eingeführt, technisch administriert und vertraglich beschafft sein. Einzelne Anwendungen darin können trotzdem außerhalb eines belastbaren Betriebs entstehen.

Entscheidend sind andere Fragen:

• Ist bekannt, dass die Lösung existiert?
• Welchen Prozess und welche Daten berührt sie?
• Wer verantwortet fachliche Regeln und technische Pflege?
• Was geschieht bei Fehlern, Änderungen und Ausfall?
• Kann eine zweite Person die Lösung übernehmen?
• Gibt es eine kontrollierte Produktionsfassung?
• Wann wird die Anwendung überprüft oder beendet?

Fehlen diese Antworten, besitzt die Organisation zwar eine offizielle Plattform, aber weiterhin unsichtbare Abhängigkeiten.

Drei Klassen statt einer Freigabe für alles

Nicht jede kleine Automatisierung benötigt denselben Aufwand. Ein persönlicher Flow, der eigene Erinnerungen sortiert, ist anders zu behandeln als eine Anwendung, mit der ein Team Kundenfreigaben erteilt.

Ein mittelstandstaugliches Modell kann drei Klassen unterscheiden:

Klasse	Typische Reichweite	Mindestregel
persönliches Werkzeug	eine Person, geringe Auswirkung, keine zentrale Prozessabhängigkeit	zulässige Plattform und Datenquellen, eigene Verantwortung
geteilte Teamlösung	mehrere Nutzer, gemeinsamer Ablauf, vertretbare Ausfallfolge	fachlicher Owner, Stellvertretung, Inventar, Supportweg und geregelte Übergabe
geschäftskritische Anwendung	wesentlicher Prozess, sensible Daten oder erhebliche Fehlerfolge	Produktverantwortung, Entwicklungs-/Test-/Produktionsweg, Abnahme, Monitoring, Wiederherstellung und Ausstieg

Die Einordnung richtet sich nicht allein nach der Zahl der Nutzer. Eine von zwei Personen verwendete Automatisierung kann kritisch sein, wenn sie Zahlungen anstößt oder Zugriffsrechte vergibt. Umgekehrt kann ein breit genutzter Informationshelfer ohne Schreibzugriff ein begrenztes Risiko besitzen.

Der Übergang braucht erkennbare Auslöser

Eine Lösung wird nicht automatisch an einem festen Geburtstag „produktiv“. Sie verändert ihren Charakter durch Nutzung und Wirkung. Deshalb braucht die Organisation Übergangskriterien.

Eine erneute Bewertung ist mindestens sinnvoll, wenn:

• weitere Personen oder Bereiche die Lösung nutzen,
• der Ablauf für einen Geschäftstermin oder eine Leistung notwendig wird,
• sensible oder besonders schützenswerte Daten verarbeitet werden,
• Daten in führenden Systemen geschrieben oder gelöscht werden,
• Freigaben, Berechtigungen oder Zahlungen ausgelöst werden,
• ein Ausfall nicht mehr ohne Weiteres manuell überbrückt werden kann,
• der Ersteller die Rolle wechselt oder das Unternehmen verlässt,
• externe Nutzer, neue Connectoren oder zusätzliche Systeme hinzukommen.

Diese Kriterien lassen sich zum Teil technisch beobachten. Die fachliche Bedeutung muss trotzdem eine verantwortliche Person bewerten.

Empowerment und Governance sind kein Widerspruch

Eine Organisation kann auf das Risiko mit einer zentralen Vorabfreigabe für jede App und jeden Flow reagieren. Das schafft Übersicht, nimmt der Plattform aber einen wesentlichen Nutzen: kleine Probleme schnell und nah am Prozess zu lösen.

Die bessere Leitfrage lautet: Welche sicheren Wege können dezentral genutzt werden, ohne jedes Mal neu verhandelt zu werden?

Für Microsoft Power Platform beschreibt Microsoft selbst Governance als Zusammenspiel aus Zielklarheit, Rollen, Umgebungen, Datenrichtlinien, Monitoring und Application Lifecycle Management. Die Dokumentation zu Rollen und Verantwortlichkeiten unterscheidet unter anderem Plattformverantwortung, Administration, Fachbereich, Informationsschutz und Support. Dieses konkrete Rollenmodell ist produktspezifisch. Das zugrunde liegende Prinzip gilt jedoch allgemeiner: Eine Low-Code-Plattform benötigt sowohl Befähigung als auch einen verantworteten Betriebsrahmen.

Governance wird dabei zu einer Art befestigtem Weg:

• Für persönliche Lösungen steht ein einfacher, zulässiger Bereich bereit.
• Für Teamlösungen existiert ein kurzer Registrierungs- und Übergabeprozess.
• Für kritische Lösungen gibt es wiederverwendbare Entwicklungs-, Test- und Betriebsstandards.
• Die Regeln werden strenger, wenn Daten, Reichweite und Fehlerfolge wachsen.

So muss nicht jede Lösung wie ein klassisches Großprojekt behandelt werden. Kritische Anwendungen werden aber auch nicht dauerhaft wie private Tabellenkalkulationen betrieben.

Sieben Leitplanken für einen tragfähigen Betrieb

1. Eine Plattformverantwortung festlegen

Jemand muss die Regeln der Plattform verantworten: zulässige Umgebungen, Rollen, Connectoren, Inventar, Kosten, Supportmodell und Eskalation. Das ist mehr als technische Administration.

Die Plattformverantwortung entscheidet nicht jede fachliche App-Funktion. Sie schafft den Rahmen, in dem Fachbereiche verantwortlich entwickeln können.

2. Fachlichen und technischen Owner trennen

Der fachliche Owner verantwortet Zweck, Prozessregeln, Nutzerkreis und Priorität. Der technische Owner sorgt dafür, dass die Lösung wartbar, übertragbar und im vereinbarten Rahmen betrieben wird.

In kleinen Organisationen können beide Rollen von derselben Person ausgeübt werden. Gedanklich sollten sie getrennt bleiben. Sonst ist bei einer Änderung unklar, ob eine technische Möglichkeit oder eine fachliche Regel zur Diskussion steht.

Wie Rollen in Entscheidungsrechte und Berechtigungen übersetzt werden, vertieft der Beitrag „Verantwortlichkeiten als Voraussetzung für skalierbaren IT-Betrieb“.

3. Datenflüsse statt nur Oberflächen prüfen

Eine einfache App kann über Connectoren auf viele Systeme zugreifen. Die sichtbare Eingabemaske sagt wenig darüber aus, welche Daten gelesen, kombiniert, versendet oder verändert werden.

Für geteilte und kritische Lösungen sollte daher dokumentiert sein:

• welche Datenquellen und Zielsysteme beteiligt sind,
• mit welcher Identität die Verbindung arbeitet,
• welche Daten gelesen, geschrieben oder gelöscht werden,
• welche externen Dienste beteiligt sind,
• welche Berechtigungen tatsächlich benötigt werden.

Bei Microsoft Power Platform können Datenrichtlinien bestimmte Connectoren gruppieren oder blockieren und ihren Geltungsbereich auf Umgebungen beziehen. Das ist eine konkrete technische Leitplanke, ersetzt aber nicht die fachliche Entscheidung über zulässige Datenflüsse.

4. Persönliche Identitäten aus kritischen Abläufen lösen

Ein häufiges Betriebsrisiko entsteht, wenn eine Anwendung oder Automatisierung an den Verbindungen ihres Erstellers hängt. Beim Passwortwechsel, Rechteentzug oder Austritt kann der Ablauf unerwartet ausfallen.

Nicht jede Plattform unterstützt dieselben technischen Identitätsmodelle. Die Grundregel bleibt: Für einen kritischen Prozess muss erkennbar sein, unter welcher Identität er arbeitet, wer diese verantwortet und wie die Übergabe erfolgt. Gemeinsame Konten ohne Nachvollziehbarkeit sind dafür keine gute Abkürzung.

5. Entwicklung, Test und Produktion angemessen trennen

Eine Änderung sollte nicht erstmals im produktiven Prozess erprobt werden. Je kritischer die Lösung, desto wichtiger werden eine kontrollierte Testumgebung, definierte Testfälle, Freigabe und ein Rückfallweg.

Microsoft beschreibt in den Grundlagen des Application Lifecycle Management unter anderem unterschiedliche Umgebungen, Lösungen, Versionskontrolle und automatisierte Bereitstellung. Nicht jede Team-App benötigt den vollen Werkzeugumfang. Eine geschäftskritische Lösung braucht jedoch einen reproduzierbaren Weg von Änderung zu Produktion.

Das NIST Secure Software Development Framework ist nicht speziell für Low-Code geschrieben. Seine Kernaussage ist trotzdem relevant: Sichere Entwicklungspraktiken müssen in den verwendeten Lebenszyklus integriert werden. Die visuelle Entwicklungsoberfläche hebt Anforderungen an Schutz, Prüfung und nachvollziehbare Änderungen nicht auf.

6. Support und Wiederherstellung vor dem Ausfall klären

Nutzer müssen wissen, wo sie eine Störung melden. Der Support muss erkennen können, welche Lösung betroffen ist, wer fachlich entscheidet und ob ein manueller Ersatzprozess existiert.

Für kritische Anwendungen gehören mindestens dazu:

• fachlicher und technischer Ansprechpartner,
• Abhängigkeiten und verwendete Verbindungen,
• letzte freigegebene Fassung,
• bekannte Fehler und Einschränkungen,
• Wiederherstellungs- oder Neuaufbauweg,
• manueller Fallback,
• Eskalation zum Plattform- oder Hersteller-Support.

Eine exportierte Datei ist nur dann ein Backup, wenn sie sich auch in einer kontrollierten Umgebung wiederherstellen lässt. Die Grundsätze aus „Ein Backup ist erst nach einem erfolgreichen Restore belastbar“ gelten deshalb auch für Low-Code-Artefakte und ihre Abhängigkeiten.

7. Nutzung und Lebenszyklus regelmäßig prüfen

Low-Code-Plattformen senken die Hürde für neue Lösungen. Ohne Aufräumprozess wächst damit auch die Zahl verwaister Apps, ungenutzter Flows und überholter Verbindungen.

Ein Review sollte nicht nur fragen, ob die Anwendung noch gestartet wird. Zu klären sind:

• Besteht der Geschäftszweck weiterhin?
• Sind Owner und Stellvertretung noch korrekt?
• Stimmen Nutzerkreis und Berechtigungen?
• Funktionieren Verbindungen und Supportweg?
• Sind Kosten und Lizenzen noch angemessen?
• Muss die Lösung konsolidiert, professionalisiert oder beendet werden?

Der Leitfaden zur skalierten Power-Platform-Governance empfiehlt eine reifeabhängige Weiterentwicklung von Rollen, Umgebungen, Überwachung und Regeln. Für den Mittelstand bedeutet das nicht zwingend ein eigenes Center of Excellence. Es bedeutet, dass die Leitplanken mit der tatsächlichen Nutzung wachsen müssen.

Konstruiertes Beispiel: Der persönliche Flow wird zum Produktionsprozess

Das folgende Beispiel ist konstruiert.

Eine Mitarbeiterin erstellt einen Flow, der Anhänge aus einem Funktionspostfach in einer gemeinsamen Ablage speichert und eine Benachrichtigung versendet. Anfangs erleichtert er nur ihre persönliche Arbeit. Nach und nach verlässt sich die gesamte Auftragsbearbeitung darauf.

Der Flow läuft weiterhin mit der persönlichen Verbindung der Erstellerin. Es gibt keine dokumentierte Vertretung, keine Überwachung und keine Liste der verarbeiteten Postfächer. Beim Stellenwechsel verliert das Konto eine Berechtigung. Eingehende Dokumente bleiben unbemerkt liegen.

Die falsche Schlussfolgerung wäre, Fachbereichen künftig jede Automatisierung zu verbieten. Die richtige organisatorische Reaktion setzt früher an: Sobald der Ablauf geteilt und für die Auftragsbearbeitung notwendig wurde, hätte er als Teamlösung registriert, einem fachlichen Owner zugeordnet und technisch übergabefähig gemacht werden müssen.

Wann Low-Code nicht die passende Lösung ist

Leitplanken machen nicht jeden Anwendungsfall geeignet. Eine andere Umsetzung sollte geprüft werden, wenn:

• extrem hohe Last oder sehr kurze Antwortzeiten entscheidend sind,
• komplexe Transaktionen und Konsistenzregeln über viele Systeme bestehen,
• die Plattform notwendige Sicherheits- oder Integrationsanforderungen nicht erfüllt,
• umfangreiche automatisierte Tests und tiefgreifende Versionskontrolle nötig sind,
• eine langfristige Kernanwendung ohne realistische Export- oder Wechselmöglichkeit entstünde,
• der Lizenz- und Betriebsaufwand den Nutzen der schnellen Entwicklung übersteigt.

Low-Code und klassische Entwicklung sind dabei keine Gegner. Eine Lösung kann als Prototyp beginnen, später professionell auf der Plattform weiterbetrieben oder bewusst in eine andere Architektur überführt werden. Diese Entscheidung sollte am Betrieb und nicht am Stolz des Erstellers hängen.

Ein Minimalmodell für den Start

Eine kleine Organisation benötigt nicht sofort ein umfangreiches Governance-Handbuch. Für den Einstieg reichen fünf verbindliche Artefakte:

1. eine Liste der vorhandenen geteilten und kritischen Lösungen,
2. ein Owner mit Stellvertretung je Lösung,
3. eine Einstufung nach Daten, Reichweite und Fehlerfolge,
4. ein definierter Übergang in Test und Produktion für kritische Lösungen,
5. ein regelmäßiger Review mit Entscheidung über Weiterbetrieb, Verbesserung oder Stilllegung.

Die Prozessfrage kommt davor. Der Beitrag „Digitalisierung vor dem Toolkauf“ hilft zu prüfen, ob der zugrunde liegende Ablauf überhaupt automatisierungsreif ist. Low-Code verkürzt die technische Umsetzung. Es übernimmt nicht die Entscheidung, welcher Prozess gelten soll.

Der erste sinnvolle Schritt ist daher keine neue Verbotsliste. Er ist eine Bestandsaufnahme: Welche fünf Low-Code-Lösungen würden den Betrieb heute am stärksten treffen, wenn ihr Ersteller morgen nicht verfügbar wäre? Für genau diese fünf werden Owner, Datenfluss, Support und Übergabe zuerst geklärt.