Schlagwort-Archive: Theory of Constraints

Was verstehen Sie unter Verschwendung?

Karl Heinz Däppler fragt, welche Rolle bei der projektübergreifenden Lessons Learned Wissenskultur die Thematik „Lean Managment“ spiele. Komplexitätsmanagement fordert ein Management, das der (in den letzten Jahren in schwindelerregende Höhe gewachsenen) Komplexität angepasst ist und sich Strategien bedient, die es erlauben, die Entropie eines komplexen Systems in die Umgebung auszulagern. Die Entropie ist das Mass für die Unsicherheit, die komplexen Systemen inhärent ist. Projektübergreifendes Lessons Learned Wissensmanagement ist eine solche Strategie. Wenn Lean Management ebenfalls zum Entropieexport beitragen kann, dann könnte es eine wichtige Rolle spielen.

Der Begriff „Lean“ könnte jedoch falsch verstanden werden. Ich habe hier immer wieder darauf hingewiesen, dass die Aufrechterhaltung der von uns geschaffenen Komplexität etwas kostet. Leider habe ich in keinem Budget je den Posten „Komplexitätskosten“ gesehen. Ich denke daher, dass dieser Posten bei Lean Management erst recht unter den Tisch fällt. Da sich „Lean“ die Vermeidung von Verschwendung auf die Fahne geschrieben hat, befürchte ich, dass dabei lokal optimiert wird. Wir haben aber sowohl beim Bierspiel als auch in der Theory of Constraints gesehen, dass lokales Optimieren dem System als Ganzens schadet. Am einfachsten ist das an einer Produktionslinie von z.B. drei Fertigungseinheiten zu verstehen. Um ein Erzeugnis herzustellen, benötige die erste fünf, die zweite 11 und die dritte sieben Zeiteinheiten. Die Produktionslinie stellt also alle 11 Zeiteinheiten ein Stück her, das verkauft werden kann. Es hat keinen Sinn, wenn die erste Fertigungseinheit mehr als ein Stück pro 11 Minuten herstellt, denn das würde zu teuren Beständen zwischen der ersten und der zweiten Fertigungseinheit führen. Wenn nun ein Lean Management Berater findet, es sei Verschwendung, wenn die erste Fertigungseinheit nur zu 5/11 oder 45% ausgelastet sei, dann ist Lean sicher nicht der richtige Weg. Wenn jedoch Lean Management bedeutet, dass die erste Fertigungseinheit genau ein Halbfabrikat bereit stellen soll, wenn die zweite Einheit bereit ist, eines zu verarbeiten, weil jede weitere Aktivität der ersten Einheit Verschwendung wäre, dann kann Lean Management ein interessanter Ansatz sein.

Der Begriff „Verschwendung“ ist eben nicht eindeutig, und ich habe in den Artikeln über Lean Management eben sowenig eine exakte Definition gefunden, wie eine dezidierte Distanzierung von jeglichem lokalem Optimieren. Solange ich keinen derartigen Hinweis finde, muss ich jedoch befürchten, dass unter „lean“ nichts anderes als „lokales Optimieren“ gemeint ist.

Wenn Projektmanagement wie Feuer ist, ist Sparen wie Wasser

Ein häufiger Grund für das Scheitern von Projekten sind mangelhafte Projektleistungen. Sie kommen nicht von ungefähr. Getreu nach dem Motto „Geiz ist geil“ verlangt der Kunde alles, will aber nichts dafür bezahlen. In einem Projekt mit einem Volumen von ca. 15 Mio Franken boten wir auch die Projektleitung für 1 Mio Franken an. Der Kunde war nicht bereit, etwas für die Projektleitung zu bezahlen mit dem Hinweis, er habe selber Projektleiter. So ein Blödsinn! Man sollte Projekte nicht mit Einkäufern verhandeln, die wenig von Projektmanagement und nichts von Komplexität verstehen. Wenn schon, dann sollten die Parteien überein kommen, dass beide – sowohl der Lieferant als auch der Kunde – auf die Projektleitung verzichten, dafür gemeinsam einen externen Projektleiter engagieren, der vor allem unabhängig sein sollte und auch Schiedsgerichtsfunktionen übernimmt. Das würde nämlich auch der Tatsache entgegen kommen, dass nur eine externe Drittpartei fähig ist, ein Gefangenendilemma zu lösen, und solche gibt es viele in Projekten.
Wenn der Kunde nichts bezahlen will, muss der Lieferant versuchen, margenerhaltende Massnahmen zu treffen, indem er überall Kosten spart. Vielleicht bedeutet das, dass er nachträglichen Kundenanforderungen wenig flexibel entgegen kommt oder gewisse Leistungen nur lückenhaft erbringt, in der Hoffnung, der Kunde merke es nicht. Diese Handlungsweise findet man nicht nur im Projekt- sondern auch im übrigen Management. Vor allem die Dienstleistungsbranche ist wahrer Meister im Abbau von Services. Man denke etwa an die Eisenbahnen, die als Staatsbahnen sogar noch eine Monopolstellung haben und locker machen können, was sie wollen. So passiert es mir laufend, dass ich ein Ticket für eine Direktfahrt von A nach B kaufe, die z.B. drei Stunden dauern soll. Die Dienstleistungsbeschreibung ist damit klar. Aus technischen Gründen wird die Strecke unterbrochen, und ich muss umsteigen. Wenn das einmal passiert, kräht kein Hahn danach. Aber das ist eine permanente Situation. Der Zug fährt nie direkt von A nach B, obwohl das so verkauft wird. Auch damit könnte ich mich abfinden. Wenn die Bahn jedoch die Strecke aus technischen Gründen unterbrechen muss, dann sollte man meinen, am Umsteigeort würde zumindest eine Zugskomposition bereit stehen, um die Fahrgäste aufzunehmen, und zwar mit denselben Sitznummern, damit die Reservierungen erhalten bleiben. Die Schweizerische Staatsbahn hält diese minimale Leistungserbringung nicht für nötig. Sie missbraucht einfach eine andere Zugslinie als Anschlusszug. Meistens klappt der Anschluss aber nicht und der Anschlusszug ist bereits abgefahren, wenn man am Umsteigebahnhof ankommt. Man hat dann mindestens eine Stunde auf die Weiterfahrt zu warten. Der Anschlusszug ist bereits mit Passagieren gefüllt und soll noch diejenigen aufnehmen, die von A kommen. Reservierungen werden völlig ignoriert. Ich bin nicht Jurist, aber mein Gerechtigkeitssinn lässt mich zu der Überzeugung kommen, dass dieses Vorgehen rechtlich bestimmt nicht haltbar ist.

Das ist nur ein Beispiel, wie der Lieferant auf Kosten der Endkunden spart. Die Theory of Constraints sagt, dass Engpässe voll ausgenutzt werden müssen und alles andere dieser Ausnutzungsstrategie anzupassen ist. Jedes System hat seinen Engpass. Das kann eine Maschine, ein Prozess oder eine Ressource sein. Für eine Staatsbahn ist der Markt der Engpass, denn wenn kein Kunde da ist, der einen Transport nachfragt, kann die SBB noch so viel produzieren, verkaufen kann sie es nicht. Uwe Techt schreibt:

Wenn das System nun nicht in der Lage ist, die Kunden, die etwas kaufen wollen, zu bedienen, dann ist das gerade das Gegenteil von „den Engpass bestmöglich nutzen“. Der Engpass wird verschwendet! Nur allzu oft kommt es vor, dass nämlich genau das Produkt in der Ausprägung, in der ein Kunde es haben möchte, nicht verfügbar ist. Wenn wir den Engpass bestmöglich nutzen wollen, dann heißt das automatisch, dass wir immer alles verfügbar haben müssen, was der Kunde zu kaufen wünscht.1

Das haben die meisten Manager immer noch nicht begriffen. Sie mögen sparen, so viel sie wollen, haben aber damit keine einzige Einheit ihres Angebots verkauft. Nur der Verkauf bringt Geld! Sie müssen den Verkauf fördern, nicht ihn durch Sparen eindämmen. Das gilt auch in Projekten: Alle versuchen zu sparen, was konfliktträchtig ist und viele Projekte in die Bedrouille führt. Das Gegenteil wäre für gesunde Projekte richtig. In Projekten werden neue Systeme gebaut. Projekte sind somit schöpferische Aufbauphasen. Das bestätigt vor allem die Natur. Erich Jantsch hat das so formuliert:

Für den schöpferischen Aufbau einer neuen Struktur werden keine Kosten gescheut – und mit Recht… Nur ein auf Sicherheit ausgehendes etabliertes System muss haushalten.2

Sparen heisst, das Bestehende bestätigen, also nichts Neues zulassen wollen. Sparen passt nicht ins Projektmanagement.

1Uwe Techt: Goldratt und die Theory of Constraints. Der Quantensprung im Management. Selbstverlag, 2006.
www.lulu.com
2Erich Jantsch. Die Selbstorganisation des Universums. Vom Urknall zum menschlichen Geist. dtv wissenschaft, Nr. 4397, München 1982

Wir können Ungewissheit nicht einschätzen, Mr. Goldratt!

Goldratts Theory of Constraints ist durchaus faszinierend und vielversprechend. Aber sie ist halt eben eine regelbasierende Theorie, während es mein Credo ist, dass die heutige Komplexität wissensbasiertes Vorgehen erfordert (siehe Reasons Handlungs- und Denkmodell). Regelbasiertes Vorgehen genügt nicht mehr, um die Stabilität derart komplexer Systemen sicherzustellen, wie wir sie bis zum heutigen Tag in Gesellschaft, Wirtschaft und Politik geschaffen haben. Bei Goldratt ist alles sehr einfach und glatt. Zwar treffen seine Protagonisten zuweilen auch Widerwärtigkeiten an, aber nur, bis sie zu den Einsichten Goldratts gelangen. Dann geht alles wie durch Butter, sie erreichen die in sie gesteckten Ziele und werden auf den erträumten Posten befördert. Die Bücher hinterlassen keine offenen Fragen. Genau das ist es aber, was mir Unbehagen bereitet. Die Welt präsentiert sich uns ausschliesslich in Form offener Fragen. In einer neue Situations gibt es zu wenig Regeln. Wir müssen uns jedes Mal erneut auf die wissensbasierte Ebene begeben und die Situaion analysieren. Das ist zwar mühsam und aufwändig, stellt aber die einzige Möglichkeit dar, um die Komplexität zu bewältigen. Wenn immer Sie eine komplexe Situation ausschliesslich über Regeln lösen wollen, destabilisieren Sie das System noch mehr als vorher. Daher werden die wirtschaftlichen Instabilitäten, die wir seit 1929 in immer kürzeren Perioden durchleben, immer heftiger bis zum Kollaps.
Seine Kritische Kette1 beginnt Goldratt mit der Skizze einer Wahrscheinlichkeitsverteilung für die Durchführungsdauer eines Tasks. Der Tasks braucht meistens z.B. 5 Tage. Auch im günstigsten Fall wird man z.B. nicht vor 3 Tagen fertig. Goldratt zeichnet folgende Skizze:

Er behauptet dann, dass die meisten Projektplaner soviele Tage für den Task einstellen, dass sie mit 80-prozentiger Sicherheit fertig werden. In unserem Bild wären das also gute 17 Tage. Stattdessen sollte man für alle Tasks eines Projekts nur diejenige Zeit einplanen, in der man mit 50-prozentige Sicherheit ans Ziel kommt und dafür am Schluss des Projekts einen grosszügigen Puffer einräumen, den man ständig überwacht. Goldratt sagt, dass wir einen Task nicht innerhalb der 50%-Marke terminieren können, wenn etwas Unvorhergesehenes passiert. Dafür ist dann der Puffer da. Aber auf dem Gebiet der Migrations- und Integrationsprojekten kenne ich niemand, der alle siene Tasks mit einer hohen Sicherheit einplant. Ich meinte, alle Projektleiter, die ich kenne, haben die realen Zeiten genommen und am Schluss einen Sicherheitszuschlag von 10-20% eingerechnet (der ihnen vom Sales natürlich wieder abgezogen wurde). Aber was sind „reale Zeiten“? Woher sollen wir diese Zeiten kennen? Ein Projekt ist per Definition ein erst- und einmaliges Unterfangen. Also ist es gar nicht möglich, Erfahrungswerte zu haben – zumindest nicht immer. Und woher kennen wir die Wahrscheinlichkeitsverteilung eines Tasks? Sie könnte nämlich auch so aussehen:

Zwar kommen 5 Tage in der Tat am meisten vor, aber die Wahrscheinlichkeit, dass der Task erst nach 10 Tage fertig gestellt wird, ist unwesentlich kleiner, als diejenige für 5 Tage. Natürlich ist eine solche Verteilung ein Extremfall, aber sie kann durchaus vorkommen.
Meines Erachtens den interessantesten Satz in seinem Buch Die Kritische Kette liefert Goldratt fast am Schluss (S. 226): Was ist ein vernünftiger Massstab für die Ungewissheit eines Projekts? – Der Projektpuffer. Verstehen Sie, was das heisst? Den Projektpuffer haben wir ja aufgrund unserer Einschätzung dimensioniert. Und jetzt soll er also ein Mass für die Ungewissheit sein, die wir per Definition nicht einschätzen können, sonst wäre es keine Ungewissheit mehr. Da scheint sich irgendwer irgendwo zu beissen.
Bis jetzt kenne ich nur folgenden Projektverlauf: Projekt mit knappen Fertigstellungsterminen geplant – es taucht etwas Unvorhergesehenes auf – man aktiviert die wissenbasierte Ebene und analysiert die Situation – man konstruiert situationsgemässe Lösungen, wenn man kann – man überwindet die Hürde und setzt das Projekt fort, meist nicht mehr plangemäss, aber für die Neuerstellung eines Plans hat man keine Zeit mehr, so dass spätestens nach Auftreten einiger unvorhergesehener Ereignissen das Projekt nur noch „intuitiv“ vorangetrieben wird.
1Eliyahu Goldratt. Die Kritische Kette – Das neue Konzept im Projektmanagement. Campus Verlag. Frankfurt a.M. 2002

Das Alte war gut. Die Entwickler des Neuen haben keine Ahnung!

In seinem Buch Die Kritische Kette sinniert Eliyahu Goldratt auf der Basis der Theory of Constraints über die Wahrscheinlichkeit nach, mit der ein Task, eine Phase oder ein ganzes Projekt nach einer bestimmten Zeit terminiert wird1. Er macht dabei den Vergleich zu dem Nachhauseweg nach der Arbeit. Unter 20 Minuten können Sie nicht zu hause sein. Meist sind es 30 Minuten. Wenn viel Verkehr ist, dann benötigen Sie sogar 40 Minuten. Und wenn Sie noch einen Kollegen treffen und mit ihm ein Bier trinken, sind Sie nicht vor 120 Minuten zu hause. Goldratt fragt dann, mit welcher Terminierungswahrscheinlichkeit wir planen sollen. Meines Erachtens ist das in Migrations- und Integrationsprojekten (MIP) die falsche Frage. Ganz abgesehen davon, dass Sie die Terminierungswahrscheinlichkeiten für einzelne Tasks und Phasen in MIP gar nicht kennen, werden typische MIP-Tasks nie fertig. Das kommt daher, dass z.B. bei einer Migration ein bestehendes System abgelöst werden soll und das neue System den Kunden vorerst niemals zufrieden stellen kann, weil es doch etwas anderes ist, als das ihm vertraute alte System. Stets vergleicht er das neue System mit dem abzulösenden, dem er tief in seinem Herzen eine Träne nachweint. Zudem kennt er das neue System noch nicht so gut und muss die Bedienung vieler Funktionen zuerst kennen lernen. Wer von uns kennt das nicht? Bis man mit einem Gerät wirklich vertraut ist und seine Stärken und Macken kennt, muss man es viele Male bedient haben, um nicht zu sagen, man müsse es in sein Leben integriert haben. Unsere Fernseher, Waschmaschinen, Autos, PCs oder Musikanlagen sind doch ein Teil unseres Lebens geworden. Wenn wir ein solches Teil jemals ersetzen müssen, finden wir eine Menge von Mängel am neuen Teil. Aber nach paar Wochen ist auch das neue Gerät ein Teil unseres Lebens geworden, und wir wissen schon gar nicht mehr, wie das alte bedient werden musste. Das Projekt „neues Gerät anschaffen und in Betrieb nehmen“ ist beendet, wenn das neue Gerät angeschlossen und betriebsbereit ist. Genau in dieser Phase haben wir allerlei zu bemängeln und herum zu nörgeln. Ich nenne das das Umgewöhnungssyndrom. Leider können wir als kleine Endkunden dem Lieferanten das Gerät nicht um die Ohren schlagen. Wenn aber z.B. eine Bank von einem Systemhaus eine neue Bankenlösung kauft und für die Migration Dutzende, wenn nicht Hunderte von Millionen bezahlt, dann kann sie den Lieferanten solange festnageln, bis sie sich endlich an das neue System gewöhnt hat. Das verzögert das Projekt ungemein.

Sehr schön studieren kann man den eben beschriebenen Effekt bei Acceptance Tests, die ein wichtiger Teil von jedem MIP sind. Dazu wird ein Testdrehbuch benötig, das die durchzuführenden Tests enthält zusammen mit Angaben über Durchführungsdauer, Start- und Endzeitpunkt, Testverantwortliche, zu erwartende Resultate, etc. Sollen z.B. 100 Tests durchgeführt werden die je 15 Minuten dauern, dann wird die Projektplanung 25 Stunden vorsehen. Erfahrungsgemäss sieht die Planung und die dazugehörende Fortschrittskurve so aus:

 

Eine solche Planung passt eher in ein Straflager. Auch noch so arbeitsame Mitarbeiter gehen mal einen Kaffee holen oder müssen die Toilette besuchen. Ab und zu muss das Testdrehbuch diskutiert oder ein Bedienungsmanual konsultiert werden. Zudem kommen Telefone und die Mails müssen gecheckt werden. Die effektive Produktivität einer Ressource beträgt normalerweise zwischen 70 und 80 Prozent.
In den letzten paar Jahren habe ich die effektiven Testfortschritte aus mehreren Projekten ausgewertet und stets folgendes gefunden:

 

Am Anfang wird ein Initialaufwand dazu führen, dass die Ausführung der Tests der Planung etwas hinten her hinkt, weil der Projektleiter die Rüstzeiten vergessen hat. Diese sind aber schnell eingeholt, und weil alles so gut geht überholen die aktuellen Tests die Planung sogar. Das kommt daher, dass man zuerst die einfachen und unproblematischen Tests durchführt. Der Projektleiter muss bei jeder Steeringboard-Sitzung den Projektfortschritt vorweisen. Er wird quasi am Fortschritt gemessen. Daher wird er solange unproblematische Tasks oder Pfade bearbeiten, wie er kann. Goldratt schreibt: Weil ein Fortschritt auf einem Pfad eine Verzögerung auf einem anderen Pfad kompensiert. Also scheint ein rascher Fortschritt auf einem beliebigen [auch nicht-kritischen] Pfad angebracht2. Das schafft Vertrauen. Doch dann beginnt es zu harzen. Einige Tests müssen wiederholt werden. Schwererwiegende Probleme müssen sogar mit der Entwicklung besprochen werden. Es gibt Fälle, in denen das Verhalten des Systems zunächst unerklärlich ist und analysiert werden muss. Das kostet viel Zeit, die nie mehr eingeholt werden kann. Und schliesslich wird der Kunde genau in diesem Zeitpunkt, in welchem die Fortschrittskurve abflacht, vom Umgewöhnungssyndrom erfasst. Das neue System passt ihm (noch) nicht so recht, weil er es noch nicht kennt. Er möchte, dass es wie das alte funktioniert und wird viele Einwände, Wünsche oder zumindest Fragen haben. Er wird verlangen, dass Testfälle ein wenig verändert und wiederholt werden. Das Problem ist also weniger die Terminierungswahrscheinlichkeit, die die Theory of Constraints untersucht, noch der Rework Cycle, wie er von System Dynamics vorausgesagt wird. Das Problem in Migrations- und Integrationsprojekten ist das Umgewöhnungssyndrom. Daher werden die Acceptance Tests nie fertig. Man muss sie irgend einmal einfach „gewaltsam“ als abgeschlossen erklären. Ganz ähnlich verhält es sich mit ganzen Migrations- und Integrationsprojekten. Auch diese werden nie so richtig fertig.

1Eliyahu Goldratt. Die Kritische Kette – Das neue Konzept im Projektmanagement. Campus Verlag. Frankfurt a.M. 2002.
2 ebenda, S. 80.