Open Loops

Unter dem Titel “Marchionne verordnet Chrysler sein Patentrezept” veröffentlichte die FAZ am 17. Juni einen Artikel, der auch für Turnaround Manager interessant ist. Welche Muster wendet der berühmte Sanierer bei einer Übernahme an, welche Vorgehensweisen haben sich schon bei Fiat, der Traktorensparte CNH und der Nutzfahrzeuggesellschaft Iveco bewährt?

Systemische Ähnlichkeiten lassen sich bei Projekten in der Krise, Unternehmen in der Krise oder bei Übernahmen sicherlich dann verwerten, wenn die Machtfülle eines Marchionne vorhanden ist. Denn es fängt blutig an: Bereits nach zwei Tagen hat der neue Chef 17 der 23 Führungspositionen neu besetzt. Zugleich vermeidet er aber den Eindruck einer Kolonialisierung, indem er mit lediglich 3 Topleuten (Finanzen, Kommunikation, Vertrieb) im Gepäck nach Amerika kommt. Von Anfang an versucht Marchionne eine zu große Belastung von Chrysler und Fiat durch Reisen und Abstimmungen zu vermeiden. Anders als bei Daimler sind Videokonferenzen zur Abstimmung das Mittel der Wahl.

Exportiert hat Marchionne besonders seine Organisationsstruktur, eine Matrixorganisation mit Spartenverantwortlichen. Denn in der steilen Hierarchie haben sich durch das Abschotten in Silos Wohlfühlpositionen aufgebaut. Mit der Matrix baut Marchionne eine gegensätzliche Zielposition auf, die zu Konflikten führt. Das Bearbeiten dieser Konflikte als Moderator ermöglicht ihm, das Unternehmen schrittweise in die gewünschte Zielrichtung zu bringen. Dabei zählt vor allem eins für die neue Führungsmannschaft: Tempo! Durch das Stecken konkreter und enger zeitlicher Ziele bewirkt Marchionne eine Fokussierung der Kräfte des Unternehmens.

Zusammengefasst lassen sich folgende Muster des Vorgehens festhalten:

• Führungspositionen neu besetzt
• keine Kolonisalisierung, sondern Autonomie des übernommenen Systems
• Kontrolle von Finanzen, Vertrieb, Kommunikation
• Wenig Reisen, Kommunikation über Videokonferenzen
• Matrixorganisation zum Aufdecken von Konflikten, die dann bearbeitet werden können
• Bearbeiten der Konflikte als Moderator
• Enge zeitliche Ziele bewirken Fokussierung der Kräfte

Mir hilft diese Sammlung als Checkliste von Möglichkeiten beim nächsten Turnaround mit Abwandlungen und Ergänzungen bestimmt.

Was hat Münchhausen mit Management zu tun? Sehr viel, folgt man dem Artikel der Kieler Nachrichten vom 18. Juni mit dem Titel: “Dein Freund, der innere Schweinehund. Marco Freiherr von Münchhausen verdeutlichte Wege zur effektiven Selbstmotivation”. Hürden mit einem großem Team zu überwinden, ist Management; sich immer wieder selbst zu motivieren und auch unbequeme Dinge zu tun, ist Selbstmanagement. Bei Letzterem helfen Tipps, die der “Trainer des Jahres 2002″ mit dem berühmten Namen zusammengestellt hat. Nachfolgend einige Hinweise des Freiherrn von Münchhausen, die ich aus eigener Erfahrung heraus nur bestätigen kann und bei meinem eigenen Selbstmanagement bereits nutze:

• Um uns zu überwinden, brauchen wir das Gefühl der Machbarkeit.
• Man sollte sich immer nur genau eine Sache zur Zeit vornehmen und diese dann so früh wie möglich am Tag erledigen.
• Den Anfang einer schwierigen Aktion sollte man sich so leicht wie möglich machen.
• Bei der Verwirklichung guter Vorsätze sollte man sich keinerlei Ausnahmen gönnen.
• Die Erledigung schwieriger Aufgaben fällt leichter, wenn man sich vor dem Loslegen “einen inneren Film mit gutem Zielfoto” macht.
• Man braucht eine klare Vorstellung von dem, was man umsetzen will.
• Man darf sich nicht überfordern, sondern sollte das rechte Maß zwischen Überforderung und Unterforderung finden.
• Die Überwindung innerer Widerstände ist eine Sache des Bauches.
• Man sollte den inneren Schweinehund als Teil von sich annehmen, man sollte ihm Grenzen setzen, ihn aber überleben lassen. Denn der innere Schweinehund ist nicht zuletzt der Wächter unseres Wohlbefindens.

Ich hoffe, diese Aufstellung hilft Ihnen so wie mir in meinem Managementalltag. Welche Grenzen wollen Sie Ihrem “inneren Schweinehund” setzen?

„Wenn wir wüssten, was wir alles wissen!“ Gelingendes Wissensmanagement ist ein zunehmend wichtiger Baustein für den Erfolg von Unternehmen. Um vorhandenes und neues Wissen zu sammeln, im Unternehmen zugänglich zu machen und systematisch zu verteilen, gibt es eine ganze Reihe von Methoden: Knowledge-maps, Checklisten, FAQs, Planspiele, Kreativitätstechniken, Mentorensysteme, Manöverkritik, Lessons Learned usw.

Im Projektmanagement werden häufig Projektberichte dazu genutzt, die „gelernten Lektionen“ an Andere weiterzugeben. Das ist eine an sich gute Idee – wäre da nicht das Problem, dass diese Berichte von den KollegInnen häufig ignoriert werden. Das Wissen aus den Projekten bleibt somit in Schubladen oder Datenbanken verschüttet. Die Frage ist also: Wie muss dieses Wissen aufbereitet werden, damit andere MitarbeiterInnen es annehmen und in ihren Projekten nutzbar machen? Die Antwort lautet: Machen Sie Geschichten daraus! Mitreißende, amüsante, spannende – vor allem: anschauliche – Geschichten motivieren zum Lesen und zu einer Auseinandersetzung mit den Inhalten. Und sie führen dazu, dass das Wissen haften bleibt, denn lebendige Bilder prägen sich besser ein als bürokratischer Text.

Dass die Verbindung von Story Telling und Lessons learned funktioniert, zeigt eine Studie von Shad Morris (Ohio State University) und James B. Oldroyd (SKK Graduate School of Business, Seoul), deren Ergebnisse in der aktuellen Juni-Ausgabe des Harvard Business Manager vorgestellt werden. Sie untersuchten die Einführung des Programms „Smart Lessons“ bei der International Finance Corporation (IFC) der Weltbank und fanden heraus, dass dieses den Wissensstand der IFC-MitarbeiterInnen „dramatisch verbesserte“. Die ProjektmanagerInnen wurden angehalten, ihre Erfahrungen in menschliche Geschichten zu verpacken, mit denen die Anderen direkt etwas verbinden konnten, und diese dann online zu stellen. Die Autoren stellten sich dabei mit einem Foto, einer Kurzvita und ihren Interessensgebieten vor. Das Programm war so erfolgreich, dass die Smart Lessons mittlerweile zu einem festen Bestandteil des Projektmanagements am IFC geworden sind. Tolle Sache!

Sicherlich kennt sie jeder von Ihnen. Auch mir begegnen sie immer wieder, wenn ich ein neues Projekt oder ein Interimsmanagement beginne: Flaschenhälse. Flaschenhälse können Maschinen oder Datenbanken sein, die in einem Web-System nicht ausreichend Traffic zulassen und die Anzahl der möglichen User eines Systems und der bearbeitbaren Requests begrenzen.

Auch Einzelpersonen oder Teams können Flaschenhälse sein. Architekten, die verspätet Architekturschablonen vorlegen, können das ganze restliche Team bremsen. Ein Zulieferer, der seine Komponenten verspätet bereitstellt, sorgt dafür, dass ein ganzes Projekt verzögert wird. Und nicht zuletzt können Manager wie ich Flaschenhälse sein, wenn sie notwendige Entscheidungen verspätet treffen.

Nun kann man sich über offensichtliche Flaschenhälse in Systemen beklagen und die Tatsache, dass es sie gibt, als unabänderlich hinnehmen.

Doch wie ist es mit der Idee, die Kenntnis von Flaschenhälsen produktiv zu nutzen? Hier hilft eine allgemeine Managementmethodik weiter, die auf Goldratt zurückgeht und “Theory of Contsraints” heißt. Goldratt hat in ihr u.a. einen kontinuierlichen Verbesserungsprozess zur Optimierung von Systemen (Produktionsanlagen, Hard-und Softwaresysteme aber auch Beziehungsgeflechte von Menschen wie Projekte) vorgeschlagen. Seine Ideen greifen weiter, aber allein der folgende fünfstufige Prozess hat mir geholfen, Flaschenhälse nicht mehr als Ärgernis, sondern als Chance zu begreifen.

1. Identifiziere den Flaschenhals im System; die ganze Kette ist nur so stark wie ihr schwächstes Glied. Ich stelle mir zu Beginn eines Projektes, insbesondere bei Turnarounds die Frage: Wo ist der wichtigste beschränkende Faktor, der einen optimalen Output verhindert?

2. Nutze das schwächste Glied, den Flaschenhals optimal. So kann man z.B. einem Architekten einen Technical Writer oder einem Manager einen Assistenten zur Verfügung stellen, um seine Kernkompetenz verstärkt ausnutzen zu können.

3. Passe die Arbeitsrate des Gesamtsystems dem Flaschenhals an. So können zum Beispiel Prioritätsverschiebungen im Gesamtsystem verhindern, dass sich vor dem Flaschenhals unnötig Arbeit und Unerledigtes anhäuft, denn das ist ohnehin Blindleistung, die nicht verarbeitet werden kann.

4. Erweitere die Kapazität des Flaschenhalses. Beispiele sind das Hinzustellen weiterer Hardware oder das Einstellen zusätzlicher Manager, die notwendige Entscheidungen treffen können.

5. Beginne wieder bei 1. Wenn der bisherige Flaschenhals behoben wurde, so begrenzt der nächste Engpass das System und sollte behoben werden.

Und wann gehen Sie auf die Suche nach den Flaschenhälsen in Ihrem Arbeitsumfeld? Haben Sie schon Ideen für die Schritte 2-4?

William Edwards Deming (1900-1993) war ein US-amerikanischer Statistiker und Wirtschaftsexperte mit großem Einfluss auf das Qualitätsmanagement und die Entwicklung der Wirtschaft in Japan und der ganzen Welt. General Mac Arthur holte ihn nach dem zweiten Weltkrieg in das industriell zerstörte Japan als Berater für die japanischen Topmanager. Demings Wirken blieb in den USA und Europa zunächst unbeachtet, diente in der japanischen Wirtschaft jedoch als zentrale Inspiration für die japanische Managementlehre. So beeinflusste sein Denken die Entstehung des Toyota Production System und der Lean Management Bewegung. In dieser Tradition steht auch Scrum, die agile Methodik Softwaresysteme zu erstellen.

Ein wesentlicher Baustein seiner Lehre ist der Deming-Cycle oder auch (P)lan-(D)o-C(heck)-(A)ct-Cycle, der auf die Ideen seines Lehrers Shewhart zurückgeht. Nach dieser Idee muss jeder Prozess geplant(P), durchgeführt (D), geprüft (C) und auf der Basis der gewonnenen Erkenntnisse verbessert (A) werden. Das ständige Wiederholen dieser Phasen des Kreislaufs führt zu einer kontinuierlichen Verbesserung des Prozesses; ich nenne den PDCA-Zyklus deshalb gerne auch Lernkreislauf.

Boris Gloger (Boris Gloger: Scrum, Hanser 2008, S.48) verwendet als anschauliches Beispiel für dieses Lernen das Vorgehen bei einem Computerspiel. Seinem Beispiel folgend hier die Grundidee verkürzt dargestellt: Man legt sich eine Taktik zurecht, wie man das nächste Level erreichen möchte (P). Die Computerfigur rennt los, wird aber von einem Monster überrascht und verliert (D). Man prüft das Ergebnis (C) und passt seine Taktik an (A). Man versucht es erneut, immer wieder, bis man alle Tricks des Levels gelernt hat und die nächste Stufe erreicht.

Schaut man sich den Ablauf in Scrum genauer an, so wird deutlich, dass die wesentliche Komponente genau der PDCA-Zyklus ist, er wird sogar verschachtelt zweifach angewendet:

Für einen Scrum Sprint gilt nämlich:

• P: das Sprint Planning Meeting
• D: Implementierung der vom Team gewählten Product Backlog Items zu einem lauffähigen System
• C: im Sprint Review Meeting wird überprüft, ob die Ziele erreicht wurden. Das lauffähige System wird geprüft.
• A: In der Sprint Retrospektive werden die Verbesserungsmöglichkeiten für den nächsten Sprint und das weitere Vorgehen im Projekt identifiziert

Für einen Tag im Sprint gilt:

• P: Im Daily Scrum wird von jedem Team-Member gesagt, was es an diesem Tag machen möchte
• D: Am Tag werden die angesprochenen Tasks durchgeführt
• C: Im Daily Scrum werden die Fragen beantwortet: Was habe ich gemacht? Welche Hindernisse (Impediments) sind aufgetreten
• A: Der Scrum Master ist dafür verantwortlich, die Hindernisse zu beseitigen. Die Team-Mitglieder passen ihr Verhalten aufgrund der im Daily Scrum diskutierten Themen Tag für Tag an.

Für mich macht diese konsequente Anwendung des PDCA-Cycles den Erfolg von Scrum aus. In komplexen Umgebungen wie einem Computerspiel - oder noch komplexeren wie einem Projekt - ist das Lernen des besten Weges einfach notwendig.