Das scheint auf den ersten Blick gar nicht mal so kompliziert. Oder komplex? Was ist der Unterschied? Und wieso ist das relevant? „Nichts leichter als das“, sagte Frederick, „komm mit!“

Tatsächlich ist – zumindest im Kontext der Bewertung einer Aufgabenstellung, einer Situation oder eines Systems – ein Unterschied zwischen kompliziert und komplex vorhanden. Wir gehen an dieser Stelle aber noch einen Schritt weiter und unterscheiden zusätzlich einfache und chaotische Aufgabenstellungen, Situationen oder Systeme. Und weil das noch nicht reicht, gibt es auch noch einen fünften Zustand, aber um den kümmern wir uns später.

Grundsätzlich ist komplex, was nicht nicht einfach oder kompliziert, aber auch nicht chaotisch ist. Einfache und komplizierte Dinge sind geordnet. Wir können ihnen mit einem mehr oder weniger überschaubaren Maß an Aufwand begegnen. Grundlage für die folgenden Einordnungen bildet das Cynefin-Framework, ein Sinn-Erfassungs-Werkzeug von Dave Snowden. Eine Erklärung auf Englisch hat er selbst in einem Video geliefert, inklusive korrekter Aussprache:

Für alle anderen hier eine kleine Zusammenfassung:

Bei einfachen Aufgaben, Situationen oder Systemen nehmen wir sie wahr, kategorisieren sie und reagieren dann. Die Ursache und die Wirkung sind offensichtlich und allen Beteiligten klar. Ein Beispiel ist hier zum Beispiel das Auslösen einer Bestellung. Der Prozess ist meist etabliert, klar dokumentiert und gut zu befolgen:

Ich brauche neues Papier, ich gehe in den Onlineshop meiner Wahl, ich klicke das Papier in den Warenkorb, gebe Adresse und Zahlungsdaten an und klicke auf „Bestellen“. Fertig. Es gibt hier so etwas wie eine best practice, einen bestmöglichen Lösungsweg.

Komplizierte Aufgaben, Situationen oder Systeme sind immer noch geordnet, aber sie erfordern ein wenig mehr Aufwand oder Expertise. Ich muss also erstmal feststellen, worum es geht, kann dann aber relativ gut analysieren, wie meine Antwort aussehen kann und dann eine mögliche Strategie auswählen, wie ich reagiere. Meine good practice ermöglicht es mir, ans Ziel zu kommen, aber sie ist nicht der einzige, sondern nur ein möglicher Weg unter mehreren dafür:

Wenn ich eine gewöhnliche Brücke bauen will, dann muss ich mir nicht eine neue Form überlegen oder neue Materialien entwickeln oder ähnliche Späße, sondern mich für eine Form entscheiden, die Statik berechnen, die Materialien ordern, die Gewerke koordinieren, Genehmigungen einholen und so weiter. Das ganze ist durchaus kompliziert, meist umfangreich, aber ich muss nichts Neues entwickeln, ich kann mich auf das verlassen, was bereits existiert, und ich werde im Verlauf des Baus für gewöhnlich keine Überraschungen erleben.

Anders ist das bei komplexen Aufgaben, Situationen oder Systemen. Alleine die Tatsache, dass ich an einer Lösung arbeite, führt dazu, dass sich meine Ausgangslage verändert. Ich lerne im Laufe der Zeit neue Dinge dazu, es tun sich neue Probleme auf, und zu allem Übel weiß ich am Anfang noch gar nicht, wie ich ans Ziel komme. Es gibt einen Haufen Parameter, von denen ich schon anfangs weiß, dass ich sie kenne, und eine Menge Parameter, von denen ich anfangs weiß, dass ich sie nicht kenne. Leider gibt es auch Wissen, von dem ich am Anfang noch nicht weiß, dass ich es benötige und nicht habe. Das wird erst im Projektverlauf klar. Die Vorgehensweise hier muss eine emergent practice sein, eine Handlungsweise, die sich mit der Zeit aus der Arbeit ergeben: Ausprobieren, auswerten, reagieren.

Als Beispiel sei hier so ziemlich jede Entwicklung einer Software genannt. Oder grundsätzlich alles, was Wissensarbeit beinhaltet.

Und dann gibt es da noch das Chaos. Ich kann zwischen dem, was ich tue und dem, was es auslöst keine offensichtlichen Ursachen entdecken. Es bleibt also als einzige Option nur, erstmal zu handeln, dann zu schauen, ob es etwas gebracht hat und dann darauf zu reagieren. Wenn ich eine Innovation schaffen will, ist das perfekt. Wenn ich aber auf ein Problem reagiere, kann das eher schwierig sein. Ich brauche hier vor allem neue Ideen, neue Ansätze, novel practices.

Wenn keine mehr einen Plan hat, wo es lang geht, wenn ich keine Daten habe, wenn es keine erkennbare Grundlage für Ursache und Wirkung gibt, aber ich mich irgendwie aus der Situation befreien muss, dann laufe ich eben los. Ich bin auf einem Raumschiff gefangen, habe meine Entführer überwältigt, weiß aber nicht, wie ich nach Hause komme? Dann fang ich an, ein paar Knöpfe auf den Konsolen zu drücken. In der Hoffnung, dass mir einer davon hilft. Und wenn mich das Knopfdrücken nicht umbringt, mach ich weiter. Bis ich es nach Hause schaffe. Oder … nun ja.

Okay, das Beispiel mag vielleicht ein wenig an den Haaren herbeigezogen sein, aber etwas Besseres fällt mir gerade nicht ein.

Nun mag der Reflex sein zu sagen, dass es doch am besten wäre, alles im einfachen Bereich zu halten oder dorthin zu reduzieren. Das klingt erstmal logisch, birgt aber ein Risiko, selbst wenn es möglich sein sollte: Aufgaben, Situationen und Systeme, die wir als einfach wahrnehmen, können sehr schnell ins Chaos rutschen, wenn wir ihnen mit dem falschen Mittel begegnen. Snowden stellt das durch eine kleine Klippe zwischen einfach und chaotisch dar. Wenn wir dort quasi runterfallen, wird es sehr teuer, uns wieder nach oben zu arbeiten. Wir möchten also in der Regel unsere Projekte dort halten, wo sie kompliziert oder komplex sind. Beides ist für uns beherrschbar, ohne das Risiko, ins Chaos abzurutschen.

Zuletzt bleibt noch das kleine Feld in der Mitte, mit Disorder bezeichnet. Dort findet sich alles, was wir nicht zuordnen können. Also anfangs alles. Und um es zuzuordnen, müssen wir miteinander reden.

Denn eine Person, die hauptsächlich in einfachen Systemen unterwegs ist (Verwaltungsmitarbeiter zum Beispiel) wird für gewöhnlich eine auftretende Situation als einfach bewerten und einem Problem mit einer best practice begegnen wollen. Wenn es dann schief geht, sind falsche Prozesse schuld.

Wer aus einem komplizierten Umfeld kommt, wird die Aufgabe als kompliziert bewerten, sie mit der gelernten good practice (klassisches PM, Six Sigma, etc.) erschlagen und ein Scheitern als „zu wenig Zeit, zu wenig Expertenwissen“ einstufen.

Menschen aus komplexen Umfeldern kommen mit der eigentlichen Aufgabenstellung ganz gut klar, tendenziell werden aber bei einer tatsächlich komplizierten oder einfachen Ausgangslage viel zu viele Ressourcen auf die Lösung verschwendet. Ein Scheitern liegt dann in ihren Augen vor allem an dem mangelnden Verständnis der anderen für die Komplexität und den notwendigen Aufwand.

Und wer aus dem Chaos kommt, wird erstmal machen. Ohne abzuwarten. Ohne zu analysieren. Einfach losstürmen. Denn nur so kann man dank neuer Praktiken, die noch niemand ausprobiert hat, dem Chaos entrinnen. Dass das in den anderen drei Feldern negative Effekte hat, wird sich jede selbst zusammenreimen können.

Es bleibt uns also nur, im ersten Schritt zu überprüfen, in welchem Bereich sich eine Problemstellung, eine Situation, ein System einordnen lässt. Und erst, wenn wir uns einig sind, oder sicher, dann können wir die entsprechende Handlungsweise – best practice, good practice, emergent practice oder novel practice – wählen und loslegen.

Wie läuft das bei euch? Sind alle Aufgabenstellungen, Systeme und Situationen bei euch eindeutig zuzuordnen? Nehmt ihr euch die Zeit dafür? Oder geht ihr direkt an die Lösung? Schreibt gerne in die Kommentare!

Wie immer gilt: Danke für’s Lesen, abonniert sehr gerne meinen Newsletter, und wenn euch der Artikel gefallen hat, tut mir einen Gefallen und verbreitet ihn weiter, das hilft mir sehr! Dankeschön!

[waglerit-newsletter-block]