Your Training Partner
Artikel
Cynefin-Framework: Leitfaden für Entscheidungsfindung

Cynefin-Framework: Leitfaden für Entscheidungsfindung

in Management, Beratung

Die teure Gewohnheit, alles als kompliziert zu behandeln

Ein grosses Finanzinstitut verbringt achtzehn Monate und mehrere Millionen mit einer detaillierten Anforderungsspezifikation für eine neue digitale Bankplattform. Das Dokument umfasst vierhundert Seiten. Als die Entwicklung beginnt, ist die Hälfte der Annahmen überholt. Das Projekt wird verspätet geliefert, über dem Budget und mit Funktionen, die Kunden nie wollten. Die Nachanalyse schliesst, dass „die Anforderungen unvollständig waren“ und empfiehlt eine gründlichere Analyse beim nächsten Mal.

Dieses Muster wiederholt sich branchenubergreifend. Die eigentliche Ursache ist selten eine unzureichende Analyse. Es ist eine fundamentale Fehldiagnose des Problembereichs. Die Organisation hat eine komplexe Herausforderung behandelt, als ware sie lediglich kompliziert. Keine noch so gründliche Vorausplanung kann diesen Kategoriefehler kompensieren.

Dave Snowdens Cynefin-Framework, zunächst am IBM Institute for Knowledge Management entwickelt und 2007 in einem grundlegenden Artikel im Harvard Business Review mit Mary Boone verfeinert, liefert die diagnostische Sprache, die Praktiker benötigen. Das walisische Wort „cynefin“ (ausgesprochen „ku-nev-in“) bedeutet Lebensraum oder Ort. Es erinnert uns daran, dass jede Entscheidung in einem Kontext existiert, der bestimmt, welche Ansätze funktionieren werden.

Zwei grundlegend verschiedene Welten

Das Framework identifiziert fünf Domänen, aber die entscheidende Unterscheidung für Fuhrungskrafte ist zwischen der geordneten Welt (klar und kompliziert) und der ungeordneten Welt (komplex und chaotisch).

In geordneten Domänen sind Ursache und Wirkung entweder offensichtlich oder durch Expertenanalyse ermittelbar. Planung funktioniert. Expertise ist entscheidend. Die richtige Antwort existiert und kann mit ausreichender Untersuchung gefunden werden. Traditionelles Projektmanagement, Requirements Engineering und Prozessoptimierung gehören hierher.

In ungeordneten Domänen können Ursache und Wirkung nur rückblickend verstanden werden, wenn überhaupt. Traditionelle Planung ist unmöglich, weil das Systemverhalten emergent ist. Digitale Transformation, Kulturwandel, Marktdisruption und Innovation leben in diesem Gebiet. Die richtige Antwort existiert nicht im Voraus. Sie muss durch Handeln entdeckt werden.

Wie erkennen Sie den Unterschied?

Ein kompliziertes Problem kann von jemandem mit der richtigen Expertise gelost werden, wenn genügend Zeit vorhanden ist. Man zerlegt es, studiert die Komponenten und setzt eine Losung zusammen. Eine Schweizer Uhr ist kompliziert: aufwendig, aber letztlich erkennbar.

Eine komplexe Situation kann nicht allein durch Analyse gelost werden, weil die Komponenten auf unvorhersehbare Weise interagieren. Ein Regenwald-Okosystem ist komplex: Jede Intervention verändert das Systemverhalten auf Weisen, die sich nicht vollständig vorhersagen lassen. Stakeholder-Dynamiken, politische Interessen und kulturelle Gewohnheiten interagieren nach demselben Muster.

Fünf Domänen, fünf Entscheidungssequenzen

Klar: wahrnehmen, kategorisieren, reagieren

Ursache und Wirkung sind offensichtlich. Ein Änderungsantrag folgt einem dokumentierten Genehmigungsprozess. Ein Vorfall entspricht einem bekannten Fehler in der Wissensdatenbank. Sie wenden etablierte Best Practices an. Dies ist die Domäne der Checklisten, Standardverfahren und klar definierten RACI-Matrizen.

Die Falle ist Selbstzufriedenheit. Snowden warnt, dass die klare Domäne gefährlich nahe am Chaos liegt. Organisationen im Autopilot-Modus sind anfällig für plötzlichen Zusammenbruch, wenn ein unvorhergesehenes Ereignis eintritt.

Kompliziert: wahrnehmen, analysieren, reagieren

Mehrere gültige Losungen existieren, aber sie zu finden erfordert Expertise. Ein Enterprise-Architekt, der Integrationsplattformen bewertet, ein Business Analyst, der einen Compliance-Prozess modelliert, ein Projektmanager, der einen Projektstrukturplan für ein mehrjähriges Programm erstellt: Alle arbeiten hier. Das Risiko ist Analyselähmung oder Expertenblindheit, bei der tiefe Expertise in einer Methodik Praktiker für Alternativen blind macht.

Komplex: sondieren, wahrnehmen, reagieren

Hier leben die meisten modernen Geschäftsherausforderungen. Statt zuerst zu analysieren, fuhren Praktiker „Safe-to-fail“-Experimente durch. Sie sondieren das System mit kleinen Interventionen, beobachten welche Muster entstehen und verstärken was funktioniert. Ein Business Analyst in dieser Domäne erstellt kein vollständiges Pflichtenheft im Voraus. Er erleichtert die Entdeckung durch Prototypen, Story Mapping und iterative Feedback-Schleifen.

Fuhrungskrafte müssen der Versuchung widerstehen, vorzeitig Ordnung aufzuzwingen. Der Instinkt, einen detaillierten Plan mit vorhersagbaren Ergebnissen zu verlangen, erzeugt falsche Sicherheit. Der bessere Ansatz ist, klare Grenzen zu setzen und dem Team zu erlauben, innerhalb dieser zu navigieren.

Chaotisch: handeln, wahrnehmen, reagieren

Keine Zeit für Analyse oder Experimente. Ein kritisches System fallt wahrend der Spitzenbelastung aus. Ein wichtiger Lieferant meldet mitten im Projekt Insolvenz an. Die Priorität ist entschlossenes Handeln, Stabilisierung und dann die Verschiebung der Situation in eine Domäne, wo strukturierte Ansätze möglich werden.

Unordnung: die gefährliche Standardreaktion

Unordnung beschreibt den Zustand, in dem niemand weiss, welche Domäne gilt. Jeder fallt in seine Komfortzone zurück: Manager erzwingen Prozesse, Analysten fordern Daten, Entwickler beginnen zu programmieren. Der Ausweg ist, die Situation zu zerlegen, jede Komponente der passenden Domäne zuzuordnen und entsprechend zu handeln.

Warum Methodikdebatten am Kern vorbeigehen

Das Cynefin-Framework erklärt, warum bestimmte Methoden in manchen Kontexten brillant funktionieren und in anderen scheitern. Wasserfall ist ein Ansatz der komplizierten Domäne: Er setzt voraus, dass gründliche Vorabanalyse den richtigen Plan identifizieren kann. Agile Methoden sind Ansätze der komplexen Domäne: Sie setzen voraus, dass Anforderungen und Losungen durch iterative Lieferung entstehen. Keine ist universell überlegen. Die Frage ist immer, in welcher Domäne Sie sich befinden.

Business Analysten, die dies verstehen, hören auf, zwischen detaillierten Spezifikationen und User Stories zu debattieren. Sie diagnostizieren zuerst den Kontext. Anforderungen für ein regulatorisches Berichtssystem (kompliziert) sehen ganz anders aus als Anforderungen für ein innovatives Kundenportal (komplex). Projektmanager erhalten ein glaubwürdiges Argument, die Methodik dem Kontext anzupassen statt einen einzigen Standard über das gesamte Portfolio zu erzwingen.

Domanenwechsel erkennen

Situationen bleiben nicht in einer Domäne. Ein standardmassiger Systemaustausch (kompliziert) kann ins Komplexe kippen, wenn die Benutzeradoption unerwartete Widerstandsmuster offenbart. Ein komplexer Organisationswandel kann chaotisch werden, wenn eine Schlüsselperson abrupt ausscheidet. Erfahrene Praktiker achten auf diese Ubergange und passen sich an, bevor die Diskrepanz Schaden verursacht.

Der gefährlichste Übergang ist von klar zu chaotisch, die „Selbstzufriedenheitsfalte.“ Regelmassige Retrospektiven, Annahmentests und Szenarienplanung liefern Frühwarnsignale. Organisationen, die dieses Bewusstsein in ihre Governance einbauen, hören auf zu fragen „Was ist unsere Methodik?“ und beginnen zu fragen „Mit welcher Art von Problem haben wir es zu tun?“ Diese Verschiebung der Fragestellung ist der Ausgangspunkt für bessere Entscheidungen.


Weiterführend

Grundlagen des Projektmanagements

Beherrschen Sie die wesentlichen Prinzipien des Projektmanagements, einschliesslich Planung, Durchführung und Governance in verschiedenen Projektkontexten.

AgilePM-Zertifizierung

Lernen Sie, agile Prinzipien in einem strukturierten Projektrahmen anzuwenden und Flexibilität mit Governance für komplexe Umgebungen zu verbinden.

Die Veränderungsgleichung: Von Gleicher zu Beckhard-Harris
Alle Beiträge
Use Case 2.0: Requirements Engineering und agile Methoden vereint