Das hat mich veranlasst zu vermuten, dass das Nachdenken über mögliche Konsequenzen geplanten Handelns tatsächlich nur dann stattfindet, wenn es “verordnet” ist. Man kann einfach nicht jedesmal, bevor man einen Atemzug macht, darüber nachdenken, welche Konsequenzen dieser Atemzug haben wird. Die notwendigsten Arbeiten in einem kleinen Teilprojekts eines kleinen Projekts erscheinen einam derart selbstverständlich und unbedeutend, dass es sich einfach nicht lohnt, lange über die Konsequenzen der Tätigkeiten nachzudenken, die man als nächstes auszuführen gedenkt.

Es ist einem nicht einmal klar, dass man eine Tätigkeit geplant hat. Sie haben ein Mail erhalten, auf das Sie antworten wollen, aber vorher noch einige Informationen beschaffen müssen. Das zu tun nehmen Sie sich jetzt vor. Das bedeutet, dass Sie diese Tätigkeiten – Informationsbeschaffung und Mail beantworten – jetzt geplant haben. Allerdings sind Sie nie bewusst hingesessen und haben einen Plan aufgestellt. Sie wissen intuitiv, wie Sie vorgehen wollen und werden. Der Plan ist in Ihrem Kopf, ohne dass er Ihnen bewusst ist.

Alltägliche Tätigkeiten sollten in ein grösseres Modell eingebettet sein

Erst recht werden Sie keine Analyse machen, welche Risiken die Informationsbeschaffung und/oder die Beantwortung des Mails enthalten und welche Konsequenzen daraus erwachsen können. Da aber fast alle Handlungen, auch die folgenschwersten, aus Detailhandlungen bestehen, die für sich allein einer Analyse nicht wert sind, wursteln wir uns durch die Projekte und durch das Leben, ohne viel nachzudenken. Alle unsere grossen Würfe – Unternehmensgründungen, Alpendurchtunnelungen, Städtebau, Mergers, Erarbeiten internationaler Vereinbarungen, etc. – bestehen aus einzelnen, kleinen Detailentscheidungen und -handlungen. Kleinvieh mach auch Mist!

Qualitätssicherungen (QS) verlangen zuweilen, das Durchlaufen vorgegebener Prozesse und das Vorweisen der entsprechenden Dokumente. Genauso würde ich von Unternehmens- und Projektmanagern verlangen, dass sie

• ein Modell ihres Systems, in dem sie tätig sind, erstellen
• sich bei der Arbeit stets an diesem Modell orientieren
• das Modell laufend verbessern und ergänzen.

Zwar passiert das tatsächlich und ganz automatisch. Aber die Modelle unserer Entscheidungsträger befinden sich in ihren Köpfen, sind ihnen und ihren Mitwirkenden kaum bewusst und wenig aufeinander abgestimmt. Die Modelle bewusst machen tut niemand freiwillig, so wenig, wie jemand freiwillig die lästigen QS-Vorgaben einhält. Daher sollte jedem Manager ein Modellcoach oder Modellassistent zur Seite stehen.

¹Nach einem Zitat von Jacob M. Braude

Warum sind kleine Programmierfehler unvermeidlich? Weil der Entwickler niemals alle Eventualitäten voraussehen kann, auf die seine Software reagieren muss. Unerwartete Situationen sind unvorhersehbar, andernfalls wären sie nicht unerwartet. In solchen Fällen wird eine Software meistens eine Fehlermeldung ausgeben. Ganz selten – und hier war es der Fall – gibt es keine Fehlermeldung, und die Anwender merken zu spät, dass etwas schief gelaufen ist. Bei der europäischen Trägerrakete Ariane V wurde die Navigationssoftware der Vorgängerrakete Ariane IV angepasst. Dabei wurde eine Kleinigkeit übersehen, was zum Absturz der Rakete führte. In der Software eines Marslandungsgerätes wurde an einer Stelle metrische mit US- Masseinheiten verwechselt, was ebenfalls zum Verlust des Geräts und zum Abbruch der Mission führte.

Der Autor der HP-Fallstudie betont, dass das Risikomanagement in den meisten IT-Projekten Sache des Business und Auftraggebers sein müsse. Stattdessen wird das Risikomanagement einfach auf die IT abgewälzt: „Seht zu, dass Ihr keine Fehler macht!“. Wie wir gesehen haben, können unscheinbare Programmierfehler riesige kommerzielle Konsequenzen haben. Das ist eine Art Schmetterlingseffekt. Das Business schneidet sich also selber ins Fleisch, wenn es die Risikoverantwortung einfach an die IT delegiert.

Die Grafik zeigt die Situation als Systemarchetypus der Problemverschiebung. Es gibt grundsätzlich zwei „Lösungen“, eine symptomatische und eine fundamentale. In unserem Fall ist die symptomatische „Lösung“ die Delegation der Risikoverantwortung an die IT. Was kann sie tun? Sie schickt ihre Leute – Entwickler und Projektmanager – in die Ausbildung und delegiert ihre Verantwortung gerade noch einmal. Immerhin: wenn die Projektmanager ein Zertifikat als „Project Management Professional“ vorweisen können, dann muss doch einfach alles gut gehen….

Wie immer ist der Weg zu der fundamentalen Lösung steiniger und mühsamer, als derjenige zu der symptomatischen. Daher wird dieser bevorzugt. Mit der Delegation der Verantwortung an die IT, entmündigt sich der Auftraggeber selbst, denn je mehr die symptomatische Lösung präferenziert wird, desto unwahrscheinlicher wird es, dass der Auftraggeber die fundamentale Lösung überhaupt versucht. Der Pfeil, der von der “Qualität der Projektführung” zum “Veranwortungsdruck auf das Business” führt, verringert letzeren Parameter. Je besser und kompetenter die Projektführung, desto unnötiger erscheint es, dass sich das Business zusätzliche Gedanken zum Risikomanagement macht. Was kann denn bei zertifizierten Projektmanagern noch schief gehen?

Dennoch sollte die fundamentale Lösung begangen werden, nämlich dass der Auftraggeber das Risikomanagement übernimmt.  Wenn ich diese Aufgabe erhielte, würde ich sämtliche Bestellungen, die in das alte Order Entry System (ERP) hinein gegangen sind, in den Produktions- und Speditionsaufträgen suchen. Wenn ich keine eindeutige Zuordnung machen könnte, würde ich die Alarmglocken läuten (siehe die beiden Abbildungen in Man schlägt den Esel und meint den Sack).

Es ist nicht Sache der IT diese Kontrolle durchzuführen, es sei denn, sie erhält einen Auftrag zur Entwicklung einer Software, die Eingänge und Ausgänge vergleicht. Das wäre ein anderes Projekt als das ursprüngliche Migrationsprojekt, welches in seinem Budget solche Kontrollen nicht vorgesehen hat. Zudem muss damit gerechnet werden, dass auch die Vergleichssoftware fehlerbehaftet ist. Daher müssen zusätzliche (menschliche) Kontrolleure eingesetzt werden.

Doch welcher Manager wagte es, solche Entscheidungen zu treffen? Wie oft hört man: “Nur keine schlafenden Hunde wecken”, bis dann einer der Hunde eben doch zubeisst.

Das klassische Projektmanagement stellt das sogenannte “Goldene Dreieck” – Budget, Termin, Qualität – in den Vordergrund. Ein Projekt muss demnach zu den vereinbarten Kosten rechtzeitig fertig werden und dabei die erwartete Qualität erreichen. Klar, wenn Ihnen der Maler einen Kostenvoranschlag zum Streichen Ihrer Küche gemacht und versprochen hat, dass Sie die Küche innert Wochenfrist wieder benutzen können, dann wären Sie bass erstaunt, wenn er die Küche während zweier Wochen belegt und dann erst noch das Doppelte des vereinbarten Preises verlangen würde. Was aber, wenn nach einer Woche alle Farbe, die der Maler verstrichen hat, plötzlich von den Wänden fällt, gerade wenn er Ihnen die frisch gestrichenen Küche übergeben will?

Termin- und budgetgetriebenes Projektmanagement ist vielleicht nicht das Richtige. Auch Scrum hilft da nicht wirklich weiter. Vielmehr sollte Projektmanagement ereignisgesteuert sein. Das ist aber nicht so einfach, wie das klassische Projektmanagement rund um das Goldene Dreieck. Die im letzten Beitrag beschriebene Fallstudie fasst das so zusammen:

Worse, a cost-and-schedule approach never holds up during a crisis… When HP saw that the order management system wasn’t working properly, it pulled out all the stops to get the code working properly—cost and schedule be damned. … when using this event-driven approach, “the project doesn’t move forward until you’ve gotten each step right.” Yet event-driven project management has its own pitfalls. It’s not infallible, and if not carefully managed, projects can drag on forever¹

Aber vielleicht hat ereignisgesteuertes Projektmanagement Potenzial. Vielleicht ist es der einzige Weg, um endlich komplexe Projekte vernünftig abwickeln zu können. Vielleicht sollten wir beginnen, unsere Projektmanager in ereignisgesteuertem anstatt in termin- und kostengesteuertem Projektmanagement auszubilden!

¹CIO. When bad things happen to good projects. 2007

Obwohl ich hier schon einmal auf den Artikel When Bad Things Happen to Good Projects¹ aufmerksam gemacht habe (Was ist billiger? Ein Mitarbeiter oder eine Zertifizierung? in diesem Blog, 29. September 2009), möchte ich nochmals mit Nachdruck darauf hinweisen. Die Lessons Learned, die man aus diesem Artikel ziehen kann, weisen eindeutig in die richtige Richtung.

Ein typisches Migrationsprojekt

Es handelt sich um eine Fallstudie eines typischen Migrationsprojekts. Nachdem HP einige Unternehmen inklusive ihren Prozessen und IT-Systemen akquiriert hat – z.B. Compaq – sah sie sich vor das Problem gestellt, die verschiedenen IT-Systeme, die dieselbe Funktionen haben, zusammen zu führen. Beispielsweise hat jede Unternehmung ein sog. Order Entry System, also eine IT-Einrichtung, die Bestellungen entgegen nimmt und in Produktions- und Speditionsanweisungen umwandelt. Die Bestellungen geben die Kunden über das Internet (bzw. das Web) direkt in das Order Entry System ein. Kleinere Kunden können ev. auch einen Support Mitarbeiter anrufen und die Bestellung mündlich durchgeben.

Bei HP ist das Order Entry System ein Teilsystem ihres SAP. Einige Unternehmen, die HP akquiriert hat, haben allerdings kein SAP eingesetzt. HP wollte nun alle Order Entry Systeme in ihrem Unternehmen auf SAP konsolidieren.

Umleiten des Outputs des einen Systems in das andere System

Das machte sie in mehreren Etappen und stets auf dieselbe Weise: Der Output eines Order Entry Systems R wurde in das SAP-System umgeleitet. Für das SAP-System waren dann die Bestellungen, die via R herein gekommen sind, gleichbedeutend, wie Bestellungen, die von einem externen Kunden kamen. Haben die Kunden, die via R bestellten, einmal begriffen, dass sie jetzt via das SAP-System bei HP bestellen müssen, kann R abgeschaltet werden.

Dazu müssen die Produktions- und Speditionsanweisungen, die das System R verlassen, in Bestellungen für das SAP-System übersetzt werden. Es braucht also zwischen dem R-System und dem SAP-System ein kleines Stück Software, das diese Übersetzung macht. HP hat diese Übersetzungssoftware für das Order Entry System einer jedem akquirierten Unternehmung geschrieben. Jedes Mal ging das gut und jedes Mal erhöhte sich die Erfahrung von HP für dieses Vorgehen bei der Übernahme einer neuen Unternehmung….bis sie die fremden Order Entry Systeme für das Servergeschäft migrieren wollten. Das Servergeschäft ist der grösste Geschäftszweig von HP.

Der Krug geht zum Brunnen bis er bricht

Die letzte und umfangreichste Migration ging schief! Die Übersetzungssoftware enthielt kleine Fehler, die dazu führten, dass viele Bestellungen im SAP-System stecken blieben und gar nie in die Produktion kamen, bzw. die bestellte Ware gar nie spediert wurde. Kunden beschwerten sich oder – noch schlimmer – wanderten ohne Kommentar ab. Der Schaden betrug 160 Millionen US-Dollar!

HP hat die Übersetzungssoftware auf Herz und Nieren getestet. Dennoch enthielt sie Fehler, denn man konnte nicht alle möglichen Bestellformate voraussehen, die die Kunden anliefern. Es gab Bestellungen, die enthielten unvorhergesehene Elemente oder Zeichen, die die Übersetzungssoftware nicht richtig interpretieren konnte. Das kann man mit den umfangreichsten und sorgfältigsten Tests nicht verhindern.

Lehren

Es gibt viele Lehren, die wir daraus ziehen können, und ich möchte in einem oder zwei Folgebeiträgen auf ein paar Lehren hinweisen, die der Autor des Artikels nicht erwähnt hat. Er betont vor allem, dass das Risikomanagement vom Business wahrgenommen werden muss und nicht auf die IT abgeschoben werden darf. Oft wird nämlich die IT “geschlagen”, obwohl man das Business meint.

Die IT versucht, durch Zertifizierung die Projektmanagement-Fähigkeiten zu erhöhen, was zwar machbar ist, aber offensichtlichs nichts taugt. Gegen die Unvorhersehbarkeit der Bestellformate hilft eben z.B. ein Gantt-Diagramm oder eine Earned Value Analysis nichts. Risikomanagement auf der Businessebene ist hingegen viel schwieriger und unangenehmer, weshalb es gerne auf die IT abgewälzt wird. Das ist der Systemarchetypus der Problemverschiebung, auf den ich im nächsten Beitrag zu sprechen komme.
Schliesslich forderte der Autor bereits 2004, dass man im Projektmanagement endlich vom Kost-Termin-Denken wegkommen sollte. Was nützt einem ein Projekt, dass kosten- und terminmässig erfolgreich abgeschlossen wurde, nachträglich dem Business aber 160 Mio Dollar Verlust bringt? Sagen Sie nicht, dass das Projekt in dem Fall nicht erfolgreich war! Es wurde vom Auftraggeber zufriedenstellend abgenommen, nachdem er sogenannte Akzeptanztests gemacht hatte, denn auch er hatte sich nicht abschliessend vorstellen können, was für Bestellungen eintreffen werden.

¹Koch, Christopher. When Bad Things Happen to Good Projects, in CIO.com, 2. April 2007

In Migrations- und Integrationsprojekten können Entwicklungsfehler zu unvorhergesehenen Ereignissen führen. Die (nachlässigen?) Entwickler haben ihr Projekt längst abgeschlossen, während das Produkt andernorts ausgerollt wird. In den dafür notwendigen Integrations- und Akzeptanztests tauchen unerwartete Produktefehler auf, die der Entwicklung nicht aufgefallen sind, weil sie in einer ganz anderen Umgebung gestetet wurden.

Unvorhergesehene Ereigniss werden sozusagen “ausgebrütet”, indem sie sich aus Fehlentscheidungen entwickeln.

Die Entscheidungen oder Handlungen sind zum Zeitpunkt ihrer Durchführung nicht eigentlich “falsch”. Erst ihre Entfaltung mit der Zeit lässt ihnen eine Bewertung zuordnen. Denken Sie an die zwei unscheinbaren Schrägstriche in einer Webadresse (URL) nach dem http:. Ihrem Erfinder schienen sie damals eine gute Idee zu sein.

In Kleine Schrägstriche – grosse Auswirkung habe ich geschrieben:

In der Zwischenzeit hat der Entscheid viele Menschen geärgert, viel unnützen Aufwand generiert, viele Werte vernichtet und angeblich vielen Bäumen das Leben gekostet.

Was damals eine “gute” Entscheidung war, erwies sich im Laufe der Zeit als fatal, so dass wir sie heute als eine Fehlentscheidung bezeichnen können. Vor allem die Tatsache, dass wir mittlerweile nicht mehr von den beiden Schrägstrichen weg kommen, war unvorhersehbar. Sowas passiert in Projekten und in der Unternehmensentwicklung allemal.

Fehlentscheide können sowohl Einzelne als auch Gruppen treffen. Manchmal “entstehen” sie spontan wie Viren in der Unternehmenskultur, ohne dass man sie einem einzelnen Individuum oder einer Gruppe zuordnen kann. Man denke z.B. an das Abilene-Paradoxon.
In einer Gruppe entsteht eine dumme Idee, die aber von allen weiter getragen und umgesetzt wird, obwohl es niemand will. Das kann erst recht in einer grösseren Organisation, wie einem Unternehmen passieren.

Es hat also wenig Sinn, sich darüber Gedanken zu machen, ob Einzelne für Unerwartetes verantwortlich sind oder das System. Der (Fehl-)Entscheid eines Einzelnen kann wahrscheinlich keine unvorhergesehenen Ereignisse grossen Ausmasses bewirken, wenn er vom System quasi “unter den Teppich gekehrt” würde. Aber meistens wird das System ihn negativ verstärken, bis er sich als unerwartete Katastrophe bemerkbar macht. Das ist das, was ich eingangs als “ausbrüten” bezeichnet habe. In diesem Sinne sind manche Unternehmen oder Gesellschaften “schnelle Brüter”….

Betrachten wir das Diagramm etwas genauer und fragen uns, welche Systemarchetypen¹ darin enthalten sind, so können wir unschwer den Archetypus “Grenzen des Wachstums” identifizieren. Dieser Archetypus besteht aus einer verstärkenden und einer bremsenden Schleife. Verstärkende Schleifen habe wir gleich mehrere. Das sind die Schleifen mit Boni und Investitionen in die Entwicklung. Je mehr wir investieren, desto mehr wächst der Markt für unsere Produkte. Der bremsende Zyklus ist im Diagramm etwas versteckt. Der Markt hat eine Obergrenze. Je mehr der Gesamtmarkt ausgeschöpft ist, desto langsamer ist das Wachstum. Das Diagramm lässt sich vereinfacht auch so darstellen, wie in der folgenden Abbildung:

Ich habe den marktgenerierende oberen Teil des ursprünglichen Diagramms weggelassen, von den verstärkenden Schleifen stellvertretend nur eine übernommen und die bremsende Schleife auf der rechten Seite explizit gezeichnet. Aus der Theorie des Systemdenkens wissen wir, dass es ein sträflicher Fehler ist, die verstärkende Schleife anzutreiben. Das bedeutet, dass der Hebel überhaupt nicht darin zu suchen ist, mit Boni und Zusatzinvestitionen zu versuchen, indirekt die Nachfrage zu erhöhen.

Vielmehr liegt der Hebel beim Archetypen “Grenzen des Wachstums” darin, die bremsende Schleife abzuschwächen, oder die bremsende Bedingung zu beeinflussen. Ich habe im folgenden Diagramm versucht, die bremsende Bedingung abzuschwächen, also die Gesamtmarktgrösse zu erhöhen, indem ich zusätzliche Leads und Opportunities generiere. Das geht nur indem man das natürliche Wachstum der Anzahl Marktteilnehmer mit Hilfe geeigneter IT-Unterstützung ausnutzt.

In der Tat bieten in der Zwischenzeit ERP-Hersteller geeignete Werkzeuge an, so z.B: SAP, die sich speziell dem Design Win Markt angenommen hat:

Design Win allows technical sales reps, field application engineers, technical marketing and manufacturing share opportunities and collaboratively work to win sockets for next generation OEM products. Design win helps allows participants to assign activities and tasks, work on their assessment of probability and value, and discuss tactics and issues. Design Win allows provides all involved parties a 360-degree view into a design win sales opportunity by providing complete visibility into an opportunity’s history, milestones, progress. Analytics provide win/loss analysis and that can help win more designs in the future.²

Das ursprüngliche Vorgehen von Loch und Solt hat auf halbem Weg Halt gemacht. Den Markt und die Kunden als diejenigen Susysteme zu bezeichnen, die mit Unkunks (unvorhergesehene Ungewissheiten) aufwarten, ist trivial und hat keinen Erklärungswert. Gerade so gut hätte Elaine Bailey das Wetter als ein unkunk-geschwängertes Subsystem bezeichnen können. Ebenso falsch ist es zu vermuten, die Subsysteme des eigenen Unternehmens hätte man bis auf übliche Risiken im Griff.

Unser Vorgehen war wie folgt:

1. Zerlegen in Problemkreise, wie es Loch und Solt gemacht haben
2. Integrieren der einzelnen Problemkreise in ein Gesamtbild unter Zuhilfenahme eines Wirkungsdiagramms
3. Identifizieren der archetypischen Muster
4. Redesign des Wirkungsdiagramms, um die indetifizierten Archetypen herauszuarbeiten
5. Anwenden bekannter Lösungshilfen, die diesen Archetypen zugeordnet sind, als strategische Ideen

^*Titel aus Die Erleuchtungsreise

¹Peter M. Senge. Die fünfte Disziplin: Kunst und Praxis der lernenden Organisation. Schaeffer-Poeschel Verlag. Stuttgart 2011.
ISBN 978-3-7910299-6-2
oder
Peter Addor. Projektdynamik – Komplexität im Alltag. Frauenfeld 2010.
ISBN 978-3-9523545-6-8 oder
William Braun. The System Archetypes. 2002.
(oder: http://www.anchor.ch/archetypen.pdf)

²SAP: Design Win Business Scenario. (Zugriff 18. Februar 2012). Für das Design Win Geschäft werden fünf Business Processes vorgestellt:
Opportunity Processing with Channel Partners
Lead Processing with Channel Partners
Product Proposals
Collaborative Design Opportunity Management
Account Processing with Channel Partners

Betrachten wir das Diagramm einmal etwas näher! Der obere Teil des Diagramms beschreibt die externe Situation, nämlich den Markt für design win Lösungen.  Einerseits muss überhaupt verstanden werden, dass ein neuartiger Geschäftszweig existiert (“allgemeines Verständnis für das design win Geschäft”) und andererseits muss das Bedürfnis dafür aufgebaut werden (“Kommunikations- und Koordinationsbedarf”). Das sind aber gerade die beiden Problemkreise – “Customer Neeed” und “Industrial Readyness” – die Elaine Bailey als “High potential for unk unks” bezeichnet hat¹.

Inwieweit diese unkunks “zuschlagen”, hängt aber wenig von Escend ab, sondern geschieht per Selbstorganisation im Markt. Es ist die Frage, ob sich eine entsprechende Mode durchsetzen kann oder nicht. Escend kann das höchstens durch geeignete Marketingmassnahmen unterstützen.
Im unteren Teil gibt es ein paar Kreise, die die Nachfrage nach den Escend Lösungen verstärken und damit ihren Marktanteil. Die verstärkenden Massnahmen führen vor allem über die Motivation der Management- und Sales Teams einerseits und des Entwicklungsteams andererseits. Es sind dies diejenige Problemkreise, die Elaine Bailey als “Foreseeable” bezeichnet hat und meinte, dass von dort wenig Unvorhergesehenes zu erwarten ist.

Wie das Diagramm aber zeigt, wird Escends Erfolg sowohl vom (unsicheren) Umfeld, als auch von den (höchstens risikobehafteten) internen Entscheidungen geprägt. Beachten Sie, wie der Markt, der durch den oberen Teil des Diagramms beschrieben wird, das Unternehmen, das durch den unteren Teil des Diagramms dargestellt ist, in wahrstem Sinne des Wortes in die Zange nimmt: Ein Pfeil geht vom “Kommunikations- und Koordinationsbedarf” zu der “Nachfrage für das Escend Produkt”, während ein zweiter Pfeil vom “allgemeinen Verständis für das design win Geschäft” auf “Escends Verständnis der Kundenbedürfnisse” Einfluss nimmt.

Es wäre ein Trugschluss zu glauben, “foreseeable” Problemkreise im Griff zu haben und sich nur auf die “high potentials for unk unks” zu fokussieren. Die Hebel liegen eben nur intern, in den Problemkreisen, die man als “foreseeable” bezeichnet. Nur dort können wir wirklich Einfluss nehmen. Ob dann Boni und höhere Investitionen in die Entwicklung das Alleinseligmachende sind, wie im Diagramm vorgeschlagen, ist nicht die Frage. Vielleicht denken sich krative Manager geeignetere Bedienungen der Hebel aus (die hoffentlich ohne allzu schädliche Neben- und Fernwirkungen bleiben). Wichtig ist zu verstehen, dass man nur intern Hebel hat, die jedoch durch Markteinflüsse jederzeit überschrieben werden könnten.

Selbstverständlich beleuchtet das Diagramm nur einen Teil der Situation. Z.B. ist ein möglicher Einfluss von Escend auf die Marktsituation durch geeignete Marketingmassnahmen nicht abgebildet. Das Diagramm muss von der Geschäftsleitung kontinuierlich ausgebaut und ergänzt werden. Ich habe aber gerade gezeigt, wie bereits aus einem ersten rudimentären Wurf eines CLD eine ganze Menge über die Bewertung der Unternehmenssituation und der daraus resultierenden Strategie heraus gelesen werden kann.

^*frei nach einem geflügelten Wort von Andy Müller-Maguhn, Mitglied des Chaos Computer Club (CCC)

¹ Christoph H. Loch, Michael E. Solt und Elaine M. Bailey . Diagnosing Unforeseeable Uncertainty in a New Venture. Journal of Product Innovation Management, Volume 25, Issue 1, pages 28–46, January 2008

Ein sogenanntes “Causal Link Diagram” (CLD) kann den Zusammenhang wieder herstellen. Natürlich liegt es nicht am Diagramm, sondern an der Anstrengung, die einzelnen Sub-Systeme und ihre gegenseitige Abhängigkeit zu identifizieren und darüber nachzudenken. Dieser Akt ist das eigentlich Verbindende. Am Besten macht man das in einer Gruppe, z.B. mit dem gesamten Geschäftsleitungteam. Ein Moderator, der Erfahrung in Modellierung hat, kann die Gruppe motivieren und ihr allzu Technisches abnehmen.

Es ist nicht so einfach, ein solches Diagramm anzufertigen, auch wenn es auf den ersten Blick trivial erscheint. Allein dieses einfache CLD beanspruchte mich über zwei Stunden. Man muss den Blick für das Wesentliche haben, um das Diagramm nicht zu überladen. Man muss einige Grundmuster kennen, wie z.B. Verzögerungen, Aging Chains, Climbing Hill, Flowting Goals² oder die Senge Archetypen³. Stermans Buch hat fast 1000 Seiten, ist 4 cm dick und hat beinahe A4-Format. Wer modellieren will, muss seinen Inhalt vorzugsweise präsent halten….

Die Grössen “allgemeines Verständnis für das design win Geschäft” und “Marktanteil für das Escend Produkt” sogenannte Bestände. Sie nehmen zu, haben aber eine obere Schranke. Irgendeinmal kann das Verständnis nicht mehr weiter wachsen. Der Martanteil kann allenfalls den gesamten Markt einnehmen, aber nicht darüber hinaus wachsen. Solche Grössen können z.B. mit dem Senge Archetypus “Grenzen des Wachstums” modelliert werden.

Stellen Sie sich ein “stilles” Kapital vor, das zu einem bestimmten Satz verzinst wird. Der Zuwachs des Kapitals hängt also sowohl vom Zinssatz als auch vom aktuellen Betrag des Kapitals ab. Das sieht dann etwa so aus:

Alle Pfeile sind direkt proportional, d.h. Je grösser die Quelle, desto grösser das Ziel des Pfeils. Daher würde das Kapital ins Unendliche wachsen. Das kann aber nicht sein, denn das Geld auf dieser Erde ist beschränkt. Natürlich erreicht ein Kapital nie einen solchen Betrag, dass es alles Geld der Erde absaugen würde. Dafür müsste es mehere Tausend Jahre lange liegen bleiben, was nicht der Sinn des Geldes ist.

Aber für unsere Zwecke gehen wir nun mal davon aus, dass dieses Kapital nun tatsächlich beginnt, riesige Summen zu verschlingen. Dann würde die Bank Ihnen einen netten Brief schreiben und ankünden, dass sie den Zinssatz senken müssen. D.h. der Zinssatz hängt nun plötzlich vom Betrag des Kapitals ab und zwar umgekegrt proportional. Das lässt sich dann so darstellen:

Das “O” beim Pfeil vom Kapital zum Zinssatz besagt, dass der Zinssatz sinkt, wenn das Kapital zunimmt (auch wenn dies nur dann der Fall ist, wenn das Kapital einen riesigen Betrag erreicht hat). Durch den unteren Kreis Kapital –> Wachstum –> Kapital wächst das Kapital zunächst an. Später – die zwei parallelen Striche im Pfeil zum Zinssatz weisen auf eine verzögerte Wirkung hin – bremst der obere Kreis das weitere Wachstum aus, so dass ein sogennanntes “logistisches Wachstum” resultiert (s. z.B: Wikipeda)

Dasselbe geschieht mit dem Verständis und dem Marktanteil im ursprünglichen Diagramm. Natürlich ist ihr Wachstum in der Praxis nicht so glatt, wie es die Kurve in obiger Abbildung suggerieren will. Aber der Trend kann durch diese Kurve durchaus gemittelt werden.
Das war eine elementare Lektion in Modellierung (mit System Dynamics). Es mag eine Zeiterscheinung sein, dass gerade Entscheidungsträger glauben, sie hätten keine Zeit für etwas umfangreichere Methoden. Aber eine Methode, die etwas hergeben soll, hat nun mal einen gewissen Inhalt.

^* Titel aus Friedrich Schelling, Ideen zu einer Philosophie der Natur, In: Bubner, Rüdiger (Hrsg.): Geschichte der Philosophie, Deutscher Idealismus, Schelling
1 Christoph H. Loch hat mit Michael E. Solt und Elaine M. Bailey . Diagnosing Unforeseeable Uncertainty in a New Venture. Journal of Product Innovation Management, Volume 25, Issue 1, pages 28–46, January 2008
² Sterman, J. D. Business Dynamics – Systems Thinking and Modeling for a Complex World. McGraw-Hill, 2000
³ Addor, P. Dynamische Archetypen. anchor.ch, letzter Aufruf Januar 2012.

Nachdem der Kapitän erklärt hatte, dass er die Klippenverhältnisse um Giglio sehr genau kenne, kommt mir das Thema bekannt vor: Experten und Sicherheitsvorschriften. Es ist genau dasselbe, wie 1986 in Tschernobyl. Vielleicht kannten der Kapitän und seine Crew die Klippen um Giglio tatsächlich sehr genau, denn immerhin fuhren sie diese Route sehr häufig. Deshalb glaubten sie, dass die Sicherheitsvorschriften, eine gewisse Distanz zu der Küste zu halten, nur etwas für Kreuzfahrer-Anfänger sei, aber nicht für sie gelten.

Wichtig ist nun, die Dynamik zu verstehen: jedes Mal, wenn die Costa Concordia diese Stelle passiert hat, ging die Crew noch einen Zentimeter näher ran. Es wurde zur Routine und die Möglichkeit, dass man alles im Griff habe, wuchs zur Gewissheit. Der Bildschirm des Echolotes wird vielleicht kaum mehr konsultiert. Vielmehr macht sich eine Leichtigkeit breit, die die Kenntnis der Klippenverhältnisse bestätigt. So ging der Krug zum Brunnen, bis er schliesslich zerbrach.

Unfallforscher und Arbeitspsychologen versicherten schon vor Jahrzehnten, dass die Umgehung von Sicherheitsvorschriften Gang und Gäbe ist. Das wird in lerntheoretischem Sinne verstärkt, d.h. man schöpft aus der Missachtung von Sicherheitsvorschriften einen Vorteil. Dörner schreibt:

Wenn man Sicherheitsvorschriften verletzt, so wird gewöhnlich dadurch das Leben leichter. Die unmittelbare Folge der Verletzung der Sicherheitsvorschriften ist zunächst nur, dass man die Behinderungen durch die Sicherheitsvorschriften los ist und freier agieren kann. Sicherheitsvorschriften sind gewöhnlich so ausgelegt, dass man bei ihrer Verletzung keineswegs unmittelbar … zu Schaden kommt [oder ein Schiff auf Grund setzt], sondern so, dass das Leben leichter wird. Die aber kann sich geradezu als Falle erweisen²,

vor allem, wenn Expertenwissen im Spiel ist. Dieses Phänomen ist nur allzu menschlich. Wahrscheinlich ist es der Grund auch für viele unspektakuläre Kleinunfälle, z.B. im Strassenverkehr. Viele Autofahrer glauben, sie seien Experte.

Was kann man daraus lernen? Man muss sicherstellen, dass die Schiffe die Sicherheitsabstände einhalten. Wie kann man das sicherstellen? Sowohl die Betreiberin der Kreuzfahrten, als auch die Küstengemeinden haben ein Interesse, dass kein solches Unglück passiert. Die Betreiberin könnte auf den Schiffen einen Sicherheitsoffizier einsetzen, der nicht dem Kapitän unterstellt ist. Die Gemeinden könnten die Überwachung des Schiffverkehrs durch die Küstenwache verstärken und zu nahe an der Küste kreuzende Schiffe aktiv zur Einhaltung der Sicherheitsvorschriften auffordern. Solange jedoch niemand bereit ist, die Kosten für die Massnahmen zu bezahlen, muss weiterhin mit solchen Katastrophen gerechnet werden.

¹Der Titel ist ein Zitat von Andreas Tenzer
² Dietrich Dörner. Die Logik des Misslingens – Strategisches Denken in komplexen Situationen. Rowohlt Verlag. Reinbek bei Hamburg, 1992

Loch, Solt und Bailey stellen in ihrem Artikel eine Fallstudie der Unternehmung Escend Technologies vor. Escends Angebot ist eine Drehscheibendienstleistung in einem Markt, der komplexe elektronische Produkte vertreibt, die aus Teilen vieler Hersteller zusammen gesetzt sind. Dadurch entstehen eine unübersichtliche Anzahl von Rollen und Schnittstellen.

Die Investoren von Escend Technologies setzten Elaine Bailey ein. Sie sollte feststellen, ob sich weitere Investitionen in die Firma lohnen. Sie setzte die Diagnosemethode von Loch und Solt ein, die auf der Zerlegung in Sub-Systeme beruht. In der Tat handelt es sich eher um eine Liste der anstehenden Problemen, als eine reduktionistische Zerlegung in Sub-Systemen (S. 19). Jedes Problem wurde dann auf mögliche Ungewissheiten hin bewertet. Wie das geschehen ist, bleibt unklar. Es ist ziemlich trivial, dass Kunden- und Marktaspekte am meisten Ungewissheiten beinhalten. Teamaspekte wurden jedoch als reine Risiken bewertet, die vorhersehbar seien.

Der Zusammenhang der Sub-Systeme (klicken Sie zum Vergrössern auf das Diagramm)

Die Liste der anstehenden Probleme und “Baustellen” ist ein guter Anfang. Danach müssten sie jedoch eher in ein big picture integriert, als weiter in Details zerlegt werden. Ich habe versucht, mit den meisten der in der Liste von Loch, Solt und Bailey aufgeführten Probleme ein mögliches big picture zu entwerfen.

Das Diagramm ist eine mögliche Art, wie Einzelprobleme in ein Ganzes integriert werden können. Es erhebt nicht den Anspruch der Absolutheit. Es hat lediglich die Aufgabe, dem Entscheider zu helfen, die gegenseitige Abhängigkeit der Probleme wahrzunehmen. Wenn in einem Bereich ein Unkunk eintritt, dann hat das Auswirkungen auf alle anderen Bereiche. Man kann nicht davon ausgehen, dass der Problemkreis des Kundenverständnisses Unkunkpotential enthalte, die Dynamik des selbstgefälligen Managementteam jedoch vorhersehbar sei. Sogar wenn vom Managementteam keine Unkunk-Gefahr ausgeht, kann es durch eine (vorhersehbare) Ungeschicklichkeit einen Unkunk im Kundensystem auslösen.

Das Diagramm kann aber auch helfen, sogenannte Hebel zu identifizieren, die der Entscheider zur Verfügung hat. Doch davon in einem späteren Beitrag.

¹Titel von Brentano

²Christoph H. Loch, Michael E. Solt und Elaine M. Bailey . Diagnosing Unforeseeable Uncertainty in a New Venture. Journal of Product Innovation Management, Volume 25, Issue 1, pages 28–46, January 2008