Das Missverständnis der vollen Auslastung. Warum wir in der Produktentwicklung den größten Gewinn mit maximal 80 % Auslastung erzielen
Ob staatlich unterstützter Großkonzern, Behörde oder mittelständischer Betrieb: 2025 stehen viele Unternehmen immer noch vor denselben Herausforderungen, wenn es um das Erreichen notwendiger Ziele in einem akzeptablen Zeitrahmen geht.
Probleme bereiten weiterhin
- exorbitant lange Lead Time (Entwicklungszyklen) – zum Kunden oder intern –
- schwankende Qualität und
- Unzuverlässigkeit in der Planung.
Während viele Organisationen versuchen, diese Symptome durch mehr Kontrolle, neue Tools oder optimierte Prozesse zu bekämpfen, liegt die Wurzel (und damit auch die Lösung) des Problems oft viel tiefer: in einem falschen Verständnis von Produktivität.
Das Missverständnis der vollen Auslastung
Ein verbreiteter Irrglaube in der Produktentwicklung ist: „Die Performance eines Systems steigt, wenn alle Bestandteile des Systems voll ausgelastet sind.“
An vielen Stellen wurde und wird dieses Prinzip aus der industriellen Fertigung kritiklos in die Software- und Produktentwicklung übernommen.
Hohe Auslastung kann jedoch nur dort angewendet werden, wo es wenig Varianz gibt, sprich wo Arbeitsschritte in exakt der gleichen Weise wiederholbar sind. Am Fertigungsband beispielsweise ist vollkommen klar, wann das nächste Werkstück zur Bearbeitung ansteht. Jede Varianz konnte hier eliminiert werden. Daher können wir die Zeit dazwischen auf ein Minimum drücken und so Leerlauf verhindern, um den maximal möglichen Profit zu erwirtschaften.
Durch die klare Vorhersehbarkeit des Arbeitsaufwands für jedes Team kann die Zeitspanne zwischen den Projekten
auf ein Minimum reduziert werden.
Doch immer da, wo keine Vorhersagbarkeit in Bezug auf die Arbeitsschritte gegeben ist, da diese von diversen Abhängigkeiten und Varianzen bestimmt werden, folgt der maximale Profit einem völlig anderen Prinzip.
So im Entwicklungsumfeld: In den allermeisten Fällen können wir dort nicht genau sagen, wie lange die Erledigung einzelner Teilarbeit braucht. Wir wissen nicht, wie lange die Entwicklung eines spezifischen Themas dauert (Varianz in der Aufgabendauer). Genauso wenig können wir sagen, wie oft wir an ein Thema ran müssen, bis wir es richtig gemacht haben (Iterations-Varianz).
Der Zeitraum zwischen den Projekten ist derselbe wie in Abb. 1., führt hier für die Teams jedoch zu Problemen, da
Arbeitsschritte verschiedener Projekte kollidieren und für Verzögerung des gesamten weiteren Ablaufs führen werden.
Setzen wir in der Produktentwicklung mit ihren Komplexitäten und Varianzen trotzdem auf sehr hohe oder volle Auslastung unseres Systems, also z.B. der Entwicklungs-Teams und Expert:innen, führt das zu genau gegenteiligen Effekten:
Mangelnde Flexibilität behindert Innovation und Reaktionsfähigkeit
Volle Auslastung bedeutet, dass kein Raum für ungeplante Arbeit, unerwartete Schwierigkeiten oder gar Innovation bleibt. Werden wir in einer solchen Situation gezwungen zu handeln und Dinge zu verändern – sei es durch neue Gesetze, eine veränderte Marktsituation, Personalmangel oder Lieferengpässe –, wird ein überlastetes, träges Systeme massive Schwierigkeiten haben, die Situation schadlos zu überstehen.
Engpässe und Staus sorgen für eine hohe Lead Time
Wenn alle Teams oder Ressourcen ständig ausgelastet sind, entstehen zwangsläufig Staus:
Jeder von uns kennt Situationen, in denen eine einzige ungeplante Arbeit den ganzen Arbeitsfluss zusammenbrechen lässt. Anfällig dafür sind besonders komplexe Arbeitsschritte, die sich nicht in kleinere Ziele unterteilen lassen. Ähnlich schwierig wird es, wenn die Verfügbarkeit von Teammitgliedern/ganzen Teams oder andere Ressourcen, die für die Erledigung notwendig sind, durch parallele Projekte eingeschränkt ist.
Als Beispiel nenne ich an der Stelle gerne die Situation bei einem unserer Kunden, wo es in 56 Iterationen nicht ein einziges Mal geschah, dass die Arbeit, die man sich für die vier Wochen vorgenommen hatte, auch wirklich abgeschlossen werden konnte. Stattdessen wurden diese „Spillovers” in die nächste Iteration mitgenommen – und zeitgleich versucht, den bereits erledigten Arbeitsanteil durch Schätzung zu berücksichtigen. Ein Scatterplot zeigte folgerichtig eine mittlere Lead Time von 84 Tagen.
Solche teils gravierenden Verzögerungen sind vergleichbar mit dem „Stau aus dem Nichts” auf der Autobahn. Der entsteht nicht durch einen Unfall oder eine Baustelle, sondern dadurch, dass bei hoher Auslastung der Fahrbahnen ein einzelnes Auto aus unvorhersehbaren Gründen plötzlich abbremst und eine Stauwelle verursacht, die sich fortsetzt.
Multitasking und das Springen zwischen den Aufgaben führt zu Qualitätseinbußen
Um das „System am Laufen zu halten“, versuchen Teams häufig, parallel an verschiedenen Aufgaben zu arbeiten. Dadurch entstehen immer neue „Spillovers” aus vorherigen Zyklen. Um diesen irgendwie gerecht zu werden, springen Teams häufig zwischen Aufgaben hin und her. Das beeinträchtigt den notwendigen Fokus oft sehr und führt zu Abkürzungen zu Lasten der Qualität, um Termine doch noch halten zu können.
Besonders fatal kann diese Situation in Kombination mit einem „blinden” Reporting werden, das nicht auf die Qualität oder tatsächlich beendete Tasks schaut, sondern auf Teilergebnisse und Quantität im Prozess setzt. Solche Kennzahlen werden das Fertigstellen von Arbeit und das Liefern von Wert nicht fördern, sondern die Mehrfachbelastung von Teams weiter schüren.
Die Folgen: Die Aufgaben bleiben irgendwo im System stecken, die eigentlichen Prioritäten werden diffus und am Ende eines Zyklus sind viele Aufgaben irgendwo in einem Fertigstellungsgrad von 70-80 Prozent gefangen – aber eben nicht fertig.
Ein produktiver Workflow in der Produktentwicklung verlangt, dass das Arbeitssystem zu nicht mehr als 80 % ausgelastet wird
Die Auslastungs-Grenze, ab der ein System durch ganz alltägliche Störungen beginnt, Staus im Workflow aufzubauen, ist mathematisch berechenbar mittels der Kingman Formel.
Bei einer Auslastung (Utilization) jenseits von 80 % steigt die Wartezeit „geparkter”/gelagerter Teilergebnisse im Prozess plötzlich exponentiell an:
Plakativ gesagt: Wenn Reaktionsfähigkeit für meine Unternehmung relevant ist (sprich: eine schnelle Auslieferung fertiger Tasks), muss ein gewisser Anteil Puffer innerhalb der Systemauslastung, mindestens 20 %, eingeplant werden.
Für eine Organisation, die im Bereich digitaler Produktentwicklung tätig ist, könnte dieser Puffer so aussehen, dass besonders gefragte Ressourcen, wie einzelne Spezialisten oder Experten-Teams, nur zu max. 80 % ihrer Zeit mit Arbeit ausgelastet werden. So kann die restliche Zeit bei Bedarf für die Reaktion auf Unvorhergesehenes genutzt werden, ohne dass dies unmittelbar Projektstau zur Folge hat. Und Hand auf Herz: „Unvorhergesehen“ ist der Alltag in der Produktentwicklung, nicht die Ausnahme. Der Grund dafür ist wie oben beschrieben: Die Varianz.
Wenn wir diese Grundprinzipien nicht berücksichtigen, erhalten wir ein System, das ineffizient, langsam und unflexibel auf Veränderungen reagiert. (Wer das eindrucksvoll selbst erleben und mit den Faktoren, die auf den Arbeitsfluss und das Endergebnis einwirken, experimentieren möchte, dem empfehle ich die Simulation X:FLOW Game.)
Aber wie können wir herausfinden, wie es bezüglich der Systemauslastung in unserem Unternehmen steht?
In meinem nächsten Beitrag sehen wir uns an, wie wir mithilfe von Kanban zu einer Visualisierung des Workflows im Arbeitssystem gelangen und wie wir uns die Erkenntnisse daraus zu Nutze machen, um schädliche Überlastung in der Folge zu verhindern und abzubauen.
Wie verbessern wir den Arbeitsfluss in unserer Organisation?
Kanban-Experte Daniel Westermayr ist in einem kostenlosen Erstgespräch für Sie da.
Jetzt Termin vereinbaren mit dem Betreff „Arbeitsfluss“.