Schlagwort-Archive: Muster

Systemisches Denken mit Wirkungsnetzwerken

In einem meiner letzen Blogartikel forderte ich dazu auf, ein System Thinker zu werden. Ich denke, dass Sie mittlerweile genug Zeit hatten, sich mit System Thinking zu beschäftigen, so dass Sie folgendes Stück „System Thinking“ nachvollziehen können oder es dazu nutzen, um Ihre System Thinking Skills zu verbessern.

System Thinking kommt wohl ohne Causal Loop Diagrams (CLD) kaum aus. Ich möchte mich heute der Frage widmen, inwiefern ein Causal Loop Diagram als systemisches Darstellungsmittel genügt. Inspiriert dazu hat mich der Artikel The Ambiguity of Causal Loop Diagrams and Archetypes von Kim Warren.

Wer und was

Ich mag Kim Warren sehr. Er war 2013 Präsident der System Dynamics Society und ich habe ihn ein paar Mal auf einer SD Conference getroffen. Zudem nahm ich vor ein paar Jahren an einer seiner hochspannenden SD-Trainings teil.

Über Causal Loop Diagrams (CLD) – auf Deutsch vielleicht mit Wirkungsnetzwerk übersetzt – und Systemarchetypen habe ich hier schon oft geschrieben, z.B. in Kein einzelner Teil… und in Archetypendiagramme

Zwei Archetypen

Der Archetypus „Eroding Goal“ besagt, dass wir zu Beginn unsere Ziele zu hoch setzen, und wenn wir sie nicht erreichen können, schnell bereit sind, sie auf niedrigerem Niveau neu zu formulieren. Umgekehrt strengen wir uns immer mehr an, das Ziel zu erreichen. Ich habe diese Situation in Fallen gelassene Vorsätze von Dozenten, Studenten und Projektleitern beschrieben

Der Archetypus „Eroding Goal“ als CLD. Blaue Pfeile haben positive, rote negative Polarität.

Der Archetypus „Escalation“ skizziert die gegenseitige Konkurrenz zweier Parteien in ein und derselben Sache. Z.B. streben zwei Personen in einer Disziplin die Weltmeisterschaft an. Immer, wenn die eine einen Erfolg verbucht, fühlt sich die andere bedroht und gibt noch mehr, um das nächste mal die andere zu überbieten.

Der Archetypus „Escalation“ als CLD.

 

Gleiche Strukturen

Im erwähnten Artikel stellt Warren fest, dass beide Archetypen – „Eroding Goals“ und „Escalation“ – aus zwei zielsuchenden Loops bestehen und sieht sich deshalb ausserstande, den Unterschied der beiden Situationen mit einem CLD beschreiben zu können. Er folgert daraus, dass CLD uneindeutig und in gewissem Grad für eine präzise Beschreibung spezifischer (Unternehmens-)Situationen ungeeignet seien. Er räumt allerdings ein, dass der Einsatz von CLD dem „Laundry List“-Vorgehen von Nicht-System-Thinkers immer noch überlegen sei.

Warrens Definition, wonach ein Archetypus ein generisches CLD, zusammen mit einer speziellen Verhaltensstory sei, finde ich bestechend handlich. Gerade an ihrer Verhaltensstory können die beiden Archetypen – „Eroding Goal“ und „Escalation“ – sehr eindeutig voneinander unterschieden werden. Das fängt schon nur bei der Tatsache an, dass in „Eroding Goal“ bloss eine Partei in gewissem Sinne gegen sich selbst handelt, während es in „Eskalation“ zwei Parteien gibt, deren Handlungen sich an denjenigen des Gegners orientieren.

Dynamische Struktur

Warren plädiert dafür, nicht beim CLD stehen zu bleiben, sondern gleich den Schritt zum System Dynamics Modell zu machen, das erst die nötige Klarheit geben könne. Ich kann ihm in dieser Hinsicht nicht folgen. Ich glaube, seine Befürchtungen, dass ein CLD die nötige Eindeutigkeit fehle, sind zumindest dann übertrieben, wenn das CLD nach allen Regeln der Kunst erstellt wurde. Meine Kritik richtet sich vielmehr gegen die vielen Berater, die CLD ohne irgendwelche Grundkenntnisse und ohne grossen Zeitaufwand ihren Kunden teuer verkaufen.

Wenn Warren z.B. schreibt: „The loop structure is mathematically identical“, dann stimmt das nicht. In dem Archetypus „Eroding Goal“ werden Soll-Zustand (Ziel) und Ist-Zustand als Differenz verglichen („Lücke“). Das führt zu einer linearen Struktur. Im Archetypus „Escalation“ hingegen werden die Resultate beider Parteien zueinander in Relation gesetzt, was nicht-linear ist.

Dass die Loopstruktur dennoch gleich ist, liegt daran, dass die Stories sehr verwandt sind. In beiden Stories versuchen die Parteien, durch Anstrengung ein Ziel zu erreichen. Während jedoch in „Escalation“ das Ziel durch die andere Partei immer höher gesetzt wird, wird es in „Eroding Goal“ durch den „inneren Schweinehund“ immer mehr gesenkt.

Fluktuationen

Eine andere Aussage Warrens fordert mich zu einer Präzisierung heraus. Er schreibt: „For example, if A and B start with the same results, there is no escalation“. Das ist rein rechnerisch zwar richtig, verkennt aber die Funktionsweise lebender Systeme. In einem System, das weit vom Gleichgewicht entfernt ist, wird die Dynamik stets von sogenannten Fluktuationen geprüft. Fluktuationen sind in Stärke und Ort zufällig vorkommende Störungen, die gegen die herrschende Struktur verstossen.

In „Escalation“ versuchen die beiden Parteien ständig, sich selbst zu verbessern, ganz ungeachtet vom Resultat der Konkurrenz. Das führt auf alle Fälle zu Differenzen in den jeweiligen Resultaten, sogar, wenn beide Parteien mit exakt denselben starten würden.

Warrens Behauptung gilt bloss für Systeme, die sich in völligem Gleichgewicht befinden. Solche Systeme sind aber tot. In ihnen bewegt sich gar nichts mehr. In der Tat gäbe es auch keine Eskalation mehr.

Jedem CLD seine Story!

Für Warren ist erst ein System Dynamics Modell ein Modell. Für mich ist ein fachgerecht erstelltes CLD jedoch bereits ein (qualitatives) Modell. Allerdings steckt für mich bedeutend mehr hinter einem CLD, als bloss ein paar Parameter, die mit Pfeilen wirr verbunden sind.

Wenn also die generischen CLD der beiden Archetypen „Eroding Goal“ und „Escalation“ fast nicht unterschieden werden können, anhand ihrer Stories und weiteren Analysen lassen sie sich jedoch wohl unterscheiden. Das bedeutet für mich: zu jedem CLD gehört eine Story! Das erreichen Sie am besten, indem Sie sich zu Beginn fragen: „Welche Archetypen stecken in der zu untersuchenden Situation“ und die Modellierung auf diesen Archetypen aufbauen. Dann tragen Sie auch stets die Story mit. Zu einem einfach mal so hingeworfenen CLD eine passende Story zu finden, dürfte ungleich schwieriger sein.

Sollen Muster gebrochen werden?

Das Thema des Barcamps über Projektmanagement, das vom 19. bis am 21. November in Dornbirn stattfindet, lautet „Muster brechen“.

Ein Musterbeispiel

In komplexen Projekten gibt es in der Tat viele Muster. Davon lebt die Komplexität des Projekts. Einige Muster könnten das Projekt verzögern. Folgendes Beispiel soll das illustrieren:

Es wird immer deutlicher, dass die verbleibende Arbeit in der nur noch kurzen Zeit bis zum geplanten und versprochenen Fertigstellungstermin des Projekts nicht bewältigt werden kann. Es ist offensichtlich, dass das Projekt nicht rechtzeitig fertig wird. Was tun?

In Wann kippt ein Projekt und warum? habe ich dargelegt, dass sich für viele vermeintlich fertig gestellte Arbeiten nachträglich herausstellt, dass sie noch Mängel aufweisen und nachgebessert werden müssen. Das nennt sich „Rework Cycle“. Manchmal gibt es explizit eine Qualitätssicherung, die gute Arbeiten durchwinkt und mangelhafte identifiziert. In IT-Projekten übernehmen Tests diese Aufgabe.

Symptomatische versus fundamentale Lösung

Wenn man sieht, dass der gesamte Arbeitsbacklog in der verbleibenden Zeit nicht mehr zu erledigen ist, wäre die symptomatische Lösung, zum Schluss auf die Qualitätssicherung zu verzichten und alle Arbeiten als „definitiv erledigt“ zu deklarieren. Damit könnte das Projekt in der Zeit abgeliefert werden. Allerdings besteht die Gefahr, dass der Kunde beträchtliche Mängel reklamiert, deren nachträgliche Bearbeitung teuer zu stehen käme, ganz zu schweigen von dem Imageverlust.

Demgegenüber steht die fundamentale Lösung, die Qualitätssicherung bis zum Schluss durchzuziehen und das Projekt zu spät abzuliefern, auf die Gefahr hin, Konventionalstrafe bezahlen zu müssen. Diese ist aber berechenbar.

Wir können die Situation so darstellen:

Shifting_the_Burden_Projekt

 

Die blauen Pfeile stellen einen verstärkenden Einfluss dar, die roten einen abschwächenden (1). Das liest sich also so: Je grösser das Problem, dass sich das Projekt verzögert, desto grösser meine Lösungsanstrengung, die QA zu umgehen. Je mehr ich die QA umgehe, desto kleiner wird das Problem, dass sich das Projekt verzögert.

Die symptomatische Lösung entpuppt sich als Sucht

Sollte ich während der symptomatischen Lösung plötzlich „kalte Füsse“ bekommen und mich doch noch für die fundamentale Lösung entscheiden, käme ich in erhebliche Argumentations-schwierigkeiten. Denn erklären Sie einmal dem Kunden kurz vor Projektabschluss, warum vieles von dem, was Sie am Schluss gemacht haben, mangelhaft ist und das Projekt jetzt doch nicht, wie erwartet, fertig wird.

Je mehr ich also von der symptomatischen Lösung Gebrauch mache, desto unglaubwürdiger würden meine Erklärungen, wenn ich mich plötzlich doch für die fundamentale Lösung entscheiden möchte. Das bedeutet, dass die fundamentale Lösung immer mehr abrückt, je mehr und je länger ich den Weg der symptomatischen Lösung begehe. Die symptomatische Lösung wird dadurch zu einer Art „Sucht“, von der man nicht mehr abrücken kann oder wenn, dann nur mit externer Hilfe.

Shifting_the_Burden_Projekt_ganz

 

Brechen des Musters

Dieses Muster wird „Problemverschiebung“ genannt und ist eines von zehn berühmten Mustern, die nach Peter Senge „Systemarchetypen“ genannt werden (2). Zu jedem dieser Muster gibt es eine Durchbrechungsstrategie (3).

Die symptomatische Lösung ist immer der schnelle und bequeme Weg. Im Geschäftsleben wird diese Lösung bevorzugt, weil es meist schnell gehen muss und keine Zeit für fundamentale Lösungen zur Verfügung stehen. Die unsolide Basis der symptomatischen Lösungen holen einem aber meist auf schmerzliche Art ein. Daher sollte sie unbedingt vermieden werden.

Ich bin mir jedoch nicht sicher, ob es in jedem Fall richtig ist, diese Muster zu brechen, in der Meinung, dadurch das Projekt zu beschleunigen. Es könnte auch sein, dass durch das Brechen von irgendwelchen Mustern die Projektkomplexität leidet, was dazu führen würde, dass das Projektziel nicht erreicht wird.

Anmerkungen

(1) Genau genommen sollten wir sagen: die blauen Pfeile sind gleichgerichtet in dem Sinne, dass wenn die Ursache zunimmt, dann auch die Wirkung zunimmt, und wenn die Ursache abnimmt, dann die Wirkung ebenfalls abnimmt. Die roten Pfeile sind gegen-gerichtet in dem Sinne, dass wenn die Ursache zunimmt, dann nimmt die Wirkung ab, und wenn die Ursache abnimmt, dann nimmt die Wirkung zu.
Mit „Ursache“ bezeichne ich hier bloss die Grösse, bei der der Pfeil startet und mit „Wirkung“ bezeichne ich die Grösse, bei der der Pfeil endet. In einem solchen zyklischen Diagramm gibt es aber keine ultimativen Ursachen und Wirkungen.

(2) Die fünfte Disziplin: Kunst und Praxis der lernenden Organisation. Schäffer-Poeschel; 11. Auflage,völlig überarbeitete und aktualisierte Auflage (11. März 2011). ISBN 978-3791029962

(3) http://www.anchor.ch/wissen/Archetypendiagramme.html

(4) Die Figuren wurden mit kumu.io gemacht: https://kumu.io/peteraddor/shifting-burden-project#shifting-burden-project