Automatisierung undefinierter Prozesse schafft keine Effizienz — sie beschleunigt die bestehende Unordnung.
In digitalen Transformationsprojekten zeigt sich ein wiederkehrendes Muster: Der Wunsch zu automatisieren entsteht, bevor das Betriebsmodell definiert ist. Unternehmen identifizieren repetitive Aufgaben, sehen in der Automatisierung eine naheliegende Lösung und beginnen mit dem Aufbau von Workflows, bevor die zugrundeliegenden Prozesse explizit gemacht wurden.
Das Ergebnis ist keine Effizienz. Es ist dieselbe Unordnung, schneller ausgeführt und schwerer rückgängig zu machen.
Architektur ist keine Voraussetzung, weil sie gute Praxis ist. Sie ist eine Voraussetzung, weil Automatisierung Annahmen festschreibt. Was im Prozess unklar, undefiniert oder schlecht strukturiert ist, wird in der Automatisierung dauerhaft.
1. Die Automatisierungsillusion
Automatisierung ist sichtbar. Sie erzeugt Ausgaben, läuft nach Zeitplan und vermittelt den Eindruck operativer Reife. Das macht sie als frühe Investition attraktiv — sie signalisiert Fortschritt auf eine Weise, die Architekturarbeit nicht tut.
Genau diese Sichtbarkeit macht vorzeitige Automatisierung jedoch teuer. Ein gut gestalteter Automatisierungs-Workflow, der auf einem undefinierten Betriebsmodell aufsetzt, verbessert das Betriebsmodell nicht. Er macht es schwerer erkennbar und schwerer veränderbar.
Dies wird manchmal als technische Schuld der Prozessautomatisierung beschrieben: Abkürzungen auf der Architekturebene werden in der Automatisierungsschicht tragend.
2. Was Architektur tatsächlich liefert
Operative Architektur ist keine Dokumentation. Sie ist eine Menge struktureller Entscheidungen: Welche Systeme existieren, welche Rollen und Verantwortlichkeiten ihnen zugewiesen sind, wie Daten zwischen ihnen fließen, was Aktionen auslöst und wo Verantwortung liegt.
Ohne dass diese Entscheidungen explizit sind, hat Automatisierung keine stabile Oberfläche, auf der sie aufbauen kann. Workflows hängen von impliziten Annahmen ab. Regeln sind in Code eingebettet statt in ein gesteuertes Betriebsmodell. Das System ist nur für denjenigen lesbar, der es gebaut hat.
Wenn sich diese Annahmen ändern — und das tun sie immer — bricht die Automatisierung auf schwer zu diagnostizierende Weise.
3. Wo Automatisierung ohne Architektur scheitert
Die Fehlermuster sind branchenübergreifend konsistent. Doppelte Dateneingaben, die kein Workflow erfasst, weil Systemgrenzen nie definiert wurden. Genehmigungsketten, die an die falsche Person weitergeleitet werden, weil die Rollenarchitektur angenommen statt dokumentiert wurde. Berichte, die inkonsistente Ergebnisse liefern, weil dasselbe Konzept in verschiedenen Systemen unterschiedlich dargestellt wird.
Das sind keine Automatisierungsversagen. Es sind Architekturversagen, die Automatisierung sichtbar — und oft gravierender — gemacht hat.
4. Reihenfolge statt Werkzeuge
Die Reihenfolge ist wichtiger als die Werkzeugauswahl. Welches ERP, welche Automatisierungsplattform, welche KI-Fähigkeit — das sind sekundäre Fragen. Die primäre Frage lautet: Ist das Betriebsmodell hinreichend lesbar gemacht worden, um eines dieser Werkzeuge kohärent einzusetzen?
Lesbarkeit bedeutet hier: klare Rollen, gesteuerte Daten, explizite Prozessgrenzen und dokumentierte Systembeziehungen. Ohne diese Grundlage ist die Werkzeugauswahl verfrüht.
5. Der I|S|P-Ansatz zur Automatisierung
Das I|S|P-Prinzip behandelt Automatisierung als dritte Schicht, nicht als erste.
• Infrastruktursicherheit legt die Betriebsgrenze fest: Welche Systeme existieren, wie sie gesichert sind, wie der Zugriff kontrolliert wird. • Systemarchitektur strukturiert das Betriebsmodell: Rollen, Workflows, Datenmodelle, Systembeziehungen. • Prozessautomatisierung greift nur auf das zu, was lesbar und steuerbar gemacht wurde.
Diese Reihenfolge ist keine Bürokratie. Sie ist die Bedingung, die Automatisierung dauerhaft statt fragil macht.
Fazit
Automatisierung, die vor der Definition des Betriebsmodells angewendet wird, schreibt diese Unordnung in jeden Workflow, den sie ausführt. Je schneller die Automatisierung, desto fester ist die Unordnung eingebettet.
Architektur zuerst bedeutet nicht langsam. Es bedeutet, auf einer Oberfläche zu bauen, die das tragen kann, was man auf ihr platziert.
