Exzellenz und Komplexität


Was heißt es eigentlich, als Beraterin [1] „exzellent“ zu sein? Wann habe ich „einen guten Job“ gemacht und wann eher nicht? Und was bedeutet der Exzellenzanspruch in einem Krisenprojekt, in dem Zeit und Geld nicht reichen und die ursprünglichen Ziele nicht mehr erreicht werden können? Diese Fragen haben mich in den letzten Jahren immer wieder beschäftigt. In der Diskussion mit jüngeren Kollegen und Kolleginnen bei Xenium ist mir aufgefallen, dass sie mit ihrer Arbeit häufig unzufrieden waren, weil sie meinten, die Aufgabe nicht gut genug erfüllt zu haben – ich dagegen war häufig  ganz anderer Meinung. Offensichtlich hatten wir da unterschiedliche Maßstäbe. Woher kommt das?

Ich glaube es kommt daher, dass „Exzellenz“ in einer komplexen Umgebung eine gänzlich andere Bedeutung hat als in einer komplizierten. 

Für die Unterscheidung zwischen komplex und kompliziert stütze ich mich dabei auf Dave Snowdens Cynefin-Modell[2] (Original-Artikel: https://hbr.org/2007/11/a-leaders-framework-for-decision-making; der englische Wikipedia-Eintrag gibt einen guten Einstieg, der deutsche ist weniger gut.) Snowden unterscheidet vier Domänen: einfach, kompliziert, komplex, chaotisch. Der entscheidende Punkt ist, dass die Problemlöse-Strategien sich signifikant unterscheiden, je nachdem in welcher Domäne ich mich befinde.

Bei einem komplizierten Problem heißt die Strategie „Wahrnehmen
– Analysieren – Handeln“ (im Original sense – analyse – respond). Das ist die
klassische wissenschaftliche und ingenieurmäßige Herangehensweise. Das Problem wird analytisch zerlegt und Stück für Stück gelöst. Ein gutes Beispiel ist die
Automobilproduktion. Ohne Zweifel ein höchst kompliziertes Problem – wie Tesla
beim Hochfahren der Produktion für das Model 3 schmerzhaft erfahren musste.
Aber letztlich war die Menge der Einzelprobleme endlich, und mit extremem
Einsatz, Fleiß und Durchhaltevermögen wurde sie Schritt für Schritt verkleinert
und irgendwann lief der Prozess rund. Ähnlich ist es häufig bei der
Inbetriebnahme neuer Software-Systeme. Die ersten Monate sind damit gefüllt,
Kinderkrankheiten, übersehenen Fehlern und Performanz-Problemen
hinterherzulaufen. Aber wenn es keine grundlegenden Architekturfehler gibt, ist
dieser Berg irgendwann abgearbeitet. Man braucht dafür gute Nerven, ein dickes
Fell und einen langen Atem – also Zeit!

Zur selben Problemklasse der komplizierten Probleme zählen Diplom/Masterarbeiten oder Dissertationen. Die Methoden dafür sind immer analytisches Denken und konsequentes Abarbeiten einer langen Liste von offenen Fragen. Okay – für ein „Summa cum Laude“ braucht es auch noch eine Portion Phantasie und Kreativität. Die Basis ist aber immer ein gründliches, analytisches Durchdringen des Themas in Breite und Tiefe. Das erfordert immer Zeit – nicht umsonst dauert eine Dissertation Jahre.

Bestens ausgebildet in diesen Methoden tritt nun die frisch gebackene Doktorandin ihren Job als Beraterin an. Und mit was für Problemen hat sie dort zu tun? Gelegentlich sicher mit komplizierten, …

...viel häufiger aber mit komplexen!

Nach dem Cynefin-Modell unterscheiden sich komplexe Probleme grundlegend von komplizierten. Solche Probleme sind durch ein hohes Maß an internen und externen Wechselwirkungen und Rückkopplungen gekennzeichnet; das Systemverhalten ist in der Regel nicht-linear. Aus diesem Grund ist eine Prognose des Systemverhaltens kaum möglich; in der Regel gelingt es erst im Nachhinein, die zugrundeliegende Ursache-Wirkungs-Kette zu erkennen. Die Methodik der Wahl heißt daher hier “Probieren – Wahrnehmen – Antworten“ (probe – sense – respond). Was heißt das genau? „Probieren“ (engl. to probe) heißt, sich dem Problem durch kleine, überschaubare Schritte zu nähern. Im besten Falle sind diese Schritte schon Teil der künftigen Lösung; es kann aber auch sein, dass etwas unerwartetes passiert. Deswegen sollte jeder Schritt weder besonders groß noch besonders aufwändig sein. In der Holocracy gibt es die schöne Frage : „Is it safe enough to try?“. Wenn es gut gegangen ist, hat man erstens etwas gelernt und zweitens kann man darauf im nächsten Schritt aufbauen. Wenn es schiefgegangen ist hat man auf jeden Fall etwas gelernt.

Der zweite Schritt „Wahrnehmen“ (to sense) bedeutet, die Ergebnisse eines jeden Schrittes nüchtern und vorurteilsfrei anzuschauen – und zwar das was funktioniert hat genauso wie das was schiefgegangen ist. Entscheidend ist dabei, sich nicht in die eigenen Ideen über das Problem zu verlieben; denn je besser die Wahrnehmung und das daraus erwachsende Verständnis ist, desto besser kann man den nächsten Schritt unternehmen.

Die gute Wahrnehmung ist deshalb entscheiden für die Qualität des dritten Schrittes: „Antworten“ durch Planung des nächsten „Probierens“.

Ich habe das englische „to probe“ bewusst mit „Probieren“ übersetzt – das ist im Kern das was man in einer solchen Situation tut. Das scheint auf den ersten Blick mit „Exzellenz“ nicht viel zu tun zu haben. Bei komplexen Problemen ist dies in Wahrheit jedoch der schnellste und effizienteste Weg zu einer Lösung, manchmal sogar der einzige. Allerdings sind die Lösungen, die auf diesem Weg entstehen, das Ergebnis vieler aufeinander folgender Schritte, in deren Verlauf das Wissen Schritt für Schritt gewachsen ist. Sie können daher niemals „aus einem Guss“ sein.

Worin liegt nun hier die Exzellenz? 
In der klugen Auswahl der Iterationsschritte,
der Präzision und Nüchternheit der Wahrnehmung der Lage und
der Schnelligkeit und Treffsicherheit der Antwort.

Statt einer gründlichen und langwierigen Analyse also das
schrittweise, experimentelle Herantasten an die Funktionsweise des Systems.
Menschen, die bestens in analytischer Methodik ausgebildet sind, tun sich damit
erst einmal schwer.

Ein Beispiel aus meiner eigenen Projekterfahrung: von 2004-2006 habe ich das IT-Projekt für das Arbeitslosengeld II („Hartz IV“) begleitet. In diesem Projekt war sehr viel neu und dynamisch

  • Das Gesetz selbst war keine einfache Weiterentwicklung der bis dahin geltenden Arbeitslosenhilfe. Viele Regelungen waren neu und in der Praxis noch nicht erprobt.
  • Das Konsortium, das den Auftrag für die Erstellung des Systems erhielt, bestand aus der T-Systems und dem kleinen Dienstleister Prosoz. Diese beiden höchst unterschiedlichen Organisationen hatten noch nie zusammengearbeitet. Die Verantwortlichen auf beiden Seiten kannten sich nur oberflächlich und waren mit der Arbeitsweise der jeweils anderen Organisation nicht vertraut.
  • Die Architektur war ungewöhnlich: eine Informix-Datenbank, ein Anwendungskern aus dem existierenden Prosoz-System für die Sozialhilfe mit großen Umbauten und Erweiterungen sowie einer neu zu entwickelnden Web-Oberfläche. Ob sich diese Architektur auf das erforderliche Mengengerüst – 30.000 Anwendern in den Arbeitsagenturen, Daten von fast 7 Millionen
    Antragstellern – würde skalieren lassen war nicht sicher.
  • Das Arbeitslosengeld II war ein zentraler Bestandteil der Arbeitsmarktrefomen der damaligen rot-grünen Bundesregierung unter Kanzler Schröder. Das Projekt stand daher mehr und mehr unter politischer Beobachtung – von Befürwortern wie Gegnern.
  • Der Zeitrahmen zwischen Februar 2004 und Oktober 2004 war extrem eng.

Niemand konnte zu Beginn des Projektes auch nur im Ansatz erahnen, welche Dynamik sich im Laufe des Jahres entwickeln würde und was die größten Probleme werden würden. Der Versuch, diese Probleme mit analytischen Methoden vorherzusehen und dann zu lösen wäre mit Sicherheit gescheitert; es blieb nur das schrittweise Herantasten an den go-live-Termin über mehrere Releases mit jeweils wachsender Funktionalität. Jedes Release brachte neue Erkenntnisse – und neue Überraschungen. Unter höchstem Einsatz auf Seiten der Projektteams wurde so schließlich Anfang Oktober ein Stand erreicht, der technisch halbwegs stabil war – das glaubten wir jedenfalls – und keine Prio-1-Fehler mehr enthielt. Funktional gab es noch erhebliche Lücken ; diese mussten durch manuelle  „Umgehungslösungen“ überbrückt werden. Auf dieser Basis wurde Anfang Oktober 2004 vom Ministerium auf Empfehlung des Vorstandes der Bundesagentur und der Verantwortlichen der Lieferanten beschlossen, mit der Erfassung der Ca. 3,5 Mio. Anträge zu beginnen.

Und wieder traten ganz neue Probleme auf: Performance, Stabilität, fachliche Fehler. Jeden Tag eine neue Überraschung. Und jeden Tag aufs Neue „probe – sense – respond“. Nichts davon war perfekt – aber das meiste hat funktioniert. Irgendwann Ende November war klar: wir werden es schaffen, alle Anträge zu erfassen, die Ansprüche zu berechnen und Bescheide zu erteilen. Und tatsächlich begann im Januar 2005 die Auszahlung von Arbeitslosengeld II an 6,75 Mio. Menschen.

Die geneigte Leserin wird es ahnen: die Leidensgeschichte war damit nicht beendet, nur ein neues Kapitel aufgeschlagen. Immer wieder tauchten in Produktion neue Probleme auf – aber letztlich gelang es über die folgenden Jahre, das System schritt für Schritt zu stabilisieren und Fehler zu beseitigen. Und das wichtigste: Der bei weitem größte Teil der Berechtigten hat von Anfang an Monat für Monat korrekt sein Geld erhalten.

Zurück zur Ausgangsfrage: War das eine exzellente Leistung? Trotz massiver Performance- und Stabilitätsprobleme, fachlicher Fehler und funktionaler Lücken?

Ja, absolut! Und ich bin bis heute stolz darauf, einen Beitrag dazu geleistet zu haben. 

Ab April war klar, dass wir am Abgrund stehen. Auch auf Seiten der Lieferanten endete zu diesem Zeitpunkt das Schönreden. Die Bereitschaft zu mutigen, aber schmerzhaften Entscheidungen war da. Der Funktionsumfang wurde auf das nötigste beschränkt, der Projektplan gestrafft und die Verantwortlichen in der Politik eingebunden. Aus meiner Sicht waren folgende Dinge am wichtigsten:

  • Es gab von Anfang an einen Plan für ein gestuftes Vorgehen mit mehreren Releases. Das war eine sehr gute Grundlage für das schrittweise Lernen und Verstehen.
  • Erkenntnisse aus den ersten Stufen und den Last- und Funktionstests wurden furchtlos [3] zur Kenntnis genommen, auch wenn  sie unangenehm waren; bei Bedarf wurden Plan, Architektur – ja, sogar die Architektur! – und Vorgehen angepasst.
  • Zwischen den zwischenzeitlich heillos zerstrittenen Projekt-Parteien setzte sich durch verschiedene Vermittlungsbemühungen eine konstruktive, Lösungsorientierte, „open-minded“ Haltung durch.

Auf diese Weise gelang es, durch überschaubare Schritte_(„probe“), Wahrnehmen und Lernen („sense“) und angemessene, überlegte Maßnahmen („respond“) in extrem kurzer Zeit und trotz hoher Risiken eine funktionierende Lösung bereit zu stellen. Weder die Architektur noch die Methodik noch die Art der Zusammenarbeit waren – gemessen an den Vorgaben der Lehrbücher – perfekt. Aber die Lösung war gut genug, um ab Januar 2005 Monat für Monat den Lebensunterhalt für fast 7 Millionen Menschen sicher zu stellen. Wenn das nicht exzellent ist – was dann?


[1] Zur Abwechslung verwende ich in diesem Blog ausschließlich die weibliche Form. Damit will ich aber nicht sagen, dass die beschriebenen Fragen nur Frauen betreffen.

[2] Das Dynaxity-Modell aus dem systemischen Management hat strukturelle Ähnlichkeiten mit Cynefin und führt zu vergleichbaren Schlussfolgerungen (s. dazu der Wikipedia-Eintrag zu Dynaxity und die dortigen Originalquellen)

[3] Danke, Christoph für dieses treffende Wort!

 

Beitrag teilen?

Share on linkedin
Share on xing
Share on facebook
Share on twitter
Share on email