Eine Sachbearbeiterin aus dem Bereich Netzanschluss hat das Problem gelöst, an dem zwei IT-Projekte gescheitert waren. Mit einer Plattform, die Anwendungen ohne klassische Programmierung ermöglicht, baute sie eine Übersicht, die alle Anträge über drei Systeme hinweg verfolgt. Die Bearbeitungszeiten sanken, zwei Nachbarteams übernahmen das Werkzeug, und niemand wollte mehr ohne es arbeiten. Zwei Jahre später wechselte die Kollegin den Arbeitgeber. Nach dem nächsten Systemupdate fiel die Anwendung aus, und es zeigte sich: Kein Zugang, keine Dokumentation, kein Verantwortlicher. Und bei der Fehlersuche fiel noch etwas auf, das schwerer wog als der Ausfall: Die Anwendung hatte Kundendaten über ein Konto verarbeitet, von dem im Unternehmen niemand wusste. Das Werkzeug hatte ein echtes Problem gelöst und dabei unbemerkt ein größeres geschaffen.
Die Eigenentwicklung der Fachbereiche lässt sich nicht verbieten, nur in die Unsichtbarkeit treiben. Die Wahl lautet deshalb nicht ja oder nein, sondern sichtbar oder unsichtbar.
Bei einem Energieversorger, für den ich eine solche Bestandsaufnahme in einem Beratungsmandat geleitet habe, förderte die erste systematische Suche über achtzig Anwendungen zutage, die Fachbereiche in Eigenregie gebaut hatten und von denen die IT nichts wusste. Tabellen mit komplexen Makros, kleine Datenbanken, automatisierte Auswertungen, Werkzeuge auf Mietplattformen. Ein Teil davon war harmlos. Ein anderer Teil verarbeitete Kundendaten, speiste Berichte an die Geschäftsführung oder steuerte Abläufe, auf die sich andere Bereiche verließen. Das Bemerkenswerte war nicht die Zahl. Es war die Tatsache, dass jede dieser Anwendungen ein reales Problem löste, für das es keine andere Lösung gegeben hatte.
Genau darin liegt der Schlüssel zum Umgang mit dem Phänomen. Drei Hebel machen aus dem Wildwuchs eine gesteuerte Fähigkeit.
Schatten-IT, also Anwendungen und Werkzeuge, die außerhalb der offiziellen IT entstehen und betrieben werden, ist kein neues Phänomen und kein Zeichen böswilliger Mitarbeitender. Sie ist der sichtbarste Beweis dafür, dass der Bedarf der Fachbereiche schneller wächst als die Kapazität der IT. Wo ein berechtigtes Anliegen auf eine lange Warteliste trifft, entsteht die Lösung eben am offiziellen Weg vorbei, leise und mit den Mitteln, die verfügbar sind. Verbote ändern daran nichts. Sie verlagern die Entwicklung nur tiefer in die Unsichtbarkeit, wo weder Datenschutz noch Betriebssicherheit je geprüft werden.
Zwei Entwicklungen verschärfen die Lage derzeit erheblich. Plattformen für Entwicklung ohne Programmierkenntnisse, unter den Begriffen Low-Code und No-Code etabliert, senken die Hürde für entwickelnde Fachanwender, international als Citizen Developers bezeichnet, von Jahren auf Wochen. Und KI-gestützte Werkzeuge senken sie erneut, von Wochen auf Stunden, denn inzwischen genügt eine präzise Beschreibung, um eine funktionierende Anwendung zu erzeugen. Die durch Automatisierung freigesetzte Kapazität trifft in den Fachbereichen auf Werkzeuge, mit denen sie sich unmittelbar in eigene Lösungen verwandeln lässt. Diese Welle rollt, ob gesteuert oder nicht.
| Merkmal | Unsichtbare Eigenentwicklung | Gesteuerte Eigenentwicklung |
|---|---|---|
| Überblick | niemand kennt den Bestand | Anwendungen sind erfasst |
| Verantwortung | endet mit der Person, die sie erstellt hat | benannt, mit Vertretung |
| Datenschutz und Sicherheit | ungeprüft | nach Risiko geprüft |
| Geschwindigkeit der Fachbereiche | hoch | bleibt hoch |
Die letzte Zeile ist die wichtigste, denn sie räumt mit dem verbreiteten Einwand auf, Steuerung koste die Geschwindigkeit, derentwegen die Eigenentwicklung überhaupt entsteht. Richtig gestaltet, nimmt Steuerung der Eigenentwicklung nichts von ihrem Tempo. Sie nimmt ihr nur die Unsichtbarkeit.
Der erste Schritt ist nicht die Regel, sondern die Bestandsaufnahme, und sie gelingt nur unter einer Bedingung: ohne Sanktionen. Wer die Meldung vorhandener Eigenentwicklungen mit Vorwürfen quittiert, erfährt von einem Bruchteil des Bestands und treibt den Rest tiefer ins Verborgene. Die Bestandsaufnahme ist ein Angebot: Was gemeldet wird, darf weiterlaufen, bis es geprüft ist, und wird beim Überführen in einen sicheren Betrieb unterstützt.
Erst dieser Überblick macht steuerbar, was längst existiert. Er zeigt, welche Anwendungen kritische Abläufe tragen, welche Daten außerhalb geschützter Systeme liegen und wo eine technische Altlast heranwächst, die niemand auf der Rechnung hat, weil sie in keinem offiziellen Bestand auftaucht. Ungesteuerter Eigenentwicklung fehlt zudem alles, was den Betrieb einer Anwendung über die Zeit sichert: geregelte Aktualisierungen, nachvollziehbare Versionsstände, eine Vertretung für den Ausfall. Sie ist damit nichts anderes als technische Schuld, die außerhalb der Bücher entsteht, und sie wird wie jede Schuld irgendwann fällig, meist im unpassendsten Moment.
Der zweite Fehler nach dem Verbot ist die Einheitsregel, die jede Tabelle mit Makro denselben Anforderungen unterwirft wie eine Anwendung, die Kundendaten verarbeitet. Eine solche Regel ist in der Praxis nicht durchzuhalten und wird deshalb flächendeckend ignoriert, womit die Steuerung ihre Glaubwürdigkeit verliert, bevor sie wirkt. Wirksam ist die Staffelung nach Risiko: Ein Werkzeug für den eigenen Arbeitsplatz braucht kaum mehr als eine Registrierung. Eine Anwendung, die ein Team nutzt, braucht einen benannten Verantwortlichen, eine Vertretung und eine Mindestdokumentation. Eine Anwendung, die Kundendaten verarbeitet oder Abläufe steuert, auf die sich andere verlassen, gehört unter die vollen Maßstäbe der IT, in regulierten Branchen ohne Ausnahme.
Diese Staffelung folgt demselben Prinzip, das gute Governance in agilen Organisationen auszeichnet: Leitplanken statt Einzelfreigaben, klare Grenzen des Erlaubten statt Prüfung jedes Schritts. Der Unterschied liegt im Gegenstand: Dort geht es um Entscheidungswege und Arbeitsformen, hier um Werkzeuge und Daten. Und die Staffelung schützt vor dem Reflex, der in regulierten Häusern besonders ausgeprägt ist: der pauschalen Absicherung, die jede Bewegung erstickt, weil niemand zwischen einem harmlosen Hilfsmittel und einem echten Risiko unterscheidet.
Verbieten scheitert, Gewährenlassen auch. Der dritte Weg ist eine Arbeitsteilung: Die IT stellt die Umgebung, die Fachbereiche entwickeln darin. Eine freigegebene Plattform mit geregelten Zugängen, angebundenen Datenquellen und zentraler Benutzerverwaltung nimmt den gefährlichsten Teil der Schatten-IT von vornherein aus dem Spiel, nämlich unregistrierte Konten, ungesicherte Ablagen und Insellösungen ohne Zugriffsschutz. Innerhalb dieser Umgebung dürfen die Fachbereiche schnell sein, außerhalb gilt sie nicht als Eigenentwicklung, sondern als Verstoß.
Ein CIO, den ich bei dieser Neuordnung unterstützt habe, verband die Bestandsaufnahme mit einem Tausch: Jede gemeldete Anwendung wurde binnen eines Jahres auf die freigegebene Plattform überführt oder geordnet abgeschaltet, und jeder Fachbereich benannte eine Person, die als Ansprechpartner für Eigenentwicklung qualifiziert wurde. Zwei Jahre später entstanden mehr Anwendungen als je zuvor, aber jede hatte einen Verantwortlichen, eine Vertretung und einen geprüften Umgang mit Daten. Die Geschwindigkeit war geblieben. Verschwunden war nur das Risiko, von dem vorher niemand wusste, wie groß es war. Ein solches Modell verlangt von der Führung ein eigenes Grundverständnis der Technik, denn wer die Werkzeuge nicht einordnen kann, kann weder die Risikoklassen festlegen noch beurteilen, ob die Leitplanken taugen.
Erstens: Wie viele Anwendungen, die Fachbereiche in Eigenregie entwickelt haben, existieren in Ihrem Unternehmen? Wenn Sie diese Zahl nicht kennen, existiert sie dennoch, nur außerhalb Ihrer Steuerung.
Zweitens: Welche dieser Anwendungen würde einen kritischen Ablauf zum Stillstand bringen, wenn die Person, die sie entwickelt hat, das Unternehmen kurzfristig verließe? Und welche verarbeitet Kundendaten in Umgebungen, die nie einer Prüfung unterzogen wurden?
Drittens: Wann startet in Ihrem Haus die erste Bestandsaufnahme ohne Sanktionen? Legen Sie den Termin in das kommende Quartal und definieren Sie zugleich drei Risikoklassen, bevor eine Prüfung oder ein Ausfall diese Aufgabe übernimmt, dann allerdings zu Bedingungen, die nicht mehr Sie bestimmen.
Die Eigenentwicklung der Fachbereiche ist gekommen, um zu bleiben, und KI beschleunigt sie weiter. Ein Verbot erzeugt keine Sicherheit, sondern Unsichtbarkeit, und Unsichtbarkeit ist die teuerste Form des Risikos, weil sie sich jeder Steuerung entzieht. Die Aufgabe der Führung ist deshalb nicht, den Wildwuchs zu beklagen oder zu untersagen, sondern ihn in eine Fähigkeit zu verwandeln: sichtbar, nach Risiko gestaffelt und auf einer Umgebung, welche die gefährlichen Abkürzungen überflüssig macht.
Die Energie, mit der Ihre Fachbereiche sich selbst helfen, ist keine Bedrohung. Sie ist ungenutztes Kapital, das nur eine Ordnung braucht, um zu wirken.
Technical Literacy für Führungskräfte – Risikoklassen und Leitplanken kann nur festlegen, wer die Werkzeuge selbst einordnen kann.
Insourcing durch KI – Dieselbe Technik, die Fachbereiche zu Entwicklern macht, holt auch ausgelagerte Arbeit zurück ins Haus.
Alle Impulse finden Sie in der Übersicht.
