Selbst gebaute Apps brauchen einen festen Platz im Betrieb

Eine kleine App aus dem Fachbereich kann ein echtes Problem lösen. Ein Formular ersetzt eine Excel-Liste. Eine Freigabe läuft schneller. Ein Team muss nicht mehr auf ein großes IT-Projekt warten. Genau darin liegt der Reiz von Low-Code und No-Code. Fachabteilungen bauen mit vorgefertigten Bausteinen Anwendungen, Automationen oder Workflows, ohne jede Funktion klassisch entwickeln zu lassen.

Für den IT-Betrieb endet die Geschichte aber nicht beim schnellen Nutzen. Sobald eine selbst gebaute App Daten verarbeitet, Berechtigungen vergibt, Entscheidungen vorbereitet oder einen Arbeitsprozess steuert, wird sie Teil der Service-Landschaft. Dann braucht sie Zuständigkeit, Support, Überblick und klare Grenzen. Sonst entsteht keine Entlastung, sondern eine zweite, schwer sichtbare Anwendungsschicht neben den offiziellen Systemen.

Warum Low-Code den Betrieb betrifft

Low-Code-Plattformen wie Microsoft Power Platform sollen es Teams erleichtern, Apps, Workflows und Auswertungen schneller zu erstellen. Microsoft beschreibt dafür unter anderem Governance-Fragen, Umgebungskonzepte, Richtlinien, Datenzugriffe und den Aufbau eines Center of Excellence. Das ist kein reines Herstellerdetail. Dahinter steckt eine Grundfrage für ITSM-Generalisten: Wer sorgt dafür, dass aus einer hilfreichen Fachbereichslösung ein verlässlicher Service wird?

Der Unterschied ist wichtig. Ein Prototyp darf experimentell sein. Eine App, die täglich von Mitarbeitern genutzt wird, braucht andere Regeln. Wer darf sie ändern. Wer erkennt Ausfälle. Was passiert, wenn der Ersteller die Abteilung verlässt. Welche Daten fließen durch die App. Und wie wird verhindert, dass ein schneller Workaround unbeabsichtigt Kundendaten, Personaldaten oder Vertragsinformationen an falsche Stellen bringt.

Der blinde Fleck liegt selten in der Technik

Die technische Plattform bringt meist bereits Verwaltungsfunktionen mit. Es gibt Umgebungen, Rollen, Sicherheitsrichtlinien, Konnektoren, Protokolle und Monitoring-Möglichkeiten. Das Problem entsteht eher dort, wo diese Funktionen nicht in einen Betriebsprozess übersetzt werden. Eine Richtlinie allein beantwortet noch nicht, wer sie regelmäßig prüft. Ein Inventar allein löst noch nicht, welche App geschäftskritisch ist. Ein Freigabefluss allein sagt noch nicht, wie eine Änderung angekündigt oder zurückgenommen wird.

Für IT Service Management ist deshalb nicht entscheidend, ob jede kleine App sofort wie eine Kernanwendung behandelt wird. Entscheidend ist eine sinnvolle Einordnung. Kleine Hilfswerkzeuge brauchen leichte Regeln. Apps mit Datenzugriff, mehreren Nutzern oder Prozesswirkung brauchen mehr Kontrolle. Kritische Lösungen gehören in ein klares Betriebsmodell mit Verantwortlichen, Dokumentation, Supportweg und Änderungslogik.

Welche Fragen vor der Freigabe geklärt sein sollten

Ein pragmatischer Einstieg ist eine kurze Betriebsprüfung vor der breiten Nutzung. Sie muss nicht bürokratisch sein, sollte aber die wichtigsten Risiken sichtbar machen.

• Zweck: Welches konkrete Problem löst die App und welcher Geschäftsprozess hängt daran?
• Verantwortung: Wer ist fachlicher Besitzer, wer administriert die Lösung und wer entscheidet über Änderungen?
• Daten: Welche Daten werden verarbeitet, gespeichert, weitergeleitet oder mit anderen Diensten verbunden?
• Berechtigungen: Wer darf die App nutzen, wer darf sie ändern und wie werden Zugriffe entzogen?
• Support: Wo melden Nutzer Störungen und ab wann wird der Service Desk eingebunden?
• Lebenszyklus: Wann wird geprüft, ob die App noch gebraucht wird, ersetzt werden muss oder archiviert werden kann?

Diese Fragen klingen einfach. Im Alltag verhindern sie aber, dass Low-Code-Lösungen nach dem ersten Erfolg unsichtbar weiterwachsen. Gerade bei Automationen ist das wichtig. Ein automatischer Ablauf kann eine Aufgabe beschleunigen, aber auch Fehler schnell vervielfachen. Wenn niemand weiß, wo der Ablauf beginnt, welche Datenquelle genutzt wird und wer ihn stoppen darf, wird aus Komfort ein Betriebsrisiko.

Ein Center of Excellence ist kein Kontrollturm

Microsoft beschreibt den CoE Starter Kit als Sammlung von Komponenten, mit denen Organisationen Einführung, Governance und Nutzung der Power Platform besser steuern können. Für ITSM-Generalisten ist daran weniger der Werkzeugname wichtig als die Betriebslogik. Ein Center of Excellence sollte nicht nur Verbote sammeln. Es sollte Transparenz schaffen, gute Vorlagen bereitstellen, Risiken früh erkennen und Fachbereiche dabei unterstützen, Lösungen sauber aufzubauen.

Das gelingt besser, wenn die IT nicht als Bremse auftritt. Fachbereiche bauen Low-Code-Lösungen oft deshalb, weil echte Reibung besteht. Ein Prozess ist zu langsam, ein System deckt einen Sonderfall nicht ab oder eine manuelle Übergabe kostet jeden Tag Zeit. Diese Energie ist wertvoll. Sie braucht aber einen Rahmen, der zwischen Experiment, Teamhilfe und produktivem Service unterscheidet.

Was in den Servicekatalog gehört

Nicht jede selbst gebaute App muss prominent im Servicekatalog stehen. Aber jede produktiv genutzte Lösung sollte irgendwo auffindbar sein. Mindestens intern sollte klar sein, welche App existiert, welchem Bereich sie gehört, welche Daten sie nutzt und wie wichtig sie für den Arbeitsablauf ist. Für stärker genutzte Lösungen kommen zusätzlich Supportzeiten, Eskalationsweg, Änderungsfenster und Abhängigkeiten hinzu.

Damit entsteht ein praktischer Vorteil. Der Service Desk kann Nutzer besser führen. Sicherheits- und Datenschutzfragen lassen sich gezielter prüfen. Änderungen an zentralen Systemen treffen nicht überraschend eine unbekannte Automation. Und Fachbereiche bekommen eine realistische Antwort darauf, wann ihre Lösung nur Teamhilfe ist und wann sie wie ein Service behandelt werden muss.

Der richtige Maßstab ist Betriebsreife

Low-Code braucht keine Vollbremsung. Es braucht einen Reifegrad, der zum Risiko passt. Eine einfache interne Checkliste reicht oft für kleine Lösungen. Bei Apps mit personenbezogenen Daten, externen Verbindungen, Prozessfreigaben oder hoher Nutzung sollte ein stärkeres Gate greifen. Wichtig ist, dass diese Schwellen vorher bekannt sind. Dann wird Governance nicht als Überraschung erlebt, sondern als normaler Teil des Wegs von der Idee zur produktiven Nutzung.

Der wichtigste Satz für den Betrieb lautet deshalb: Selbst gebaute Apps dürfen schnell entstehen, aber sie dürfen nicht ohne Adresse, Besitzer und Rückweg produktiv bleiben. Wer diese drei Punkte klärt, schützt nicht nur die IT. Er schützt auch die Fachbereiche vor Lösungen, die im falschen Moment niemand mehr erklären, ändern oder reparieren kann.

Quellen und Einordnung

• Microsoft Learn: Governance considerations for Power Platform.
• Microsoft Learn: Microsoft Power Platform Center of Excellence Starter Kit.