Nicht jedes Warten ist Zeitverschwendung

Letzte Woche habe ich einen Artikel veröffentlicht, der auf einer Behauptung beruhte (Hier auf Deutsch lesen). Die Kapazität ist im Budget berücksichtigt, die Wartezeit hingegen nicht. Deshalb birgt die Wartezeit ein enormes Potenzial zur Beschleunigung der Entwicklung: Sie ist weitgehend unsichtbar, stellt aber eine große Quelle von Ineffizienz dar.

Innerhalb einer Stunde hat ein Leser die Behauptung auseinandergenommen. Er hatte Recht, und die Behauptung bleibt trotzdem bestehen – allerdings nicht in der Form, wie ich sie formuliert habe. Welche Hälfte nicht zutraf, ist der Teil, den es sich zu notieren lohnt.

Der Einwand

Oskar von Dungern, ein Systemingenieur, der sich seit Jahren mit Kooperationsstandards in der mechatronischen Entwicklung beschäftigt, antwortete darauf wie folgt:

Wartezeiten an sich sind normal und lassen sich nicht vermeiden. Erst das Warten auf dem kritischen Pfad verzögert die Fertigstellung. Wenn Experten an mehreren Projekten arbeiten, entstehen entweder ungenutzte Kapazitäten bei reichlich vorhandenem Personal oder wartende Projekte bei knappen Kapazitäten. Man kann eine Organisation so gestalten, dass Projekte selten warten müssen, doch das bedeutet, dass man deutlich mehr Fachwissen vorhalten muss, als man tatsächlich benötigt. Die Betrachtung der Wartezeit ist sicherlich hilfreich. Sie ist eines von mehreren Optimierungskriterien.

Dr.-Ing. Oskar von Dungern

Jeder Satz davon ist richtig. Eine Warteschlange, die außerhalb des kritischen Pfades liegt, verursacht am Liefertermin keine Kosten. Ein Unternehmen, das so organisiert ist, dass kein Projekt jemals auf einen Spezialisten warten muss, ist ein Unternehmen, das für Spezialisten bezahlt, die häufig untätig sind. Wartezeit ist per Definition keine Verschwendung, und jede Warteschlange als Feind zu betrachten, führt zu einem anderen, ebenso kostspieligen Misserfolg.

Die Behauptung war also zu pauschal. Sie implizierte, dass Warten schlecht sei, doch Warten ist nicht schlecht. Es handelt sich um ein Symptom, dessen Bedeutung davon abhängt, in welchem Zusammenhang es auftritt.

Der kritische Pfad bleibt nicht unverändert

Doch hier dürfen wir die Sache nicht zu sehr vereinfachen: Die Reaktion, einfach nur den kritischen Pfad zu verwalten, ist im Prinzip richtig, in der Praxis jedoch gefährlich.

Im Bauwesen lässt sich der kritische Pfad im Voraus berechnen und ist relativ stabil. Man kennt den Abhängigkeitsgraphen, die Dauer wird anhand von Arbeiten geschätzt, die bereits mehrfach durchgeführt wurden, und der Pfad, den man im ersten Monat berechnet, entspricht in etwa dem Pfad, den man im neunten Monat beobachtet.

Bei der Produktentwicklung läuft das anders. Sowohl der Abhängigkeitsgraph als auch die Dauer ändern sich, während das Programm dazulernt. Ein thermischer Test widerlegt eine Annahme bezüglich der Gehäuseauslegung, und ein Teilsystem, für das ursprünglich sechs Wochen Spielraum vorgesehen waren, wird plötzlich zu dem Punkt, auf den alle warten. Eine Lieferantenschnittstelle erweist sich als weniger stabil, als im Schnittstellendokument angegeben. Der kritische Pfad ist keine Eigenschaft des Plans. Er ist eine Eigenschaft dessen, was man derzeit glaubt – und diese Überzeugungen ändern sich.

Der kritische Pfad ist eine Hypothese, die sich im Laufe der Zeit aktualisiert.

Das hat eine unangenehme Folge. Wenn Sie nur die Warteschlangen verwalten, die sich derzeit auf dem kritischen Pfad befinden, hinken Sie stets einen Schritt hinterher. Die Warteschlange, die Ihnen Probleme bereitet, ist genau die, die bei Ihrer letzten Überprüfung noch harmlos war.

Es gibt noch eine prägnantere Formulierung: Das Warten außerhalb des kritischen Pfades ist nicht kostenlos. Es handelt sich um verbrauchte Zeitreserven. Genau diese Zeitreserven ermöglichen es einem Pfad, unerwartete Ereignisse aufzufangen, ohne dass sich der Liefertermin verschiebt. Ein Schritt, der in einer langen Warteschlange steht, hat diesen Puffer bereits aufgebraucht; sobald er also auf den kritischen Pfad gelangt, verschiebt er den Termin sofort, ohne dass eine Abfederung stattfindet. Die Kosten sind bereits früher entstanden und werden erst später in Rechnung gestellt.

Dies ist dieselbe strukturelle Blindheit, die in Conway-Drift, wo sich Organisation und Architektur allmählich voneinander entkoppeln und keine einzelne Entscheidung falsch erscheint. Nichts ist sichtbar kaputt, bis die Koordinationskosten auf einen Schlag zum Tragen kommen.

Die Auslastungsfalle

Das Kapazitätsargument verdient eine echte Antwort und kein bloßes Zugeständnis, denn der von Oskar beschriebene Zielkonflikt ist real, und der Wechselkurs entspricht nicht den Annahmen der meisten Organisationen.

Es gibt einen Grund, warum Unternehmen überhaupt gemeinsame Fachkräfte einsetzen: Arbeitsteilung funktioniert. Ein Thermikspezialist, der fünf Projekte unterstützt, kann tiefergehende Fachkenntnisse entwickeln und wirtschaftlicher eingesetzt werden als fünf Thermikspezialisten, die in fünf Teams eingebettet sind. Die Alternative zum Abwarten ist daher nicht einfach nur ein “besserer Arbeitsfluss”. Die Beseitigung jeder Abhängigkeit würde auch einen Teil des wirtschaftlichen Nutzens der Spezialisierung zunichte machen.

Das Problem entsteht, wenn die Vorteile der Spezialisierung anhand der Auslastung bewertet werden, während die daraus resultierenden Koordinations- und Wartezeiten außer Acht gelassen werden. Die Arbeitsteilung schafft naturgemäß Abhängigkeiten. Diese Abhängigkeiten führen zu Warteschlangen. Die Frage ist nicht, ob man sie beseitigen soll, sondern ob der Nutzen der Spezialisierung die dadurch verursachten Verzögerungen überwiegt.

Arbeitsteilung funktioniert. Aber Arbeitsteilung schafft auch Abhängigkeiten, was wiederum zu Warteschlangen führt.

Die Wartezeit steigt nicht proportional zur Auslastung. Sie steigt überproportional an, wenn eine Ressource ihre volle Auslastung erreicht. Donald Reinertsen hat dies für die Produktentwicklung in Die Prinzipien des Produktentwicklungsflusses, und dabei kommt es vor allem auf den Verlauf der Kurve an: Wenn man die Auslastung eines gemeinsam genutzten Spezialisten von 95 Prozent auf 85 Prozent senkt, lässt sich mit nur wenig ungenutzter Kapazität eine erhebliche Verkürzung der Wartezeit erzielen. Eine Senkung von 85 auf 75 Prozent bringt hingegen deutlich weniger.

Der Zielkonflikt ist also real und zudem asymmetrisch. Die meisten Organisationen befinden sich auf der steilen Seite dieser Kurve, wo ein bescheidener Puffer eine überproportionale Verkürzung der Wartezeiten bewirkt, da Leerlaufzeiten in Berichten als Verschwendung erscheinen, während Wartezeiten in Warteschlangen in keinem Bericht überhaupt auftauchen. Mitarbeiter bis nahe an die volle Kapazitätsgrenze auszulasten, weil Leerlauf sichtbar ist, während die daraus resultierenden Warteschlangen die Reaktionsfähigkeit beeinträchtigen, ist so verbreitet, dass es dafür sogar einen eigenen Begriff gibt. Die Auslastungsfalle.

Was tatsächlich überlebt

Wenn man das herausnimmt, was durch den Einspruch hinfällig geworden ist, bleibt Folgendes übrig.

Jede Organisation, mit der ich zusammenarbeite, kann mir ihre Kapazitäten nennen: Personalbestand, Auslastung, die Kosten für einen Arbeitstag eines Spezialisten, die Länge der Warteschlange für die Testumgebung. Diese Zahlen gibt es, weil jemand sie im Budget einplanen musste.

Fast keiner von ihnen kann mir sagen, wie lange die Wartezeit war. Weder die Gesamtwartezeit, noch die Aufteilung zwischen aktiver Arbeit und Wartezeit für eine einzelne Funktion, noch welche dieser Wartezeiten zu diesem Zeitpunkt auf dem kritischen Pfad lag.

Das ist die Asymmetrie, und sie hängt nicht davon ab, ob Warten Verschwendung ist. Oskars Abwägung zwischen teurem, ungenutztem Fachwissen und verzögerten Projekten ist eine legitime wirtschaftliche Entscheidung. Dazu braucht es beide Zahlen. Wenn nur eine davon vorliegt, wird diese Abwägung dennoch jeden Tag automatisch getroffen. Sie wird nur nie bewusst getroffen.

Das ergibt eine bessere Behauptung als die, die ich gepostet habe:

Warten ist keine Zeitverschwendung. Unbegrenztes Warten ist eine Entscheidung, die niemand getroffen hat.

Eine Diagnose, die dem Einwand standhält

Nimm eine Funktion, die du letztes Jahr veröffentlicht hast. Eine echte, mit Datumsangaben.

Ermitteln Sie die Kalenderzeit vom ersten Auftrag bis zur Auslieferung und unterteilen Sie diese in aktive Arbeitszeit und Wartezeit. Stellen Sie dann für jeden Wartezeitabschnitt zwei Fragen statt nur einer.

War das damals Teil des kritischen Pfades?

Wäre es Teil des kritischen Pfades, wenn dieselbe Funktion heute in Ihrem Unternehmen zum Einsatz käme?

Die meisten Unternehmen können die erste Frage nicht beantworten, weil niemand dies dokumentiert hat. Fast keines hat die zweite Frage gestellt. Die zweite Frage gibt Aufschluss über das kommende Jahr, und genau in der Lücke zwischen den beiden Antworten verbirgt sich meist bereits die nächste Überraschung.

Wenn beide Antworten für jede von Ihnen gefundene Warteschlange „Nein“ lauten, ist Ihre Wartezeit tatsächlich nur eines von mehreren Kriterien, und Sie können mit gutem Gewissen etwas anderes optimieren. Dieses Ergebnis ist so selten, dass ich gerne davon erfahren würde.

Warum das jeden stören sollte, der ein technisches System betreibt

Der Einwand war besser als der Anspruch, den er angreifte – was wiederum das Argument dafür ist, Ansprüche zu veröffentlichen, die überhaupt angegriffen werden können. Ein Verfahren, gegen das man nichts einwenden kann, ist kein Verfahren. Es ist ein Slogan mit einer Grafik.

Aber beachten Sie, was diese Korrektur nicht bewirkt hat. Sie hat niemanden gerettet. Wenn Sie nicht sagen können, wie viel Zeit bei Ihrer letzten Lieferung mit Warten verbracht wurde, treffen Sie nicht Oskars Abwägung zwischen teurer Kapazität und verzögerten Projekten. Sie überlassen diese Entscheidung Quartal für Quartal der Zahl, die gerade auf einem Dashboard zu sehen ist.

Das Unangenehme daran ist, dass die Lösung kein Transformationsprogramm ist. Es handelt sich um die Neugestaltung eines einzelnen Aspekts, die ehrlich durchgeführt wird, wobei die damit verbundene Wartezeit neben der Arbeit vermerkt wird. Die meisten Organisationen haben so etwas noch nie auch nur ein einziges Mal gemacht.

Den ersten Tag der Product-Velocity-Schulung bei oose in Hamburg genau diese Rekonstruktion, anhand eines Fallbeispiels, das die Teilnehmer mitbringen. Dieses Seminar findet am 21. und 22. September auf Deutsch statt. Da viele Leser weder Deutsch sprechen noch in der Nähe von Hamburg wohnen, schließt dies die meisten Leser dieses Beitrags aus.

Was niemanden ausschließt: Führen Sie die oben beschriebene Diagnose für eine Funktion durch und teilen Sie mir die Nummer mit. Ich sammle diese Zahlen. Das Muster, das sich über alle Organisationen hinweg abzeichnet, erweist sich als interessanter als jede einzelne von ihnen, und Oskars Einwand ist der Grund, warum ich nun neben der ersten auch die zweite Frage stelle.