Warum Transformationsprojekte scheitern, wenn Bedürfnisse als fix, bekannt und vollständig artikulierbar behandelt werden
Die meisten Transformationsprojekte beginnen mit einer vertrauten Annahme: Das Unternehmen weiß bereits, was es braucht. Anforderungen werden gesammelt, Tools werden in die engere Auswahl genommen, und ein Projekt wird um eine Reihe genannter Ziele gestartet. In der Praxis ist diese Annahme jedoch oft falsch.
Unternehmen beginnen selten mit vollständig ausgearbeiteten, stabilen und gut verstandenen Bedürfnissen. Stattdessen werden Bedürfnisse unter Unsicherheit entdeckt. Sie werden durch unvollständige Informationen, vererbte Prozesse, interne Politik, Koordinationsprobleme und die Art und Weise geprägt, wie das Problem selbst eingerahmt wird.
Ohne operative Architektur skalieren Organisationen keine Transformation. Sie skalieren Mehrdeutigkeit.
1. Begrenzte Rationalität: Organisationen entscheiden nicht auf Basis vollständiger Kenntnisse
Herbert Simons Forschung zu Entscheidungsprozessen in Wirtschaftsorganisationen ist einer der klarsten Ausgangspunkte für das Verständnis dieses Problems. Simon argumentierte gegen die Idee, dass Entscheidungsträger mit vollständiger Rationalität, vollständigem Wissen und unbegrenzten Rechenkapazitäten handeln. Stattdessen handeln sie unter begrenzter Rationalität: Sie haben begrenzte Informationen, begrenzte Aufmerksamkeit und begrenzte Fähigkeit, Konsequenzen zu modellieren.
Seine Forschung zur Entscheidungsfindung innerhalb von Organisationen wurde 1978 mit dem Nobelpreis für Wirtschaftswissenschaften ausgezeichnet.
In der Praxis bedeutet dies, dass ein Unternehmen vor Beginn einer Transformation nicht einfach „weiß”, was es braucht. Was es hat, sind partielle Beschreibungen, lokale Anreize, ererbte Annahmen und Fragmente der operativen Realität.
2. Framing-Effekte: Wie ein Unternehmen das Problem definiert, beeinflusst, was es will
Verhaltensökonomische Forschung fügt eine zweite wichtige Schicht hinzu. Daniel Kahnemans nobelpreisgekrönte Arbeit, zusammen mit Amos Tversky, zeigte, dass Entscheidungen unter Unsicherheit systematisch von klassischen rationalen Modellen abweichen. Eine der wichtigsten Erkenntnisse ist, dass Framing eine Rolle spielt: Die Art und Weise, wie Optionen und Risiken präsentiert werden, verändert, wie Menschen sie bewerten.
Wenn ein Unternehmen seine Herausforderung als „Wir brauchen KI” rahmt, wird es einen bestimmten Satz von Lösungen sehen. Wenn dasselbe zugrunde liegende Problem als „Unser Betriebsmodell ist fragmentiert” gerahmt wird, sieht es einen anderen.
3. Konstruierte Präferenzen: Bedürfnisse entstehen oft während der Diagnose
Paul Slovics Arbeit zur Konstruktion von Präferenzen ist hier besonders aufschlussreich. Slovic argumentiert, dass Präferenzen oft nicht einfach in Menschen oder Organisationen gespeichert sind und darauf warten, offenbart zu werden; vielmehr werden sie häufig im Prozess der Ermittlung konstruiert.
Für Unternehmen bedeutet dies, dass dasselbe oft für „Bedürfnisse” gilt. Ein Unternehmen kann glauben, dass es Automatisierung, ERP, KI, Dashboards oder Workflow-Software benötigt. Aber diese genannten Bedürfnisse entwickeln sich oft, sobald die Organisation ihre eigenen Prozessgrenzen klarer sieht.
4. Anforderungsunsicherheit: Die operative Realität von Systemprojekten
Dieses Problem ist nicht nur philosophisch; es ist auch in der Systeme- und Softwareforschung weitgehend anerkannt. Forschungen zu Anforderungsunsicherheit und -volatilität zeigen, dass unvollständige, sich ändernde oder unklare Anforderungen die Projektleistung und -ergebnisse wesentlich beeinflussen.
Dies ist der Grund, warum Transformationsprojekte, die zu schnell mit der Implementierung beginnen, oft Schwierigkeiten haben. Das Problem ist nicht einfach schlechtes Projektmanagement. Es geht darum, dass die operative Realität noch nicht sichtbar gemacht worden ist.
5. Was das für die operative Architektur bedeutet
Das ist der Grund, warum operative Architektur vor der Automatisierung wichtig ist.
Die erste Aufgabe ist nicht, alles schnell zu automatisieren. Die erste Aufgabe ist es, das Betriebsmodell sichtbar und strukturiert zu machen.
Das ist die Logik hinter dem I|S|P-Prinzip:
• Infrastruktursicherheit schafft die technischen und operativen Rahmenbedingungen. • Systemarchitektur strukturiert Rollen, Workflows, Datenmodelle und Systembeziehungen. • Prozessautomatisierung automatisiert nur, was sichtbar und steuerbar gemacht wurde.
Fazit
Unternehmen wissen oft noch nicht, was sie brauchen. Das ist kein Versagen. Es ist ein normaler Zustand der Entscheidungsfindung unter Unsicherheit. Der Fehler ist es, frühe genannte Anforderungen so zu behandeln, als wären sie vollständig, fix und vollständig rational.
Von dort aus wird die Transformation weniger darum gehen, Tools zu kaufen, und mehr darum, die operative Architektur aufzubauen, die gute Entscheidungen ermöglicht.
