Was tun, wenn die Aufträge schneller hereinkommen als sie bearbeitet werden können? Sich ihnen nacheinander zu widmen, also immer nur einen Auftrag zur Zeit als Team in Arbeit zu haben, scheint nicht zu funktionieren. Die Lieferzeiten werden länger und länger.
Annette, Beatrice und Carolin schauen sich genauer an, wie sie bisher mit den Aufträgen umgegangen sind. Ihre Regel first come, first serve und die streng sequenzielle Abarbeitung haben dazu geführt, dass Aufträge in eine Warteschlange aufgenommen werden mussten: das Backlog. Darin “standen sie herum”, bis die Arbeit an ihnen begonnen wurde, die dann allerdings ruckzuck erledigt war.
Die wachsende Lieferzeit von Auftragsannahme bis Fertigstellung bestand also aus einer immer gleichen Flow Time für die Produktion plus einer wachsenden Queue Time (QT) vor Produktionsbeginn.
First come, first serve ist also nicht schuld an der langen Lieferzeit, sondern das “Parken” der Aufträge, um sie nacheinander voll konzentriert abzuarbeiten. Immer nur ein Auftrag zur Zeit sollte bearbeitet werden; die Gründerinnen hatten also ihr Work in Process (WIP) auf 1 begrenzt.
Indem an jedem Tag ein Auftrag von Anfang bis Ende bearbeitet wurde, fielen auch die Wartezeiten bei Tageswechseln weg. Das war auch Ziel dieser Vorgehensweise. Doch diese Wartezeiten in der Flow Time, also während der Auftragsbearbeitung, waren — wie sich herausstellte — klein im Vergleich zu den länger und länger werdenden Queue Times vor Beginn der Auftragsbearbeitung.
WIP = 1 war bestimmt eine gute Entscheidung für maximale Qualität — andererseits hat dieses Ideal zu den wachsenden Lieferzeiten geführt. Vielleicht sollten sie sich davon verabschieden und schneller auf Auftragseingänge reagieren? Mindestens ein Experiment wäre das wert; schlimmer als die bisher schon wachsenden Lieferzeiten kann es eigentlich nicht werden.
Zur Erinnerung:
- Touch Time (TT): Die Zeit, die Hand angelegt wird an einen Auftrag.
- Wait Time (WT): Die Zeit, in der ein angefangener Auftrag "herumsteht" und darauf wartet, dass wieder Hand an ihn gelegt wird.
- Flow Time (FT): Touch Time + Wait Time
- Queue Time (QT): Die Zeit, die ein Auftrag darauf wartet, überhaupt erstmal begonnen zu werden.
- Lead Time (LT): Die Zeit, die es braucht von Auftragsannahme bis Lieferung, also Queue Time + Flow Time.
Starten statt Warten
Aus Sicht der Kunden ist die Queue Time natürlich auch Wartezeit. Die wollen die Gründerinnen nun verkürzen, indem sie jeden Auftrag beginnen, sobald er eintrifft. Warum Aufträge überhaupt in eine Warteschlange stellen? So gut scheint die Idee mit dem Backlog vielleicht doch nicht gewesen zu sein, wenn dadurch die Lieferzeit länger und länger geworden ist.
Die neue Regel von Annette, Beatrice und Carolin lautet: Jeder Auftrag wird nach Eingang schnellstmöglich begonnen. Falls schon ein anderer Auftrag in Bearbeitung ist, wird der nach spätestens 30 Minuten unterbrochen. Statt einen Auftrag von Anfang bis Ende durchzuziehen, wollen sie nun die Aufträge in “Scheibchen schneiden”; jedes Scheibchen ist mindestens 30 Minuten lang. Eine maximale Länge gibt es nicht. Wenn nur noch ein Auftrag zu bearbeiten ist, kann an dem selbstverständlich solange gewerkelt werden, bis er fertig ist — oder ein anderer begonnen werden muss.
Indem die Gründerinnen Aufträge so schnell wie möglich starten, wollen sie jede Queue Time vermeiden und insgesamt schneller liefern. Aber klappt das auch? Für die dritte Woche im März sieht die Idee der Gründerinnen so aus (der Einfachheit halber schließen die Tage mit ihren 6 Stunden Arbeitszeit für die Produktion direkt aneinander an; nächtliche Wartezeit wird nicht gezählt):
Eine Queue Time gibt es nicht mehr; die Arbeit beginnt sofort und endet deshalb auch bald.
Oder nicht?
Nein! Diese Vorstellung ist eine Illusion! Das ist ein naives Bild. So einfach funktioniert Multi-Tasking nicht! Nichts anderes wollen die Gründerinnen ja tun: Sie wollen an mehreren unabgeschlossenen Aufträgen (quasi) gleichzeitig arbeiten. WIP für sie als eine Team Ressource ist größer als 1 (im Bild manchmal 3).
Mindestens zwei offensichtliche Fehler hat die Darstellung:
Erstens ist in dem Bild keine Unterbrechung des einen Auftrags für einen anderen zu sehen.
Zweitens fehlt jeder “Umschaltaufwand” beim Wechsel zwischen den gleichzeitig in Bearbeitung befindlichen Aufträgen.
Eine Queue Time gibt es zwar nicht mehr, doch die Produktion ist trotzdem nicht zügig. Im Gegenteil! Denn die Flow Time wird aufgebläht durch zunehmende Wartezeiten. Und jeder Wechsel zu einem anderen Auftrag, um den wieder ein Stück voran zu bringen, kostet Zeit. Die Erfahrung und auch Studien sagen, dass solcher “Umschaltaufwand” zwischen 5 und 15 Minuten frisst (Switch Time (ST)). In dieser Zeit wird nicht wirklich an der Aufgabe, der man sich zuwendet, produktiv gearbeitet; vielmehr bringt man sich nur erstmal wieder auf den Ist-Stand, bevor es danach weitergeht.
Letztlich ist die Switch Time jedoch nicht das Hauptproblem; es sind die Wartezeiten zwischen den “Scheibchen”, in denen die Aufträge bearbeitet werden. Das reale Bild sieht so aus:
Die Touch Time Blöcke der Aufträge werden weiter und weiter auseinander gezogen. Je größer die Zahl der angefangenen Aufträge, je größer WIP, desto länger dauert es einfach, bis ein Auftrag wieder dran ist.
Mal angenommen:
WIP ist 3 und die Touch Time Blöcke sind 30 Minuten lang,
dann wartet ein Auftrag, nachdem der Fokus zu einem anderen gewechselt ist, mindestens 60 Minuten, bis er wieder dran ist: (WIP-1) * 30 Minuten; im Beispiel: (3-1) * 30 Minuten = 2 * 30min = 60 Minuten.
Da sich die Flow Time (= Touch Time + Wait Time) mit zunehmender Zahl angefangener Aufträge verlängert, kommt es bei weiteren eintreffenden Aufträgen zu einem stark verlangsamenden Effekt je Auftrag. Das obige Bild wird schwärzer und schwärzer durch die für jede angefangene Aufgabe steigende Wait Time. Die Gründerinnen sind permanent aktiv — doch jeder einzelne Auftrag kommt nur schleppend voran. Sie können nicht anders, als schwarz zu sehen für die Zukunft ihres Business, wenn sie weiterhin auf Multi-Tasking setzen.
Dass ein Auftrag Touch Time erfährt, wird zur Seltenheit. Die so genannte Flow Efficiency (FE) sinkt rapide. Sie stellt das Verhältnis zwischen der Summe aller Touch Times je Auftrag und der Dauer für seine Erledigung dar, der Flow Time:
Unter dem Bruchstrich geht die Wait Time in die Flow Efficiency ein. Deshalb ist die Flow Efficiency umso kleiner, je größer die Wait Time wird. Ein FE-Wert von 1 ist ideal. So war es zu Beginn, als die Auftragslage von Instant Insight noch nicht so gut war: jeder Auftrag wurde konzentriert “in einem Rutsch” von Anfang bis Ende erledigt. 5,5 Stunden Flow Time entsprachen 5,5, Stunden Touch Time. So war es auch noch, als die Aufträge in der Warteschlange standen; denn die Queue Time ist keine Wait Time während der Produktion.
Doch durch das Multi-Tasking sinkt die Flow Efficiency rapide; der häufige Wechsel zieht Aufmerksamkeit von jedem angefangenen Auftrag ab und lässt ihn warten. Zum Beispiel stehen bei Auftrag XXVII 30 Minuten TT schon knapp 6 Stunden WT gegenüber.
Die FT ist damit auf 8,3% gesunken. Was wird die Lieferzeit für diesen Auftrag sein? Das hängt vom weiteren Auftragseingang ab; wenn mehr Aufträge begonnen werden müssen, während der Auftrag noch nicht beendet wurde, können daraus 5, 6 oder auch 9 Tage werden.
Der gut gemeinte Ansatz, Aufträge nicht in einer Warteschlange warten zu lassen, ist also ein Rohrkrepierer. “Starten statt Warten” ist kein Erfolgsmotto! Zu weiterhin unabsehbar langen Lieferzeiten kommt hier auch noch der Wahnsinn des ständigen Umschaltens zwischen angefangenen Aufträgen. Wie sollen die Gründerinnen da den Überblick behalten?
Die Gründerinnen sind jeden Abend geschafft, ohne etwas geschafft zu haben. Das lässt sie ihre desaströse Taktik schnell bemerken. So kann es nicht weitergehen. In ihren Reflexionsrunden können sie den Zusammenhang zwischen ihrer Erschöpfung und dem unsinnigen, gar kontraproduktiven Vorgehen deutlich sehen.
Aufträge so schnell wie möglich zu beginnen, um dem Kunden Servicewillen zu demonstrieren oder gar die Lieferzeit zu verkürzen, obwohl noch andere Aufträge in der Produktion sind, ist eine fatale Idee. Working hard hat ihnen nichts gebracht.
Die Abarbeitung strickt nacheinander hat eine hohe Flow Efficiency, aber dennoch wachsende Lieferzeiten durch Queue Time. Die Abarbeitung im kurz getakteten Multi-Tasking hat eine niedrige Flow Efficiency, ebenfalls wachsende Lieferzeiten und führt auch noch direkt in die Erschöpfung. Gibt es vielleicht einen Mittelweg? Beides ist keine Option. Aber wie kann dann eine Lösung aussehen?
Die Gründerinnen sind zwar erschöpft von ihrem Ausflug ins Multi-Tasking, doch sie lassen den Mut nicht sinken. So, wie sie eine gute Balance zwischen Arbeit und Freizeit als grundlegend ansehen, glauben sie daran, dass working hard nicht die Lösung sein kann und darf. Sie setzen auf working smart. Aus der Philosophie ist ihr Produkt entstanden. Damit werden sie auch eine Lösung für ihre Arbeitsorganisation finden.
Wer erfahren will, welchen Ansatz die Gründerinnen als nächstes ausprobieren wollen, der drückt den Knopf und wird per E-Mail informiert.