Schatten-IT im Unternehmen — wenn Mitarbeiter eigene Dashboards und Apps bauen

Uns erreichen zunehmend Berichte, die alle in eine ähnliche Richtung gehen: Mitarbeiter bauen sich mit Low-Code-Plattformen oder KI-Unterstützung eigene kleine Dashboards und Apps — für die Auswertung von Kennzahlen, zur Automatisierung eines Arbeitsschritts oder schlicht, weil eine bestehende Software eine Lücke lässt. Das ist zunächst kein schlechtes Zeichen. Es zeigt Eigeninitiative, und die Werkzeuge dafür sind heute so zugänglich wie nie. Das Problem entsteht dort, wo diese Tools ohne Einbindung der zentralen IT entstehen, wachsen und irgendwann fester Bestandteil von Arbeitsabläufen werden — ohne dass jemand außerhalb des Erstellers weiß, wie sie funktionieren.

Diese Form der unkontrollierten Eigenentwicklung wird als Schatten-IT bezeichnet. Sie entsteht meist mit guten Absichten und wird zum Risiko, sobald das Ergebnis geschäftskritisch wird. Ein Überblick über die konkreten Gefahren.

Keine Versionierung

Ohne Versionskontrolle wie Git ist jede Änderung am Code eine Einbahnstraße. Wenn eine neue Funktion einen bestehenden Ablauf kaputt macht, gibt es keinen Punkt, zu dem man zurückkehren kann. Im schlimmsten Fall überschreibt eine neue Version die alte vollständig — und mit ihr jede Möglichkeit, den vorherigen, funktionierenden Zustand wiederherzustellen.

Keine Dokumentation

Was eine Anwendung tut, warum sie so gebaut wurde und welche Annahmen sie über die Daten trifft, mit denen sie arbeitet, existiert oft ausschließlich im Kopf der Person, die sie erstellt hat. Für alle anderen — Kollegen, Vorgesetzte, im Zweifel auch die IT — bleibt die Anwendung eine Black Box, die niemand außer dem Ersteller warten, erweitern oder im Fehlerfall verstehen kann.

Keine Sicherung des Quellcodes

Liegt der Code nur lokal auf einem einzelnen Rechner, hängt seine Existenz an der Hardware dieses einen Geräts. Ein Festplattendefekt, ein verlorenes Notebook oder ein versehentliches Löschen reicht aus, um Monate an Arbeit und ein mittlerweile produktiv genutztes Werkzeug unwiederbringlich zu verlieren.

Fehlende Security

Selbstgebaute Tools entstehen in der Regel mit Fokus auf die schnelle Lösung eines konkreten Problems — nicht mit einem Sicherheitskonzept. Fehlende Authentifizierung, offene Schnittstellen ohne Zugriffsbeschränkung oder unverschlüsselt übertragene und gespeicherte Daten sind die Folge. Wo professionelle Software Security-Reviews und Penetrationstests durchläuft, gibt es hier meist gar keine Prüfung.

Direkte Datenbankzugriffe ohne Berechtigungskonzept

Besonders kritisch wird es, wenn ein selbstgebautes Dashboard direkt lesend oder gar schreibend auf produktive Datenbanken zugreift — oft mit einem einzigen, breit berechtigten Zugang, der eigentlich für andere Zwecke gedacht war. Ein unbedachter Klick, eine fehlerhafte Abfrage oder eine klassische SQL-Injection können hier direkt Produktivdaten verändern oder zerstören, ganz ohne böse Absicht.

Compliance und DSGVO

Sobald personenbezogene Daten in einem solchen Tool verarbeitet werden — und das passiert schneller als gedacht, etwa bei Auswertungen zu Kunden oder Mitarbeitern — entsteht eine Verarbeitung, die in keinem Verzeichnis von Verarbeitungstätigkeiten auftaucht, kein Löschkonzept kennt und im Zweifel gegen die DSGVO verstößt. Für ein Werkzeug, von dem die Compliance-Verantwortlichen im Unternehmen gar nichts wissen, lässt sich das kaum nachträglich heilen.

Wissensverlust beim Weggang des Erstellers

Verlässt die Person, die das Tool gebaut hat, das Unternehmen, bleibt oft ein Werkzeug zurück, das niemand mehr versteht, anpassen oder im Fehlerfall reparieren kann — obwohl mittlerweile ganze Abläufe darauf aufbauen. Ein einzelner Mitarbeiter wird damit ungewollt zum Single Point of Failure für einen Teil der Unternehmens-IT.

Wie Geschäftsführer das an ihr Team kommunizieren

Am wirksamsten ist eine kurze, wertschätzende Ansage, statt eines nachträglichen Verbots. Ein Vorschlag als Formulierungshilfe für eine E-Mail oder Team-Nachricht an alle Mitarbeiter:

Passende Alternativen statt Ad-hoc-Lösung

Wer Mitarbeitern eine Ansage macht, sollte im gleichen Atemzug eine Alternative anbieten. Eine Orientierung, welche Werkzeugkategorie welches Bedürfnis abdeckt: