Komplexität ist für Manager, was Knoblauch für Drakula

Fast alle führenden Manager glauben, dass das Management von Komplexität zu einem der kritischsten Erfolgsfaktoren geworden ist. Das geht aus einer Umfrage unter 150 deutschen Top Managern hervor1. Gutes Komplexitätsmanagement wird an drei Resultaten gemessen:

  • niedrigere Betriebskosten
  • höhere Transparenz
  • erhöhte Agilität im Erkennen neuer Herausforderungen und in der Adaption von Lösungen

Komplexitätsdimensionen

Nur die wenigsten Manager haben aber eine Ahnung, wie sie mit Komplexität umgehen sollen, um diese Resultate zu erreichen. Die Studie “Mastering Complexity” analysiert die Meinungen der 150 Manager führender Unternehmen, die mit der zunehmenden Komplexität umgehen müssen.
Die Manager sehen drei unterschiedliche Dimensionen von Komplexität:

  • die innere Komplexität, die von organisatorischen und logistischen Prozessen, Systemen und Daten innerhalb des Unternehmens verursacht wird
  • die äussere Komplexität, die durch gesetzliche Rahmenbdingungen, Kunden, Lieferanten und Konsumenten zustande kommt und
  • die Marktkomplexität, die von Produkten, Preisen und Marken getrieben wird.

Wachstumsanstrengungen führen zu erhöhter Produktevielfalt, was sich negativ auf die Effizienz und den Preiswettbewerb auswirkt und dadurch das Wachstum bremst. Die Studie nennt diesen Zyklus “Komplexitätsfalle”. Um daraus zu entweichen, müssten neue Wege im Komplexitätsmanagement beschritten und neue Entscheidungsprzesse gefunden werden. Weg vom traditionellen Entscheidungsprozess, der auf Erfahrung, historischen Daten und funktional-orientiertem Denken beruht, hin zu einem cross-fuktionalem, auf transparenten Echtzeitdaten beruhendem Entscheidungsprozess basiert und von Simulationstools und anderen modernen IT-Mittel unterstützt wird.

Warum reduzieren und nicht erhöhen?

Nachdem die Manager richtigerweise zwischen interner und externer Komplexität unterschieden und festgestellt haben, dass sie die externe Komplexität nicht beeinflussen können, ist es schade, dass sie dann dem Grundtenor über Reduktion der inneren Komplexität verfallen. Als hätten sie noch nie etwas von William Ross Ashbys Arbeiten gehört, kommen sie nicht auf die Idee, die innere Komplexität so lange zu erhöhen, bis sich damit die äussere verstehen und bewältigen lässt.

Aber eines wird bei der Lektüre der Studie klar: Weder die Manager noch die Autoren machen sich Gedanken darüber, was Komplexität denn wirklich ist. Die vorgeschlagene Zweiteilung in “gute” und “schlechte” Komplexität ist eher verwirrend als hilfreich. Die sogenannte “schlechte” Komplexität ist nämlich gar keine Komplexität, sondern vielmehr Entropie, die beim Aufbau von (“guter”) Komplexität immer entsteht.

Augenwischerei

Die in der Studie angebotene Methodologie des Komplexitätsmanagement kommt mir – etwas vereinfacht gesagt – vor, wie der Tipp, den mir kürzlich jemand gab. Er sagte: “Wenn ich in meiner elektronischen Agenda den ganzen Monat offen habe, werde ich von den vielen Terminen erschlagen. Ich kann diese Komplexität reduzieren, indem ich nur den aktuellen Tag öffne”. Es wäre zu entgegnen:

  • Unübersichtlich viele Termine haben nichts mit Komplexität zu tun!
  • Durch die Einschränkung der Sicht auf nur einen einzelnen Tag wird die Situation nur scheinbar einfacher. Das ist Selbsttäuschung.
  • Besser wäre, die eigene (innere) Komplexität durch Erlernen und Aneignen von Zeitmanagementmethoden zu erhöhen und sich dadurch in die Lage zu versetzen, mit den vielen Terminen locker umgehen zu können.

Die Frage bleibt, weshalb die Manager den Umgang mit Komplexität als vordringlich einstufen, aber sich nicht ernsthaft damit auseinandersetzen. Wer niedrige Betriebskosten anstrebt, ist nicht wirklich an Komplexitätsmanagement interessiert. Auch Prozesse zu strukturieren und Systeme zu ordnen, ist für ein effektives Komplexitätsmanagement genau der falsche Ansatz. Ich würde vielmehr an der Ambiguitätstoleranz der Manager und ihrer Unternehmen arbeiten.

1Roesgen, R. & Schey, V. Mastering Complexity. Camelot Management Consultants. November 2012.

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

Ist agil jetzt agil oder was?

In der Diskussion zu meinem letzten Artikel Ein agiler Bastard zwischen einem Karnickel und einer Rummelfliege wird schliesslich nicht mehr auf die ursprünglichen Fragestellung eingegangen, sondern über ganz andere Dinge diskutiert als über die Frage, was “agil” denn aussmacht. Dietrich Dörner nennt das vertikale Flucht, eine Strategie, die ich auch in Projekten immer wieder antreffe.

Kriterien für agiles Projektmanagement

Natürlich geht es mir nicht um eine Definition von “agil” in engerem Sinne, sondern um die Bedeutung des Begriffs und vor allem um Kriterien, mit denen ich agiles Projektmanagement erkennen kann. Wenn ein Kunde fordert, dass ich sein Projekt agil durchzuführen habe, dann muss er mir doch erklären können, was er darunter versteht! Tut er das nicht, kann ich nur auf den Ursprung des Begriffs zurück gehen, also auf das Agile Manifest, und feststellen, dass agil etwas ist, das mit Entwicklungsprojekten zu tun hat.

Wie kann ich erkennen, ob ein Projekt agil durchgeführt wird? Der Einzige, der mir bisher brauchbare Kriterien geliefert hat, ist Ralf. Er hat immer betont, dass agiles Vorgehen inkrementell sei. Im übrigen seien lernendes Vorgehen und unmittelbare Kommunikation kennzeichnend.

Kundennutzen versus Überraschungen

Ralfs Erklärungen des Begriffs “Inkrementell” und die Abgrenzung zu “iterativ” sind sehr aufschlussreich. Nach ihm resultiert jedes Inkrement in einem Kundennutzen. Da mein hauptsächlichstes Anliegen seit jeher der Umgang mit Überraschungen in einem Projekt ist, war ich bisher der Meinung, es gehe um agiles Ausweichen von unvorhergesehenen Ereignissen. Ich stellte mir tatsächlich den Haken schlagenden Hasen vor, der geschickt -sprich agil – dem Gegner ausweicht. Um den Kundennutzen brauche ich mir in Migrations- und Integrationsprojekten keine Sorgen zu machen. Sie finden ohnehin beim Kunden statt, der sehr genau aufpasst, dass er bei jedem Schritt den grösstmöglichen Nutzen hat. Das ist eben der grundlegende Unterschied zu Entwicklungsprojekten, die oft “off-shore”, also abseits des Kunden, abgewickelt werden. Mir ist schon klar, dass das einmal zu einer tiefgreifenden Veränderung kommen musste, deren Ziel es war, den Kunden mehr einzubinden.

Das Problem habe ich aber gerade bei Migrations- und Integrationsprojekten NICHT. Mein Problem ist das Unvorhergesehene. Inkrementelles Vorgehen kann nützlich sein, in Form von vorsichtigen kleinen Schrittchen. Knirscht das Eis unter den Füssen, nimmt man einen anderen Weg, auf dem es weniger knirscht. Wo aber das Eis dick genug und ausgemessen ist, kann man getrost grössere Schritte machen. Ich nenne das lieber rekursives statt inkrementelles Vorgehen, weil die Schrittweite vom bisher Erreichten abhängt (siehe Was ist der Unterschied zwischen inkrementellem und rekursivem Vorgehen?). Die Schritte sind also nicht vom Kundennutzen geleitet, sondern von unvorhergesehenen Ereignissen. Das setzt grosse Aufmerksamkeit voraus. Daher spreche ich von vigilantem Projektmanagement.

Lernende Organisationen und direkte Kommunikation

Das Kriterium “lernendes Vorgehen” verlangt nach Konkretisierung. Lernen ist sehr zeitaufwändig. Eine Unternehmung kann eine lernende Organisation sein, ob ein Projekt aber die Zeit hat zu lernen, ist fragwürdig. Länger als ein paar Monate bis höchstens zwei Jahre sollte ein Projekt nicht dauern. Ob das für organisationales Lernen reicht?

Und bezüglich unmittelbare Kommunikation gäbe es auch so einiges zu sagen. Der Verkäufer des Lieferanten muss das Projekt unter dem Preis anbieten, ob er nun mit dem Projektmanager redet oder nicht. Und der Einkäufer des Kunden sagt: “Prima, wir nehmen das Angebot an, aber zu einem 25% niedrigeren Preis”. Den Projektmanagern des Kunden und des Lieferanten wird dann nur noch gesagt, dass sie jetzt zu den und den Konditionen beginnen können. Während der Projektabwicklung sprechen z.B. die CEO von Kunden und Lieferanten miteinander über das Projekt, ohne die Projektmanager oder gar -mitarbeiter einzubeziehen, etc. Ein Projekt hat viele Stakeholders, die sich möglicherweise gar nicht alle gegenseitig kennen. Wie wollen sie da denn unmittelbare Kommunikation pflegen?

Ich habe zeitlebens Projekte in multinationalen Konzernen durchgeführt. Vielleicht haben die Vertreter agiler Methoden eher kleine Unternehmen im Sinn, die von ihrer Grösse und von ihren Entscheidungsstrukturen her schon agil sind?