Archiv der Kategorie: System Dynamics

Wann fangen Sie an, ein System Thinker zu werden?

System Thinking ist eine der wichtigsten Kompetenzen in unserer hochkomplexen Welt. Da der Begriff nicht mit „K“ beginnt, wird diese Kompetenz im 4K-Modell des Lernens meist unterdrückt oder schnöde der Kompetenz des kritischen Denkens untergeordnet, wo es sicher nicht hingehört. Vielleicht sollte „System Thinking“ besser „Complexity Thinking“ genannt werden, dann gäbe es ein 5K-Modell des Lernens, was vielleicht passender wäre.

Was ist System Thinking (ST)?

Hier hilft das deutsche Wikipedia nicht weiter. Der Artikel ist zu kurz und endet sogar mit „Komplexitätsreduktion“, was nicht systemischem Denken entspricht. Der Begriff System Thinking (ST) ist nicht streng definiert und wird von Autor zu Autor verschieden interpretiert, je nachdem, ob er eher aus therapeutischer oder organisationstheoretischer Ecke kommt oder ob er die Welt durch eine soziologische, psychologische oder biologische Brille betrachtet.

ST ist weder eine Methode noch ein Konzept, sondern ein Paradigma, d.h. eine Denkhaltung. Darin unterscheidet sich ST wesentlich von Management Methoden, wie Lean, Agil, 6 Sigma, etc.

Gemeinhin werden fünf bis sechs Charakteristiken des ST erwähnt, die den Begriff meines Erachtens recht gut umreissen (1).

1. Vernetztheit: Ein System wird als Netzwerk seiner Teile angesehen, die miteinander verbunden sind und einander in verschiedenem Mass positiv oder negativ beeinflussen. Aber man kann nicht einfach behaupten, dass alles mit allem vernetzt ist, das wäre zu simpel.

2. Ganzheitlichkeit: Um die systemweite Vernetzung zu erfassen, richtet sich der Blick auf die Struktur des Gesamtsystems und sieht die einzelnen Bereiche allenfalls unscharf, im Gegensatz zu jedem Engineer Thinking.
ST glaubt, dass die Struktur des Systems sein Verhalten bestimmt.

3. Selbstorganisation: Ein System Thinker erkennt die Fähigkeit eines Systems, aus sich heraus unvorhergesehen neue Qualitäten zu schaffen. Selbstorganisation ist ein dynamischer Aspekt und basiert auf lokalen Abweichungen von der Norm.

4. Nichtlinearität: Die Vorstellung, dass eine Ursache eine bestimmte Wirkung hervorruft und diese ev. wiederum Ursache einer weiteren Wirkung sein kann, ist lineares Denken. Ein System Thinker hat erkannt, dass durch Vernetzung eine Wirkung auf ihre Ursache zurückwirken kann. Das System ist also in Feedbackschlaufen strukturiert. Bildlich gesprochen: wenn Sie versuchen, eine Unebenheit eines Tischtuchs zu glätten, kann durch Ihre Handlung woanders eine Unebenheit entstehen.

5. System Mapping: Ein System Thinker hat verschiedene Werkzeuge, um das System abzubilden und zuweilen sogar zu simulieren.
Ein grosse Hilfe bezüglich den Einsatz und Gebrauch solcher systemischer Werkeuge bietet das Systemswiki von Gene Bellinger, den ich sehr schätze. Auf der Einstiegsseite finden Sie das Video Systems Thinking World, das gleich in viele wichtige Tools einführt. Weiter befindet sich dort eine Liste von „Free Learning Programs“, u.a. einen Lehrpfad zum „Certified System Thinker. Gene’s Materialien sind sehr praxisbezogen und toolorientiert.

Eine interessante Gegenüberstellung von acht verschiedenen Definitionen nehmen Ross D. Arnold und Jon P. Wade in
A Definition of Systems Thinking: A Systems Approach vor, um dann festzustellen, dass jede Definition eine Auswahl aus folgenden Aspekten trifft:

  • Interconnections/Interrelationships
  • Wholes rather that parts
  • Nonlinear Relationships
  • Stock and Flow Relationships
  • Delays
  • Feedback Loops
  • Dynamic Behavior
  • Acknowleding that systems are important
  • System as the cause of its behaviour
  • System structure generates behaiviour

Der Artikel enthält einige schöne und verständnisfördernde Grafiken. Es lohnt sich, reinzuschauen.

Watersfoundation ist eine Institution mit der Vision,

to increase the capacity of educators to deliver academic and lifetime benefits to students through the effective application of systems thinking concepts, habits and tools in classroom instruction and school improvement

und eine wahre Fundgrube für ST Themen. Es gibt dort auch eine schöne Grafik zu den Habits of a System Thinker. Es gibt sogar eine App, die Sie für nur 1 $ auf Ihr Smartphone laden können. Ein virtueller Weg, um die Gewohnheiten eines System Thinker zu erleben und zu üben. Suchen Sie im App Store oder in Google Play nach „ST Habits“!

Wozu soll das gut sein?

Laura und Derek Cabrera formulieren in ihrem Buch Systems Thinking made simple die Hoffnung, mit ST verzwickte Probleme besser lösen zu können. Unter „verzwickten (oder ‚wicked‘) Problemen“ werden wohl die aktuellen Probleme der Menschheit verstanden, wie Global Warming. Dereks Vision sind 7 Milliarden System Thinker.

Barry Clemson bringt in seinem Artikel What ist System Thinking – A personal Perspective die Meinung zum Ausdruck, dass wir ST benötigen, um

to deal with complex messes, situations where there are many interacting elements causing big problems

Clemson glaubt, dass der Weg zu nachhaltiger Ökonomie und effektiveren Regierungsformen nur über ST möglich sein wird.

Für mich ist das Erkennen von Neben- und Fernwirkungen einer Entscheidung eine der wichtigsten Charakteristiken von ST. Eine Lösung eines komplexen Problems kann Nebenwirkungen haben, die das Problem möglicherweise noch verstärken. Oder die Lösung bringt das Problem aktuell ohne sichtbaren Nebenwirkungen zum Verschwinden, dafür gibt es Fernwirkungen, die woanders und gar in der Zukunft viel grössere Probleme verursachen. Gerade moderne Managementkonzepte bieten schnelle Lösungen an (im ST werden sie „symptomatische“ Lösungen genannt), ohne mögliche Neben- und Fernwirkungen zu diskutieren. Das wäre für die Methode eher kontraproduktiv.

Denke ich systemisch über ein Thema nach, so komme ich zuweilen zu ganz anderen Schlüssen, als mit klassischem, linearen Denken. So steht beispielsweise im systemischen Projektmanagement der Rework Cycle im Mittelpunkt, den ich in meinem Blogartikel Die effektivste Massnahme, um Projektverzögerungen zu minimieren beschrieben habe. Der Rework Cycle ist ein ganz zentraler Punkt im Projektmanagement, wird aber in den populären Managementansätzen kaum erwähnt, weil zu wenig bekannt.

Wie wird man ein System Thinker?

System Thinking muss trainiert werden. Ein Managementkonzept verkünden, ist schnell getan, sich aber eine neue Sicht zu erarbeiten, ist einschneidend, denn „if you change the way you look at things, the things you look at change”, meint Derek Cabrera. Eines dieser „things“ könnte auch Ihr Leben sein.

Zum Training von ST hilft die bereits erwähnte App von Watersfoundation. Wenn Sie sich entscheiden, ein System Thinker zu werden, dann arbeiten Sie täglich eine Stunde mit dieser App. Krystyna Stave and Megan Hopper unterscheiden in What Constitutes Systems Thinking? A Proposed Taxonomy verschiedene Stufen auf dem Weg zu einem System Thinker und schlagen zwischen „Low Level“ und „High Level of ST“ sogar ein Kontinuum vor. Basics sind

  • Recognizing Interconnections
  • Identifying Feedbacks
  • Understanding Dynamic Behaviour.

Intemediate Skills sind:

  • Differentiating Types of Variables and Flows und
  • Using Conceptual Models

Zu den advanced skills gehören noch Stave/Hopper:

  • Creating Simulation Models und
  • Testing Policies

Gerade, weil ST eine Kompetenz ist, für die hart trainiert werden muss, die aber für eine erfolgreiche Zukunft benötigt wird, sollte sie in der Bildungsdiskussion ernstgenommen werden. ST ist nicht kritisches Denken, aber System Thinker sind grundsätzlich kritischer. Für ST in der Schule gibt es nebst Watersfoundation auch deutschsprachige Materialien.

Für die Unterstufe bietet sich Günther Ossimtitz‘ Bändchen Entwicklung systemischen Denkens an (ISBN 978-3890194943). Interessante Hinweise für den Umgang mit ST entnimmt man auch seiner Präsentation Systemisches Denken und mathematische Darstellungsmittel  oder seinem Buch Das Metanoia-Prinzip – Eine Einführung in systemgerechtes Denken und Handeln (978-3881204231).

Es ist egal, welchem Autor Sie folgen. Wichtig ist bloss, dass Sie System Thinking in allen Ihren Bildungsveranstaltungen anbieten, und wenn es anstelle von Mathematik ist.

(1) Krystyna Stave and Megan Hopper, What Constitutes Systems Thinking? A Proposed Taxonomy

oder

Leyla Acaroglu, Tools of a System Thinker.

Systemdenken in Theorie und Praxis – Teil 2

Dies ist der zweite Teil eines grösseren Artikels, den mir Margret Richter und Marco Willnecker von der SOLIDIA Managementberatung (solidia.de) in Hamburg zur Publikation in diesem Blog vorgelegt haben. Wer den ersten Teil über Systeme lesen will, klickt links unter „Letzte Beiträge“ auf „Systemdenken in Theorie und Praxis – Teil 1“.

Praktische Umsetzung des Systemdenkens

Im ersten Teil des Beitrages haben wir uns mit den Grundlagen des Systemdenkens auseinandergesetzt. Wir haben gezeigt, wie Systeme funktionieren und durch positive bzw. negative Rückkopplungen beschrieben werden können. Dieses Vorgehen hilft, auch komplexere Sachverhalte erfassen, analysieren und beschreiben zu können.

Lineare Planungsansätze haben kurze Beine

Dies ist insofern notwendig, da die aktuell weit verbreiteten linearen Planungsansätze (z. B. isolierte Betrachtung unterschiedlicher Einflussfaktoren auf ein Geschäftsfeld) nicht oder nur begrenzt in der Lage sind, komplexe Situationen zu erfassen und zu beschreiben. Komplexe Situationen zeichnen sich nicht nur durch die im letzten Beitrag beschriebenen Rückkopplungen, sondern durch eine Reihe weiterer Merkmale aus. Dies sind zum Beispiel nicht erwünschte Nebenwirkungen, wenn an einer bestimmten Stelle des Systems eingegriffen wird.

Lineare Planungsansätze basieren meist auf der Grundüberlegung, ein großes Problem in Teilprobleme zu zerlegen, für diese Teilprobleme Lösungen zu finden und im letzten Schritt die gefundenen Ergebnisse zusammenzuführen. Aufgrund der Vernetzung von Einflussfaktoren führen diese Ansätze aber nicht zum Erfolg. Gefordert ist vielmehr ein Vorgehen, das die wechselseitige Beeinflussung von Ursache und Wirkung in geeigneter Art und Weise abzubilden in der Lage ist.

Wir wollen demonstrieren, wie ein Kunde das Systemdenken erfolgreich für seine komplexen Herausforderungen einsetzen kann. Wir nehmen dabei Bezug auf unser Beispiel aus dem 1. Teil des Beitrages.

Dazu gehen wir in einem ersten Schritt von einer Entscheidungssituation aus, der sich aktuell sehr viele Unternehmen gegenübersehen, nämlich differenzierter werdenden Kundenanforderungen. Diese haben bereits in sehr vielen Branchen zu Herausforderungen geführt, da inzwischen eine Vielzahl an Modellen und Varianten angeboten werden muss, um den Bedürfnissen der Kunden gerecht zu werden. Dies zeigt sich zum Beispiel in der Automobilindustrie, wo sich die Anzahl der Modelle und Varianten innerhalb der letzten Jahre vervielfacht hat. So bietet z. B. alleine das Unternehmen BMW aktuell rund 22 Modelle und 1295 Modellvarianten an. Die Entscheidungssituation bezieht sich also auf folgende Frage:

Welche Auswirkungen hat eine gestiegene Modell- und Variantenanzahl auf das Unternehmen XY und wie soll mit den Auswirkungen umgegangen werden?

Ferner ist eine Abgrenzung des betrachteten Systems vorzunehmen, d. h. es ist festzulegen, welcher Ausschnitt aus der Realität betrachtet werden soll. Wir betrachten in unserem fiktiven Beispiel die Ebene des Gesamtunternehmens.

In einem zweiten Schritt gilt es diejenigen Beteiligten zu identifizieren, deren Interessen, aber auch Einstellungen und Ressourcen berücksichtigt werden müssen. Im vorliegenden Beispiel sind dies insbesondere die Kunden, die Produktion oder das Management. An dieser Stelle haben wir bewusst eine Begrenzung vorgenommen, um unser Beispiel nicht zu „komplex“ werden zu lassen.

Abbildung 3

Sind die Beteiligten festgelegt, gilt es, deren Interessen und Ziele zu definieren. So können für den Kunden individuelle Anforderungen an das Produkt festgestellt werden, die u. a. eine höhere Anzahl an Produktvarianten erforderlich macht. Zu berücksichtigen sind auch die Ziele des Managements, in unserem Beispiel wird ausschließlich die ökonomische Dimension der Ziele betrachtet. Für die Produktion lassen sich z. B. Qualitätsziele oder die Forderung nach geringen Ausfallzeiten feststellen.

Abbildung drei zeigt den nächsten Schritt: Hier wurden erfolgskritische Faktoren abgeleitet, Beziehungen definiert und in einem Wirkungsgefüge miteinander verbunden. Dazu wurde der Ansatz von Probst und Gomez gewählt, der einen initialen Kreislauf im Sinne eines Motors identifiziert und daran weitere erfolgskritische Faktoren ankoppelt. Der „Motor“ in diesem Beispiel ist der Zusammenhang zwischen Anzahl der Produktvarianten, der Kundenzufriedenheit, dem Absatz und Umsatz.

Das Ergebnis in unserem Beispiel ist eine sehr rudimentäre Darstellung, da wir bewusst nur wenige Beteiligte des Systems betrachtet haben: Denn: Je mehr Beteiligte ich habe, desto mehr Interessen und desto umfangreicher ist das Wirkungsgefüge.

Über eine statische Analyse mittels geeigneter Software lassen sich in einem weiteren Schritt wirksame Hebel im Wirkungsgefüge identifizieren. Dies sind in unserem Beispiel insbesondere die Faktoren „Fehler“, „Komplexität in der Produktion“ und auch die „Anzahl der realisierbaren Varianten“

Anpassungsfähigkeit des Unternehmens

Letztendlich resultiert hieraus die Fragestellung für das Management, wie eine möglichst hohe Variantenanzahl bei einem handhabbaren Maß an Komplexität und möglichst geringen Fehlern realisiert werden kann. Ein Lösungsansatz für unser Beispiel ist es, die Anpassungsfähigkeit des Unternehmens zu erhöhen, um es dadurch in die Lage zu versetzen, langfristig mit einer steigenden Variantenzahl oder sich im Zeitablauf ändernden Varianten umgehen zu können.

Ausgangspunkt für die Lösungsfindung können z. B. die biokybernetischen Lenkungsregeln nach Vester sein. Dies sind generische und allgemeine Handlungsempfehlungen für den Umgang mit komplexen Systemen.Dass es sich dabei nicht um realitätsferne Empfehlungen handelt, zeigt sich insbesondere daran, dass von Unternehmen aktuell angewandte Problemlösungsstrategien für eine steigende Variantenvielfalt – beabsichtigt oder nicht – die biokybernetischen Grundregeln befolgen.

So schlägt Vester z. B. vor, Produkte, Funktionen und/oder Organisationsstrukturen mehrfach zu nutzen. Genau dies setzt die Automobilindustrie mit dem Plattformgedanken um: ein- und dieselbe Plattform (=technische Basis als Grundlage für äußerlich verschiedenartige Modelle und Varianten) findet für mehrere Fahrzeugmodelle Anwendung – das System Unternehmen hat sich dadurch also an die steigenden Anforderungen der Kunden angepasst.

Eine weitere Regel von Vester ist, dass ein System funktions- und nicht produktorientiert sein soll. Auch dies sehen wir aktuell bei Automobilherstellern, die sich in immer stärkerem Maße nicht mehr als reine Hersteller, sondern als Anbieter von Mobilität mit einem dementsprechenden Angebot an Services und Dienstleistungen verstehen (z. B. Sharing-Modelle).

Zusammenfassend lassen sich an Hand dieses stark vereinfachten Beispiels als eine Grundregel für den Umgang mit komplexen Systemen erkennen: So ist es notwendig, eine Varietät an Meinungen, Erfahrung und Fachwissen in die Problemlösung einzubringen. Dadurch steigt die Komplexität des Systems (hier: die Komplexität des Systems “Unternehmen”)und ermöglicht es diesem, besser mit unterschiedlichen Umweltbedingungen umzugehen.

Praktisch umgesetzt werden kann dies z. B. über spezielle Workshop-Konzepte (z. B. die wintegration®), bei denen eine Ausgangsfrage definiert wird und in einem hocheffizienten Arbeitsprozess das Wissen aus allen Teilen der Organisation zur Lösungsfindung genutzt wird.

Literaturangaben:

Gomez, P., Probst, G. (1995): Die Praxis des ganzheitlichen Problemlösens.

Richter, M. (2015): Komplexitätsmanagement in der Produktion, Trainer Journal 2/15, Nr. 85, S. 12, online im Internet unter:http://www.solidia.de/komplexitaetsmanagement-in-der-produktion/, zuletzt abgerufen am 01.10.2016.

Richter, M. (2013): Erneuerung von Strategieplanungsprozessen – biokybernetisch überprüft, in Grösser, S., Schwaninger, M., Tilebein, M., Fischer, T., Jeschke, S. (Hrsg.): Modellbasiertes Management, Berlin 2013, ISBN 0947-2452, S. 181 – 195.

statista (2015): Anzahl der Modellreihen im deutschen Pkw-Markt in den Jahren 1995 bis 2015, online im Internet unter: https://de.statista.com/statistik/daten/studie/224036/umfrage/pkw-modellreihen-in-deutschland/, zuletzt abgerufen am 01.10.2016.

statista (2013): Top 10 Automobilhersteller auf dem deutschen Markt nach der Anzahl der Modellvarianten (Stand: August 2013), online im Internet unter: op 10 Automobilhersteller auf dem deutschen Markt nach der Anzahl der Modellvarianten (Stand: August 2013), zuletzt abgerufen am 01.10.2016.

Vester, F. (2002): Die Kunst vernetzt zu denken. München.

Vester, F. (1990): Unsere Welt – ein vernetztes System, München.

Von Ettingshausen, O. (2016): Grundlagen des Systemdenkens: Entscheiden in komplexen Situationen. Norderstedt.

Mit Modellen Komplexität verstehen

Im fünften Kapitel ihres Buches über digitale Kompetenz brechen die Autoren eine Lanze für Modellbildung (1). Es stimmt, dass komplexe Systeme nicht mehr berechenbar sind und daher numerische Methoden immer wichtiger werden. Komplexe Systeme können nur noch «ausprobiert», sprich «simuliert», werden. Dazu wird zunächst ein Modell des Systems benötigt. Ein Modell ist eine vornehmlich quantitative Beschreibung des Systems. Warum immer darauf hingewiesen wird, dass Modelle Vereinfachungen seien, ist mir nicht klar. Hartmann und Hundertpfund sprechen von «Weglassen von Details», wodurch die übergeordneten Strukturen sichtbar werden sollen.

Mentale und explizite Modelle

Wir sollten nicht vergessen, dass wir die Welt ausschliesslich durch Modelle wahrnehmen können. Was wir sehen oder wahrnehmen sind höchstens Modelle der Realität. Dabei werden nicht unbedingt Details weggelassen. Manchmal ergänzt unser Wahrnehmungsapparat das Modell sogar mit «erfundenen» Details, wenn etwas sonst nicht zusammenpasst.

Alle Menschen generieren seit Geburt laufend mentale Modelle. Das allein reicht aber nicht mehr aus, um die gesteigerte Komplexität verarbeiten zu können. Wir müssen lernen, auch bewusst und explizit Modelle zu entwickeln. Nur, wie macht man das? Eine Mindmap ist noch lange kein Modell. Sie ist bloss ein Baum ohne Querverbindungen. Hartmann und Hundertpfund empfehlen nebst Concept Maps (2) z.B. die bottom-up Entwicklung von Wirtschaftskreisläufen. HilusDas hat der leider viel zu früh verstorbene Günther Ossimitz in seinem Büchlein «Entwicklung Systemischen Denkens» schon 2004 für die Schule gefordert (3). Er zeigt dort, wie bereits 14jährige in der Lage sind, explizite Modelle als Causal Loop Diagramme zu realisieren. Das Büchlein ist für Lehrer, die Modellbildung unterrichten wollen, ein hervorragender Leitfaden.

Spätestens auf Fachhochschulstufe ist ein Modellbildungsmodul notwendig, denn die grossen Herausforderungen lassen sich nicht mit Weltgipfeltreffen lösen. Vielmehr bedarf es der gemeinsamen Anstrengung der Professionals, die an der Zukunft bauen in Lehre, Entwicklung, Industrie und Verwaltung. Leider wird aber in den Curriculae nur spärlich Zeit eingeräumt für interdisziplinäre Modellbildungsstudien. Ich habe an der Schweizerischen Fernfachhochschule FFHS ein Modul entwickelt, das genau die von Hartmann und Hundertpfund geforderten Fähigkeiten vermittelt (4). Zuerst nähern wir uns eher deskriptiv einem Modell in Form von sogenannten «Causal Loop Diagrams».

WasserabflussDanach benutzen wir den Insightmaker, um kollaborativ quantitative Modelle zu entwickeln. Der Insightmaker ist ein online Tool, das sowohl Bestandes-Fluss-Modelle als auch agentenbasierte Modelle unterstützt und gratis benutzt werden kann. An der Modellentwicklung können alle von unterwegs teilnehmen und das Modell erweitern oder ergänzen. Jedoch: mit Tools alleine, haben die Modelle noch keine Seele.

Adrian Fröhlich schrieb (5):

In einer Epoche, in der alle mit Tools, Techniken und Methoden hantieren, stirbt das Denken aus. Wir leben in der Hohen Zeit der Zauberlehrlinge

Modellbildung lernen

Um ein komplexes System oder einen komplexen Zusammenhang zu verstehen, kommen wir definitiv nicht um Modellbildung herum. Explizite Modellbildung, die über den Toolgebrauch hinausgeht, will aber geübt sein. Es ist eine Fähigkeit und benötigt viel Verständnis sowohl für das zu modellierende System als auch für die Modellierungssprache schlechthin. Modellbau ist nicht einfach Kommunikation. Man muss schon genau nachdenken und zu Bleistift und Papier greifen. Es ist deshalb nicht verwunderlich, dass Modellbildung so stiefmütterlich behandelt wird. Hartmann und Hundertpfund schreiben:

Die Förderung des Abstraktionsvermögens und der Modellbildung setzt voraus, dass sich die Lehrpersonen selbst immer wieder auf eine «grosse Flughöhe» begeben, um nicht in den Details eines Themas verhaftet zu bleiben

Das sagt sich so einfach. Zunächst müssen die Lehrenden selbst eine Ahnung von Modellbildung haben. Das geschieht nicht von heute auf morgen und kann auch nicht in einem Kurs gelernt werden. Man muss sich täglich und aktiv damit beschäftigen, üben, scheitern und wieder versuchen. Das ist, was ich «lernen» nenne. Es beeinträchtigt auf jeden Fall den gewohnten Tagesablauf. Ich beschäftige mich jetzt seit gut 20 Jahren mit Modellbau à la System Dynamics und bin noch lange nicht am Ziel.

Wenn wir uns mit komplexen Systemen beschäftigen wollen, dann müssen wir die Fähigkeit der Modellbildung ab der Primarschule üben und später, in Pädagogischen und Ingenieurhochschulen quantitativ weiterentwickeln. Das ist unbequem, weshalb niemand Interesse daran hat. Also wursteln wir weiterhin in der immer komplexer werdenden Welt herum, in der Hoffnung, zufällig den richtigen Hebel gefunden zu haben.

(1) Werner Hartmann, Alois Hundertpfund: Digitale Kompetenz. Was die Schule dazu beitragen kann, hep verlag, 2015, 176 Seiten, 978-3-0355-0311-1

(2) Ein gutes Concept Map Tool kann hier gratis herunter geladen werden:

(3) Günther Ossimitz, Entwicklung systemischen Denkens – Theoretische Konzepte und empirische Untersuchungen. Profil Verlag 2004, 978-3-89019-494-3

(4) Fernfachhochschule Schweiz, FFHS: Methoden und Modell zur Entscheidungsunterstützung 

(5) Adrian W. Fröhlich:  Mythos Projekt – Der Ausweg aus der systembedingten Sackgasse. Galileo Press, 2001. 978-3898421539

Projekte sind soziotechnische Systeme und erfordern Rationalität

Das diesjährige PMCamp Berlin, das vom 10. bis am 12. September stattfindet, steht unter dem Thema „Komplexität“. Für mich ist Komplexität eine Voraussetzung eines Systems, damit es seine Funktion erfüllen kann. So benötigt ein Projektsystem eine gewisse Komplexität, um das Projektziel zu erreichen. Würde man die Komplexität des Projekts reduzieren, könnte es das Ziel nicht mehr erreichen.

Aspekte soziotechnischer Systeme

Turbulent kann ein Projekt sein, weil seine Gegebenheiten ständig ändern (Dynamik) oder weil es sich anders entwickelt, als wir erwartet haben (Ungewissheit). Menschen, die in solchen Systemen entscheiden müssen, neigen dabei zu folgendem Verhalten:

  • Denken in linearen Ursache-Wirkungsketten
  • Nichtbeachtung von verzögertem Feedback
  • Hypothesenbildung aufgrund vermeintlicher Korrelation
  • Fehleinschätzung exponentieller Entwicklungen und von Wahrscheinlichkeiten

Ursache-Wirkungsketten

Passiert etwas Unvorhergesehenes, fragen wir sofort, wie das passieren konnte. Wir wollen die Ursache wissen, in der Meinung, man müsse bloss diese Ursache entfernen, damit die ungewünschte Wirkung nicht wieder auftritt. Das ist eine irrige Vorstellung. Bekannt ist das Ehepaar von Paul Watzlawick: Er geht ins Wirtshaus, weil er vor seiner nörgelnden Frau flüchtet, während sie ihm Vorwürfe macht, weil er ständig im Wirtshaus ist.

Den linearen Ursache-Wirkungsketten stehen die System-Archetypen gegenüber, die viele Projektsituationen als Ursache-Wirkungszyklen modellieren.

Verzögerter Feedback

Fast jede Handlung bewirkt nicht nur, was sie beabsichtigt, sondern hat darüber hinaus (unbeabsichtigte) Neben- und Fernwirkungen. Speziell Projekte werden oft von Entscheidungen eingeholt, die eigentlich schon lange erledigt waren.

Haben Sie gewusst, dass es verzögerter Feedback erster, zweiter und höherer Ordnung gibt? Kennen Sie den Unterschied? Sollten Sie, wenn Sie durch turbulente Projekte navigieren wollen.

Nichtlineare Entwicklungen und Wahrscheinlichkeiten

Hier sehen Sie eine Grafik der Weltbevölkerung zwischen 1000 v. Chr. und 1800 n. Chr., ohne Angabe der Grössenordnung.  So etwas kommt in Projekten oft vor, z.B. im Zusammenhang mit der Anzahl Change Requests oder Test Failures. Setzen Sie die Kurve bis ins Jahr 2000 fort! Die meisten Personen bleiben mit ihren Schätzungen bis zum Faktor 3 hinter dem tatsächlichen Betrag zurück.

Weltbevoelkerung_blind

David Kahneman hat verschiedentlich darauf hingewiesen, wie schlecht wir im Einschätzen von Wahrscheinlichkeiten abschneiden. Welches Spiel würden Sie lieber spielen, wenn Sie es wiederholt spielen könnten?

Sie erhalten acht Franken mit einer Wahrscheinlichkeit von 1/3

Sie erhalten drei Franken mit einer Wahrscheinlichkeit von 5/6

Die meisten Versuchspersonen entscheiden sich für das zweite Spiel, weil es anscheinend einen sichereren Gewinn verspricht. Aber im ersten Spiel haben Sie auf die Dauer mehr gewonnen.

Vermeintliche Korrelation

Nehmen wir an, in einem Projekt verhalten sich zwei Grössen auffällig ähnlich, z.B. so:

korrelation_blind

Der Korrelationskoeffizient beträgt 0.9926. Wir neigen in diesem Fall schnell dazu zu vermuten, dass die beiden Grössen etwas miteinander zu tun haben. Diese Hypothese über das Funktionieren des Projekts dient uns dann als Grundlage für unsere Entscheidungen.

Das obige Beispiel stammt aus dem neuen Buch „Spurious Correlations“ von Tyler Vigen. Die beiden Kurven geben übrigens die Entwicklung der pro Kopf Konsumation von Margarine einerseits und der Scheidungsrate im amerikanischen Maine andererseits zwischen 2002 und 2009 wieder.

Wir neigen in der Tat dazu, Zusammenhänge zu vermuten, wo gar keine sind.

Systemische Darstellungsmittel müssen nicht zwingend „komplex“ sein

Beschränkungen menschlicher Kognition manifestieren sich gerade bei ganzheitlichen Wahrnehmungsautomatismen. In komplexen Projektsystemen ist jedoch genügend Zeit, darüber bewusst zu reflektieren. Dabei kann die Ganzheitlichkeit auf der Strecke bleiben. Rationale Reflektion findet in geeigneten Modellen statt und bedarf systemischer Darstellungsmittel, um den Zusammenhang zur Ganzheitlichkeit nicht zu verlieren. Erkenntnisse aus dem Reflektionsprozess müssen nachträglich durch Achtsamkeitsübungen wieder in die Gesamtsicht eingepflegt werden.

In „Projektdynamik – Modelle für komplexe Umgebungen“ stelle ich die geeignetsten Darstellungsmittel vor. Das Buch kann frei heruntergeladen werden.

Auf Seiten 184ff erkläre ich den Umgang mit der Zeit und was es mit verzögertem Feedback auf sich hat. Ab Seite 202 folgt ein Tutorial zu nichtlinearen Entwicklungen und Wahrscheinlichkeiten. Auf den Seiten 219 bis 234 führe ich in die Verwendung von Causal Loop und Stock-and-Flow-Diagrams ein. Und auf Seiten 235ff zeige ich die kognitive Kraft von Modellen.

Der Verstand kann Defekte der unbewussten Kognition ausgleichen

In „Gestaltungsansätze für Soziotechnische Systeme“ (2005) stellen die Autoren eine Methodenhierarchie auf. Die mathematischen Ansätze des Operations Research werden auf „naturwissenschaftliches Denken“ reduziert, das soziotechnische Systeme nicht voll erfassen könne. Auch mit der nächst höheren Stufe, der Systemanalyse, sei

die Analyse komplexer Systeme … nur begrenzt möglich

Die Autoren schreiben:

Zur effizienten Bewältigung der Analyse und Gestaltung von soziotechnischen Systemen sind darüber hinaus Methoden und Werkzeuge erforderlich

und stellen dann Systeme, wie ERP, Datenmanagementsysteme, Managementinformationssysteme, Systeme des Wissensmanagement, Workflowsysteme, etc. vor, ohne sich Rechenschaft abzugeben, dass diese Systeme gerade auf den eingangs erwähnten Konzepten des Operations Research basieren.

Gewiss, der Artikel ist zehnjährig. Er drückt aber eine Haltung aus, die leider nach wie vor dominiert: da zum Verständnis quantitativer Methoden beträchtliche Denkleistungen erforderlich sind, werden sie als zweitrangig und ungenügend abgetan. Damit hat man eine Entschuldigung, sich nicht damit befassen zu müssen und weiterhin rein intuitiv vorgehen zu können. Aber damit kommt man in komplexen soziotechnischen Systemen nicht weit.

Führen heisst Modellieren – aber wie?

Die uns umgebende reale Welt, insbesondere Unternehmen, Projekte, Familien und Gesellschaften können wir nur als Modelle wahrnehmen. Unser Wahrnehmungsapparat ist ein Modellierungstool. Das ist insbesondere in der Führung ein wichtiger Aspekt, denn wer die Richtung vorgibt, muss das Umfeld und die angesprochenen Menschen kennen (also modellieren) und Entwicklungen antizipieren (also voraussagen).

Modellierung und Simulation sind nicht dasselbe

Der theoretische Biologe, Robert Rosen, kommt in seinem Essay „On Models and Modeling“ zum Schluss, dass Modellierung eher eine Kunst, denn Wissenschaft sei. Er erklärt das an seiner berühmten Grafik(1).

Rosen-Grafik

Eine Simulation hat zum Ziel, das natürliche System zu beschreiben, d.h. sein Verhalten zu imitieren, um es vorauszusagen. Die innere Struktur des Simulationsmodells kümmert sich wenig um die innere Struktur des natürlichen Systems. Hauptsache, die Voraussagen stimmen!

Modellierung ist funktoriell

Demgegenüber unterscheidet Rosen ein Modell. Es hat semantische Bezüge zum externen System, das es abbildet. Die Abbildung ist in kategorientheoretischem Sinne funktoriell, indem eine Relation zwischen zwei Subsystemen des natürlichen Systems auf eine Relation zwischen den beiden Subsystembildern innerhalb des Modells abgebildet wird.

Rosen-Grafik_Funktor
Das Diagramm ist kommutativ.

 

Insofern ist ein Modell zwar viel näher an der Natur, würde aber von klassischen Wissenschaftstheoretikern als unwissenschaftlich abgelehnt, weil es die Semantik des natürlichen Systems nicht vollständig abstrahiert.

H. A. Louie erklärt den Unterschied zwischen Modell und Simulation ganz anschaulich so:

These activities are akin to the assertion that since a given curve can be approximated by a polynomial, it must be a polynomial. Stated otherwise, curve-fitting without a theory of the shape of the curve is simulation; model requires understanding of how and why a curve takes its shape.

Systemische Archetypen als Basis von Modellen

Um den Modellierungsprozess sozialer Systeme etwas zu erleichtern, gehe ich von einfachen Verhaltensmustern aus, nämlich den systemischen Archetypen, wie sie Peter Senge in der Fünften Disziplin beschrieben hat(3).  In der Kategorie der Führungssysteme sind das Limites einfacher Subsysteme. Wer schon einmal versucht hat, die Senge Archetypen zu simulieren, weiss, dass das nicht ohne weiteres gelingt. Die Archetypen sind Limites simulierbarer Systeme und als solche ausserhalb der Subkategorie der simulierbaren Systeme.

Das bedeutet, dass ein Modell immer auf Archetypen aufgebaut sein sollte und nicht umgekehrt.

 

(1) Rosen, R. On Models and Modeling.
APPLIED MATHEMATICS AND COMPUTATION 56:359-372 (1993)

(2) A.H. Louie. Robert Rosen’s anticipatory systems, foresight VOL. 12, NO. 3 2010, pp. 18-29, (Emerald Group Publishing Ltd)

(3)Senge, Peter. Die Fünfte Disziplin. Schäffer-Poeschel, 2011

Komplexitätsreduktion? Läuft bei mir nicht.

Am PMCamp in Dornbirn 2014 kam einmal mehr das Thema Komplexitätsreduktion auf. Erstaunlich, wie sich so etwas hält, trotz jahrzehntelanger Diskussion. 1956 publizierte Ashby sein berühmtes Gesetz(1). Obwohl er nicht der erste und einzige ist, der die Notwendigkeit der Komplexität oder Varietät verstand, ist seine Aussage doch die von der Öffentlichkeit am meisten akzeptierte.

Jeder hat seine eigene Vorstellung von Komplexität

In einem Pausengespräch sagte mir jemand, dass man doch nicht immer die ganze Welt in Betracht ziehen könne und sich auf einen Ausschnitt beschränken müsse. Wie wahr! Nur kümmert das die Welt nicht. Wer Mist baut und dieser anderen auf den Kopf fällt, darf sich nicht der Verantwortung entziehen. Was soll man also tun?

Das Problem beginnt mit dem Begriff „Komplexität“. Alle verwenden ihn, niemand weiss, was er bedeutet, bzw. jede Person versteht darunter etwas anderes(2). Die meisten Menschen setzen Komplexität einfach mit Intransparenz, Unordnung und hoher Varietät gleich. Für mich hat Komplexität aber weniger mit dem Sein als vielmehr mit dem Werden zu tun. Komplexität ist Dynamik, Rückkopplung und Potential zur Emergenz!

Dynamik ist in einem Projekt förderlich

Wird z.B. in einem Projekt die Dynamik und Rückkopplung reduziert, indem man strukturiert, Regeln aufstellt und Vorschriften erlässt, dann kann das dazu führen, dass das Projekt erstarrt und zusammenbricht, ins Abseits läuft oder abgebremst wird. Wenn das Projekt stoppt, kann nichts mehr schief, aber auch nichts mehr richtig gehen. Insofern erachte ich Dynamik, Rückkopplungen und Emergenzen in Projekten als förderlich, auch wenn das bedeutet, dass die Stakeholder vermehrt unter Stress stehen. Dann ist es eben eine Frage der Sichtweise, ob man Komplexität als grundsätzlich schlecht oder als hilfreich ansieht.

Vertrauen ist gut, Kontrolle ist besser?

NebelDas Problem liegt an unserem Drang, alles kontrollieren zu wollen. Das ist irgendwie ein menschliches Bedürfnis, kommt aber langsam in die Jahre. Unsere Welt ist überaus komplex geworden und kann längst nicht mehr kontrolliert werden. Wir müssen vielmehr lernen, mit Komplexität und Ungewissheit zu leben. Wir müssen uns fragen, wie wir uns im Nebel bewegen, wenn wir die Beschaffenheit des Weges vor unseren Füssen nicht mehr erkennen. Vielleicht wären Werkzeuge nützlich, wie z.B. ein Blindenstock oder ein Radar. Mit ihnen können wir zwar den Weg nicht vollständig kontrollieren, aber mindestens so viel, dass wir nicht ständig stolpern. (Zwar hinkt die Nebelmetapher! Den Weg gibt es, auch wenn wir ihn nicht sehen, die Zukunft gibt es noch nicht, sie liegt nicht im Nebel).

Das magische Dreieck der Komplexität

Es gibt solche Werkzeuge. Jedoch kommt hier ein ähnliches Gesetz, wie das von Ashby, zum Zuge: Das „Thorngatesche Postulat der angemessenen Komplexität“. Es besagt, dass von den drei metatheoretischen Tugenden „Allgemein, Genau und Einfach“ bloss stets zwei wahrgenommen werden können und die dritte vernachlässigt werden muss(3). Das bedeutet: allgemeingültige und einfache oder vereinfachende Handlungsanweisungen oder Methoden für Projekte sind Beliebigkeiten, d.h. Blahbla.

Modelle helfen, den Weg zu finden

ProjectscopeDaher würde ich auf Allgemeingültigkiet und Präzision setzen und die Forderung nach Einfachheit fallen lassen. Die gesuchten Werkzeuge, um in ungewissen und hochdynamischen Projekten zu bestehen, sind Modelle und Modellbildung. Mit Modellen lässt sich zwar auch nicht die ganze Welt einfangen, aber es kann zumindest untersucht werden, wo das Projekt „klemmt“ und welche Auswirkungen unsere Policies haben, auch ausserhalb des Projekts. Hier denke ich insbesondere an

  • Causal Loop Diagrams
  • System Dynamics
  • Bayesianische Netze
  • agentenbasierten Modelle.

Mit den heute zur Verfügung stehenden Möglichkeiten im Web 2.0, können alle, die sich dafür interessieren, unkompliziert die kompliziertesten Modelle bauen(4).

Quallen:

(1) R. Ashby: An introduction to Cybernetics. Wiley, New York 1956.

(2) M. Sussman: Ideas on Complexity in Systems – Twenty Views. 2000

(3) Karl E. Weick: Sources of order in Underorganized Systems: Themes in Recend Organizational Theory. In: Karl E. Weick (Hrsg.): Making Sense of the organization. University of Michigan/ Blackwell Publishing, Malden, MA 2001, ISBN 0-631-22317-7, S. 32–57

(4) Insightmaker für System Dynamics, Causal Loop Diagramme und agentenbasierte Modelle. GeNIe für bayesianische Netze. Beide sind gratis und dennoch professionell. Beide habe ich getestet und viel Erfahrung damit gesammelt.

Die effektivste Massnahme, um Projektverzögerungen zu minimieren

Am PM Camp in München, Ende Juli 2014, habe ich den Rework Cycle vorgestellt. Im Prinzip ist es ein Hauptschlüssel für erfolgreiches Projektmanagement. Das Rework Cycle Modell geht davon aus, dass vermeintlich erledigte Arbeiten nachgebessert oder wiederholt werden müssen, z.B. wegen Fehlern oder weil Policies geändert haben.

Der Rework Cycle

Der Bauingenieur David Ford berichtet von zwei Atomkraftwerkbauten (1). Während der Bauzeit flossen aus Erfahrungen beim Betrieb anderer AKW neue Bauvorschriften ein. Ich konnte das in meinen IT-Migrationsprojekten bestätigen. Die Systeme, die wir installierten, waren kurz vorher woanders in Betrieb genommen worden. Uns erreichten Meldungen über Laufzeitfehler, die unter Last auftraten. Das führte dazu, dass wir gewisse Tests wiederholen mussten, neue Lastverteilungsmassnahmen einbauen oder die geplanten Konfigurationen ändern mussten. Solche unvorhergesehenen Massnahmen sind die Ursache des Rework Cycle.

Die in realen Projekten gewonnen Daten stimmen so gut mit der Simulation des Modells überein, dass es heute ausser Zweifel steht, dass der Rework Cycle in jedem Projekt auftritt und es aufbläst. Wer den Rework Cycle ausser Acht lässt, wird sich regelmässig über Projekte wundern, die ihr terminliches Ziel nicht erreicht haben und die Ursache in Bereichen suchen, die gar nichts mit dem Problem zu tun haben, z.B. Kommunikation oder Management Awareness.

Wie umgeht man den Rework Cycle?

Gar nicht! Er ist Gesetz. Man kann aber die terminverzögernden Auswirkungen dämpfen, wenn man das Modell kennt. Dieses geht davon aus, dass die durchgeführten Arbeiten nicht gleich auf den Haufen „Erledigt“ kommen, sondern zuerst auf einen Haufen „zu begutachten“. Erst diejenigen Arbeiten, die sich bei der Kontrolle als gut erweisen, kommen auf den Haufen „Erledigt“. Die anderen müssen nachgebessert oder wiederholt werden. Sie kommen daher vorläufig auf den Haufen „Rework“.

ReworkCycleBasisMan sieht nun deutlich: Das Projekt wird nur dadurch fertig, indem man sich des Haufens „zu begutachten“ annimmt. Natürlich müssen die Originalarbeiten auch gemacht werden, aber „durchgewunken“ werden sie erst durch die Kontrolle. Das bedeutet, dass häufige Kontrollen das Projekt mehr voranbringen, als z.B. nur eine einzige Endkontrolle. Peter Lancy von der PA Consulting Group will das sogar genau wissen (2). Er hat gezeigt, wie sich die Laufzeit eines Projekts erhöht, wenn nur eine „grosse“ Schlusskontrolle, statt vier über das Projekt verteilte Kontrollen, gemacht wird. Aus seiner Grafik entnimmt man z.B., dass ein Projekt, in welchem die „Qualität“ (= Anteil an Arbeiten, die bei der Kontrolle auf den Haufen „Erledigt“ kommen) 0.85 beträgt dreimal länger geht als geplant, wenn nur eine Kontrolle gemacht wird und unwesentlich länger als geplant, wenn vier Kontrollen gemacht werden.

ProjektLaufzeit_Rework_LancyDer Anteil derjenigen Arbeiten, die bei der Kontrolle auf den Haufen „Erledigt“ kommen, werden in Lancys Grafik „Qualität“ genannt. In der Tat hängt es von diesem Anteil ab, ob das Projekt je fertig gestellt werden kann oder nicht. Es gibt einen „Kipp-Anteil“ (sog. tipping point), bei welchem das Projekt sozusagen an Ort tritt. Ist der Anteil höher als dieser Kippanteil, kommt das Projekt voran, andernfalls fällt es immer mehr zurück.

Damit heisst der Haupterfolgsfaktor: In einem Projekt so oft Reviews und Kontrollen machen, wie es nur geht! Das klingt einfach und selbstverständlich. Aber unterlassene Kontrollen sind der Hauptgrund für Verzögerungen in Projekten!

(1) Taylor, T./Ford, D. Tipping point failure and robustness in single development projects. Syst. Dyn. Rev. 22, 51–71, (2006)

(2) Lancy, P. Development Inefficienties – Managing the „Rework Cycle“ in Complex Projects. Australian Construction Law Newsletter ACLN, Issue #55, 1997

Sind unbeabsichtigte Nebenwirkungen einfach nur Kollateralschäden?

Wie wir bei Judith Neumer gesehen haben, gibt es keine Patentrezepte, um das Unerwartete zu vermeiden[1]. Unerwartetes passiert eben und zwar unerwartet. Wir können höchstens geschickter oder ungeschickter darauf reagieren.

Judith Neumer hat aber ein paar Tipps gegeben, wie wir das Nahen eines unerwarteten Ereignisses erspüren könnten, z.B. indem wir unser Umfeld sehr aufmerksam beobachten. Judith Neumer hat auch gesagt, dass wir das Unerwartete möglicherweise etwas reduzieren können, indem wir unseren Handlungen einen Sinn geben.

Zwei Arten von Unerwartetem

Ich unterscheide zwei Arten von Unerwartetem:

  1. Ein externes Ereignis passiert, das von uns völlig unabhängig ist. Z.B. ein grösserer Meteorit fällt uns auf den Kopf. Umgangssprachlich wird so etwas als „Schicksalsschlag“ bezeichnet. Wir konnten es nicht erahnen, und sogar wenn, hätten wir nichts dagegen unternehmen können.
  2. Ein Ereignis passiert, das wir indirekt mitverschuldet haben, aber auf derart intransparenten Wegen, dass wir niemals damit gerechnet haben, so dass es uns tatsächlich unerwartet einholt.

Für die zweite Art gibt es zu den Neumerschen Tipps weitere Möglichkeiten, und sie warten gerade in der Systemtheorie auf uns. Ich spreche hier aber von allgemeinen Systemtheorien und nicht von der Luhmannschen. Es gibt unzählige Systemtheorien, angefangen von den biologischen eines Ludwig van Bertalanffy oder eines Humberto Maturana, über die kybernetischen eines Wiliam Ross Ashby oder Norbert Wiener, bis hin zu den mathematischen Katastrophen- und Chaostheorien[2].

Die Systemtheorie Jay W. Forresters beschäftigt sich mit vernetzten Wirkungsdiagrammen. Je mehr ich mich für etwas einsetze, desto intensiver die Wirkungen meiner Interventionen. Einige Wirkungen sind von mir beabsichtigt, andere nicht. Die Auswirkungen meiner Handlungen haben wiederum Auswirkungen und diese wieder. So ist es möglich, dass gerade die nicht beabsichtigten und mir nicht bewussten Auswirkungen meiner Handlungen zeitverzögert auf mich zurück wirken und meine Absichten unerwarteterweise zunichte machen.[3]

Ungewollte Fern- und Nebenwirkungen im (Projekt)Management

Das bekannte Beispiel ist das Einsetzen von mehr Mitarbeitern, wenn ein Vorhaben oder Projekt droht, nicht rechtzeitig fertig zu werden. Wenn Ihre Gäste schon bald vor der Türe stehen und Sie noch nicht bereit sind, ist es das Naheliegendste, jemand zu bitten, Ihnen zu halfen und einige offene Tasks zu übernehmen. Zumindest in der Softwareentwicklung weiss man seit Brooks, dass der Einsatz zusätzlicher Arbeitskräfte bei bereits verzögerten Softwareprojekten diese nur noch weiter verzögert. Das ist das Brooksche Gesetz.[4]

Kürzlich sah ich eine Dokumentation über den Bau des Gotthardtunnels. Louis Favre hat das Projekt – wie heute üblich – schon damals unter Budget und Zeit angeboten (was ihm übrigens unerwartet das Leben kostete). Der dadurch entstandene Druck führte zu Unzufriedenheit in allen Lagern, Erschöpfung, Krankheiten und – unerwarteten – sozialen Unruhen[5].

Nun werden Sie sagen, das sei ja selbstverständlich. Erliegen Sie nicht dem Rückschaufehler![6]. Das war zum Projektbeginn alles andere als selbstverständlich. Aber mit einem Projektmodell, das auf einem Wirkungsdiagramm basiert, hätten einige der mit dem Vorgehen zusammenhängende unerwartete Entwicklungen erahnt werden können.

Systemarchetypen

Peter Senge hat zehn sogenannte Systemarchetypen beschrieben[7]. Das sind ganz einfache Wirkungsdiagramme, die die Wirkungen einer Handlung in einen bewusst-beabsichtigten und einen unbewusst-unbeabsichtigten Teil aufteilt. Die Archetypen sind Grundmuster menschlichen Handelns. Der einfachste solche Archetyp heisst „Verschlimmbesserung“ und sieht so aus:

Je einschneidender das Problem, desto dringlicher erscheint es uns, etwas dagegen zu unternehmen. Ist der Handlungsbedarf gross genug, bekämpfen wir das Problem mit Abwehraktivitäten. Dadurch schwächt sich das Problem tatsächlich oder vermeintlich ab und verschwindet vielleicht sogar vollständig. Jede Handlung hat Nebenwirkungen. Unsere Abwehraktivitäten könnten neben der Abschwächung des Problems andere Auswirkungen haben, vielleicht sogar solche, die das Problem reaktivieren und verstärken.

Weitere Beispiele findet man z.B. in [8]. Mit dem Insight Maker lassen sich solche Diagramme einfach erstellen und kommunizieren[9]. Hier [10] habe ich den Archetypus „Problemverschiebung“ auf eine Projektsituation angewendet. Würden wir unserer Entscheidungen und Handlungen proaktiv mit den Sengearchetypen analysieren, würde uns viel Unerwartetes erspart bleiben.

[1]Addor, P. Kritik von Forschungsansätzen im Umgang mit Ungewissheit zwischen Beherrschung und Ohnmacht. Dieser Blog, Nov. 2013.  http://bit.ly/18tf62H

[2]http://de.wikipedia.org/wiki/Systemtheorie

[3]Eine gute Quelle der Systemtheorie nach Jay W. Forrester bietet die System Dynamics Society: http://www.systemdynamics.org/

Eine frühe Einführung in die Theorie von Coyle, R.G. System Dynamics – the State-of-the-Art. Herbst 1978. http://systemdynamics.org/dynamica/articles/51/3.pdf

Ein moderner Abriss der Theorie von Sterman, John. Making System Thinking More Than a Slogan. November 2013. http://nbs.net/making-systems-thinking-more-than-a-slogan/

Empfehlenswert auch Gene Bellinges Systemwiki: http://www.systemswiki.org/index.php?title=Main_Page

[4]Brooks, Frederick P. Vom Mythos des Mann-Monats. Essays über Software-Engineering. Verlag moderne industier buch AG. Bonn 2003

[5] http://de.wikipedia.org/wiki/Gotthardtunnel

[6]Taleb, Nassim N. Narren des Zufalls. Die verborgene Rolle des Glücks an den Finanzmärkten und im Rest des Lebens. Wiley VCH Verlag. Weinheim 2005. S. 101f 

[7]Senge, Peter. Die fünfte Disziplin. Kunst und Praxis der Lernenden Organisation. Klett-Cotta Verlag. 2008 und

Senge, Peter et al. Das Fieldbook zur Fünften Disziplin. Klett-Cotta Verlag. 2008

[8]Z.B. unter Anchor Management Consulting. Dynamische Archetypen. http://www.anchor.ch/cms/front_content.php?idart=57

oder in Braun, William. The System Archetypes. Feb. 2002. http://wwwu.uni-klu.ac.at/gossimit/pap/sd/wb_sysarch.pdf

 [9]http://insightmaker.com/

[10]http://insightmaker.com/insight/4040

Was geschieht eigentlich in einem Projekt?

 

Was passiert bei der Abwicklung eines Projekts in Ihren Augen? Welche Grösse ändert sich im Verlauf eines Projekts?

Für mich ist ein Projekt in erster Linie ein Lernprozess. Als dynamische Grösse eines Projekts sehe ich das Mass an Wissen und Verstehen und nicht den Fortschritt beim Abarbeiten einer Work Breakdown Structure.

Abarbeiten unerledigter Arbeit?

Die klassische Sicht eines Projekts: Am Anfang hat man einen Berg von offenen Aktivitäten. Wenn alle Tasks ereldigt sind, ist das Projekt abgeschlossen.

Das erinnert an den Büroangestellten im Comic, der links auf seinem Schreibtisch ein Kästchen „unerledigt“ hat und rechts ein Kästchen „erledigt“.

So jedenfalls modelliert J. Sterman ein Projekt1.

Pich, M. et al. schreiben2

A project is often seen as a collection of simultaneous and sequential activities which together produce an identifiable outcome of value….In its simplest form, project management consists of planning, executing, and monitoring these activities.
In this section, we propose a general model of projects that takes the network of activities (including the scheduling of these activities) as a decision variable. Activities are chosen to maximize the project payoff, represented by a preference function

Eine neue Sichtweise

Mir scheint es an der Zeit, dass wir uns von dieser Sichtweise eines Projekts verabschieden, denn sie ist möglicherweise der Grund dafür, warum Projekte immer wieder scheitern.

Ich glaube nämlich nicht, dass die Menge der Aktivitäten ein Projekt ausmacht. Schliesslich kann man dieselbe Aufgabe in unterschiedlicher Weise lösen. Der eine macht ein wenig mehr, der andere etwas weniger. Der Bau eines Einfamilienhauses umfasst in den USA vermutlich weniger Aktivitäten als hierzulande.

Was hingegen den Bau eines Einfamilienhauses ausmacht ist nicht so sehr das Aufziehen der Mauern und das Verlegen der Dachziegeln, als vielmehr das Erlernen, was ein Einfamilienhaus eigentlich ist, was es umfasst und wie man in einem Einfamilienhaus lebt. Daher ist der Bau eines Einfamilienhauses für den Bauunternehmer eigentlich kein Projekt, für den Bauherrn aber schon.

Ein Projekt ist ein Lernprozess

Ein Projekt ist definitionsgemäss erst- und einmalig. Daher wissen weder der Projektführer/Unternehmer, noch der Auftraggeber/Kunde, was in einem Projekt auf sie zukommt. Sie müssen den Projektgegenstand erlernen, sie müssen verstehen, wie sich der Projektgegenstand in der speziellen Umgebung verhält und sie müssen erkennen, welche Möglichkeiten der Projektgegenstand bietet.

Beispielsweise haben wir in einem Projekt für einen Telefonbetreiber ein neues Voice Messageing System (VMS) installiert, weil das alte an seine Grenzen gestossen ist. Die Migration war ein einziger Lernprozess. Der Lieferant musste lernen, was der Kunde eigentlich genau wollte. Der Kunde musste lernen, dass gewisse Anforderungen so nicht möglich waren und dass er eingespielte Arbeitsabläufe verändern musste, um das neue System nutzen zu können. Während der Integrationstests lernte man gemeinsam, dass sich das neue System in dem speziellen Umfeld des Kunden ein wenig anders verhält, als man zu Beginn erwartet hatte. Das Projekt war abgeschlossen. als alle Beteiligten alles verstanden hatten.

Die eigentliche Arbeit – spezifizieren von Anforderungen, aufziehen von Mauern, transportieren und verbauen von Materialien, installieren von Computersystemen und Software, etc. – rückt in dieser Sicht in den Hintergrund und dient nur dem Erkennen von Fakten.

Ein alternatives Projektmodell

Während der Arbeit („Work in Progress“, WIP) ergeben sich Fakten, die man möglicherweise zunächst nicht richtig versteht. Man legt dann die Aufmerksamkeit auf diese Fakten und bildet Hypothesen, die man zu verifizieren versucht. Wenn man das Gefühl hat, die Fakten verstanden zu haben, kommen sie in den Topf der bestätigten (oder erledigten) Fakten. Sollten sich später eine neue Faktenlage ergeben, die dem bisherigen Verständnis widerspricht, müssen die erledigten Fakten möglicherweise revidiert werden. Das Einverleiben scheinbar verstandener Fakten nenne ich „Informationsdissipation“, analog der Energiedissipation bei der Verrichtung von Arbeit3.

Das ist der allgemeine Lernprozess, wie er in Projekten abläuft. Anstatt dass unerledigte Aufgaben erledigt werden, werden vielmehr Tatsachen gelernt. Das macht ein Projekt aus, nicht das Erledigen von Aufgaben und Tasks.

1Sterman, J.D. Business Dynamics – Systems Thinking and Modeling for a Complex World. McGraw-Hill. Boston, 2000
2Pich, M., Loch, Ch., De Meyr, A. On Uncertainty, Ambiguity, and Complexity in Project Management. S. 1011. Management Science © 2002 INFORMS
Vol. 48, No. 8, August 2002 pp. 1008–1023
3Addor, P. Projektdynamik – Komplexität im Alltag. S. 62. Liebig Verlag. Frauenfeld, 2010

Realismus ist nur ein beschönigender Ausdruck für einen Reduktionismus

In Kritik der Systemtheorie, Systembiologie, Kybernetik, Chaostheorie, Spieltheorie1  kritisieren sehr zornige Menschen verschiedene wissenschaftliche Ansätze zur Komplexitätsbewältigung. Sie erklären sie allesamt zu Instrumenten des Establishments, mit denen es die arbeitende Bevölkerung kontrollieren und unterdrücken will. Der Duktus und die Agressivität dieser Argumente erinneren mich stark an die bemühenden Diskussionen der diversen marxistisch-leninistisch-trotzkistisch-maoistischen Splittergruppen, die im Fahrwasser der 68er Revolution zu menschenverachtenen terroristischen Bewegungen wurden.

Vorwurf des Reduktionismus

Eines hat mir aber zu denken gegeben: die Autoren behaupten, dass die angeblich systemischen Ansätze, wie Chaostheorie, Spieltheorie oder Kybernetik im Grunde genommen genauso reduktionistisch seien, wie die alten Konzepte von Adam Smith oder Isaac Newton. Es ist zwar nicht richtig, dass die neue Weltsicht auf einer Maschinenmetapher basiert, wie es die Autoren behaupten. Die Maschinenmetapher haben wir in den 1960er Jahren eben gerade abgelegt. Ende dieser Dekade kam es nicht nur in politischer und gesellschaftlicher Hinsicht zu einem Umbruch, sondern auch in wissenschaftlicher. Die Newtonsche Weltsicht wurde von ihrem Sockel geworfen. Man verstand plötzlich, dass nicht alles berechenbar ist. Wenn heute noch jemand an der Maschinenmetapher für biologische und soziale Systeme festhält, dann hat er etwas falsch verstanden. Aber der Vorwurf des Reduktionismus bleibt.

Und in der Tat habe ich ab und zu dieselben zweifelnden Gedanken. Die Beschreibung einer Managementsituation mit eine System Dynamics Model ist reduktionistisch, die spieltheoretische Erklärung einer Handlungsoption ist ebenso reduktionistisch, genauso wie agiles Vorgehen in einem Projekt oder die Zerstückelung eines Problems in Teilprobleme, wie es das Systems Engineering empfiehlt. Es ist blosss ein anderer Reduktionismus als früher. Während man bis in die 1960er Jahre z. B. nichtlineare und nichtintegrable Differentialgleichungen ausblendete, obwohl sie die Mehrheit realer Gegebenheiten modellieren, kann man solche mittlerweile dank Computern sehr gut untersuchen. Damit kann man zwar komplexere Systeme beschreiben als früher, aber ihre Beschreibung ist ebenso reduktionistisch, wie früher die Beschreibung linearer Systeme durch Integrale.

Alternativen?

Nur, welche Alternativen haben wir? Die Empfehlung der Autoren, sich allem und jedem zu verweigern, die Hände in den Schoss zu legen und nichts zu tun, kann’s irgendwie auch nicht sein, vor allem nicht für einen Manager, der es seinen Kunden richtig machen will. Gesucht ist also ein Vorgehen, das zwar nicht wissenschaftlich, weil dann analytisch und somit reduktionistisch ist, aber doch methodisch, um es zu studieren und darüber zu kommunizieren. Empfehlungen, wie: „hör‘ dir die Sache an und entscheide dann aus dem Bauch heraus“ kann ich angesichts der mehr als zweifelhaften Wahrnehmungs- und Erkenntnisfähigkeit des Menschen nicht unterstützen2. Und Ansätze, die auf irgendwelchen Kraftzentren oder geheimen Botschaften basieren, sind mir zu esoterisch und zu unpraktikabel.

Wir sagen ja nicht, dass spiel- oder chaostheoretische Modelle die Managementsituation getreu wiedergeben. Im Gegenteil: Angesichts der Tatsache, dass ein soziales System eben gerade NICHT berechenbar ist, können wir es nur noch mit groben Pinselstrichen abbilden. Aber immerhin kann unter Umständen auch in einem Gemälde, das nur mit groben Pinselstrichen gemalt ist, etwas zu sehen sein. Ashby hat nie behauptet, dass das Modell dieselbe Komplexität haben muss, wie das zu steuernde System. Ashby sagte:

Je größer die Varietät eines Systems ist, desto mehr kann es die Varietät seiner Umwelt durch Steuerung vermindern3

Und:

Jeder gute Regulator eines Systems muss ein Modell des Systems sein4

Ein System Dynamics Modell oder ein spieltheoretisches Modell will keineswegs ein soziales System berechenbar machen. In reduktionistischen Ansätzen gibt es keine Emergenz. Dass lebende Systeme zu Emergenz fähig sind, ist uns mittlerweile klar. Chaostheoretische, kybernetische oder spieltheoretische Modelle können keine Emergenzen prognostizieren und sind somit reduktionistisch. Auch reduktionistische Modelle können aber helfen, über das System nachzudenken, um dadurch für die Dynamik des Systems aufmerksamer zu werden.

1Jorg Djuren, Olaf Weiss, Uwe Wendling. Kritik der Systemtheorie, Systembiologie, Kybernetik, Chaostheorie, Spieltheorie. 2010.
2Siehe z.B. Daniel Kahneman. Schnelles Denken – Langsames Denken. 2012
3Wikipedia, Ashbys Gesetz. letzte Bearbeitung Feb 2012.
4Addor, P. Effiziente Steuerung verlangt nach Modellen. Dieser Blog, Juli 2011

Titel frei nach Frank Fehlberg, (*1981), Historiker und Religionssoziologe