Wenn Excel und Power Automate zum Betriebsrisiko werden

Ein Genehmigungsprozess, eine Statusverfolgung, eine Datenerfassung zwischen zwei Abteilungen oder zum ERP-System - meist beginnt es mit Excel, einer SharePoint-Liste und ein wenig Power Automate dazwischen. Jemand im Fachbereich hat es gebaut, weil es schnell ging und funktionierte. Jahre später trägt genau dieses Konstrukt einen Prozess, von dem mehrere Abteilungen abhängen - ohne dass es je als System geplant wurde.

Wie aus einer Zwischenlösung ein unternehmenskritisches System wird

Der Übergang passiert schleichend. Ein Formular wird um ein Feld erweitert, ein Flow um einen weiteren Freigabeschritt, eine Liste um eine neue Spalte für Daten, die vorher niemand erfasst hat. Jede einzelne Änderung ist klein und naheliegend. In der Summe entsteht ein Prozess, den formal niemand verantwortet - klassische Schatten-IT: außerhalb der IT-Governance gewachsen, ohne Dokumentation, mit Zugriffsrechten, die sich niemand mehr im Detail erklären kann. Das Tool taucht in keiner Inventarisierung auf, bis es ausfällt oder jemand danach fragt.

Wo die Plattform selbst an ihre Grenzen kommt

Power Automate und SharePoint sind für viele Abläufe die richtige Wahl - das Problem ist nicht das Werkzeug, sondern der Punkt, an dem ein Prozess über das hinauswächst, wofür es gebaut wurde. Laut Microsofts eigener Dokumentation läuft ein einzelner Cloud-Flow inklusive wartender Schritte wie Freigaben maximal 30 Tage - danach läuft ein offener Genehmigungsschritt schlicht ins Leere. Die Ausführungshistorie wird ebenfalls nur 30 Tage vorgehalten, Audit-Protokolle meist 90 Tage. Flows ohne Aktivität oder mit anhaltenden Fehlern werden automatisch deaktiviert. Für einen einfachen, kurzlebigen Genehmigungsschritt ist das unproblematisch. Für einen Prozess, der über Monate läuft, mehrere Abteilungen verbindet und im Zweifel nachweisbar sein muss, wird genau das zum stillen Risiko - der Flow bricht nicht mit einer lauten Fehlermeldung ab, er hört einfach auf zu funktionieren.

Der Teil, der bei einer DSGVO-Prüfung unangenehm wird

Sobald ein solches Tool personenbezogene Daten verarbeitet - Mitarbeiterdaten, Kundendaten, Bewerberdaten - stellt sich die Frage nach dem Verzeichnis von Verarbeitungstätigkeiten (Art. 30 DSGVO). Die Ausnahme für Unternehmen unter 250 Mitarbeitenden greift nicht, sobald die Verarbeitung nicht nur gelegentlich erfolgt, ein Risiko für die Rechte Betroffener birgt oder besondere Datenkategorien betrifft - und eine laufende Mitarbeiter- oder Kundendatenverarbeitung ist praktisch nie „nur gelegentlich“. Dazu kommt Art. 32: angemessene technische und organisatorische Maßnahmen, inklusive Zugriffskontrolle und im Zweifel Protokollierung. Ein geteiltes Excel-Sheet mit breiten Zugriffsrechten und ohne nachvollziehbare Änderungshistorie erfüllt das in der Praxis selten - nicht, weil das Gesetz Excel verbietet, sondern weil die Anforderung an Nachweisbarkeit mit dem Werkzeug kollidiert.

Fällt ein Unternehmen zusätzlich unter NIS-2 (abhängig von Sektor und Größe), kommen ähnliche Erwartungen an Zugriffskontrolle und Protokollierung für die Systeme hinzu, die zur Leistungserbringung genutzt werden. Ob ein konkretes internes Tool darunterfällt, ist dabei fallabhängig - eine pauschale Antwort gibt es nicht, eine konkrete Einordnung im Zweifel schon.

Der naheliegende, aber riskante Reflex

Wenn das Risiko einmal sichtbar wird, ist die erste Reaktion oft: alles ersetzen, am besten durch ein „richtiges“ System. Das klingt sauber, koppelt aber sofort mehrere laufende Prozesse an ein Projekt mit ungewissem Ausgang - und genau die Abteilungen, die heute produktiv mit dem gewachsenen Tool arbeiten, tragen das Risiko, bis das neue System fertig ist. Der Prozess, der ersetzt werden soll, läuft in der Zwischenzeit unverändert weiter, mit denselben Schwächen.

Das progressive Muster: ein Workflow nach dem anderen

Tragfähiger ist es, sich einen kritischen Workflow herauszugreifen und den tatsächlichen Ablauf zuerst zu verstehen - wer ihn nutzt, welche Daten wirklich fließen, wo die Freigaben liegen, was bei einem Fehler passiert. Erst danach folgt die technische Härtung: eine saubere, isolierte Anbindung an die bestehenden Systeme (ERP, HR), echte Zugriffskontrolle statt eines für alle geteilten Zugangs, eine Protokollierung, die im Zweifel auch einer Prüfung standhält. Der Rest der Prozesslandschaft bleibt vorerst unangetastet. Wissenstransfer gehört von Anfang an dazu, nicht als nachträgliche Dokumentation - genau die Person, die den Ablauf heute allein versteht, ist der Grund, warum das Risiko überhaupt entstanden ist.

Wo KI-generierter Code hier an seine Grenzen kommt

Ein internes Tool lässt sich heute mit KI-Unterstützung in wenigen Stunden zusammenklicken - ein Formular, ein paar Automatisierungsschritte, fertig. Wie schnell etwas entsteht, sagt aber nichts darüber aus, wie tragfähig es als produktives System ist: Zugriffskontrolle, Fehlerbehandlung und Nachvollziehbarkeit gehören selten zum ersten Entwurf, weder beim von Hand gebauten Power-Automate-Flow noch beim KI-generierten Prototyp. Genau diese Lücke zwischen Prototyp und Produktivsystem betrifft interne Tools nicht weniger als kundenseitige Oberflächen.

Das Ergebnis, wenn es funktioniert

Ein einzelner gehärteter Workflow wird oft zur Vorlage für die nächsten - dieselbe Anbindung, dieselbe Zugriffslogik, dieselbe Protokollierung lassen sich wiederverwenden, statt jeden Prozess erneut als Sonderfall zu behandeln. Aus einer Ansammlung fragiler Einzellösungen wird so schrittweise ein System, das mehr als eine Person versteht - ohne dass der laufende Betrieb dafür je stillstehen musste. Es ist dasselbe Prinzip, das auch bei der schrittweisen Modernisierung eines gewachsenen Frontends trägt: nicht alles auf einmal anfassen, sondern ein Stück nach dem anderen - und jedes fertige Stück zur Vorlage für das nächste machen.