16 — Wertstromanalyse und DMAIC
Teil F — Wie man misst. Zurück zur Übersicht.
Lernziel
Nach diesem Kapitel kannst du eine Wertstromanalyse durchführen, Engpässe erkennen und den DMAIC-Zyklus als eines von mehreren Verbesserungsverfahren einordnen. Du weißt, warum es sinnlos ist, an einer Stelle zu optimieren, die nicht der Engpass ist.
16.1 Warum an der richtigen Stelle optimiert werden muss
In Kapitel 1 stand die Rechnung: zwei Arbeitstage Bearbeitung, 43 Tage Warten. Dieses Kapitel liefert das Handwerkszeug, um solche Zahlen systematisch zu erheben und daraus Maßnahmen abzuleiten.
Die zugrundeliegende Einsicht stammt aus der Engpasstheorie: In jedem Ablauf gibt es genau eine Stelle, die den Durchsatz begrenzt. Jede Verbesserung an einer anderen Stelle ist wirkungslos — sie erzeugt nur größere Warteschlangen vor dem Engpass.
Anforderung ──► Entwicklung ──► TEST ──► Freigabe ──► Ausrollen
3 Tage 14 Tage 2 Tage 1 Tag
▲
der Engpass
Entwicklung wird doppelt so schnell: 3 → 1,5 Tage
Gesamtdauer: 20 → 18,5 Tage. Gewonnen: 7 Prozent.
Testumgebung automatisiert: 14 → 1 Tag
Gesamtdauer: 20 → 7 Tage. Gewonnen: 65 Prozent.
Beide Verbesserungen kosten ähnlich viel Aufwand. Nur eine wirkt.
16.2 Die Wertstromanalyse
Das Verfahren stammt aus der schlanken Produktion und ist auf IT-Abläufe unmittelbar übertragbar.
Vorgehen
- Rahmen festlegen. Wo beginnt und endet die Betrachtung? Üblich: von der Anforderung bis zur produktiven Nutzung.
- Schritte aufnehmen. Jeden Arbeitsschritt in der tatsächlichen Reihenfolge, nicht in der beschriebenen.
- Zeiten erheben. Je Schritt Bearbeitungszeit und Wartezeit davor.
- Übergaben markieren. Jeder Wechsel der zuständigen Person oder Abteilung.
- Qualität erfassen. Wie oft muss ein Schritt wiederholt werden?
- Auswerten. Flow-Effizienz, Engpass, größter Einzelhebel.
Die Kennzahlen
Bearbeitungszeit = Summe der reinen Arbeitszeit Durchlaufzeit = Anfang bis Ende, inklusive Warten Flow-Effizienz = Bearbeitungszeit / Durchlaufzeit Erstdurchlaufquote = Anteil der Schritte ohne Nacharbeit
| Flow-Effizienz | Einordnung |
|---|---|
| unter 5 % | üblich, keineswegs ungewöhnlich |
| 5–15 % | bereits verbessert |
| 15–25 % | gut |
| über 25 % | sehr gut |
Beispiel: KFZ-Rechner, vorher und nachher
| Schritt | Vorher: Bearbeitung / Warten | Nachher |
|---|---|---|
| Anforderung aufnehmen | 2 h / 5 Tage | 2 h / 1 Tag |
| Entwickeln | 6 h / 3 Tage | 6 h / 0 |
| Code Review | 1 h / 4 Tage | 1 h / 3 h |
| Testumgebung bereitstellen | 15 min / 9 Tage | automatisch / 4 min |
| Testen | 4 h / 2 Tage | 12 min automatisch / 0 |
| Änderungsantrag und Freigabe | 1 h / 14 Tage | 15 min / 2 h (Standardänderung) |
| Ausrollen | 3 h / 6 Tage | 4 min automatisch / 0 |
| Durchlaufzeit | etwa 45 Tage | etwa 1,5 Tage |
| Flow-Effizienz | etwa 3,5 % | etwa 25 % |
Die Verbesserungen stammen ausschließlich aus den vorangegangenen Kapiteln — Automatisierung, Testpipeline, GitOps, Standardänderungen. Nichts davon ist besonders raffiniert; die Wirkung entsteht durch die Kombination.
Führe die Analyse mit den Beteiligten durch, nicht über sie hinweg.
Ein Wertstrom, den die Prozessabteilung im stillen Kämmerlein zeichnet, bildet den beschriebenen Ablauf ab. Der tatsächliche sieht regelmäßig anders aus — mit Umgehungen, Absprachen auf dem Flur und Schritten, die nur einer bestimmten Person bekannt sind.
Zwei Stunden mit allen Beteiligten an einer Wand mit Haftnotizen liefern ein ehrlicheres Bild als vier Wochen Interviews. Und sie erzeugen nebenbei etwas, das noch wertvoller ist: das gemeinsame Verständnis, dass niemand einzeln schuld ist.
16.3 Angefangene Arbeit begrenzen
Eine der wirkungsvollsten und billigsten Maßnahmen überhaupt — und eine der unbeliebtesten.
Das Gesetz von Little beschreibt den Zusammenhang:
Durchlaufzeit = angefangene Arbeit / Durchsatz 20 begonnene Aufgaben, 4 werden pro Woche fertig → 5 Wochen 8 begonnene Aufgaben, 4 werden pro Woche fertig → 2 Wochen
Wer weniger gleichzeitig anfängt, wird schneller fertig. Das widerspricht dem Gefühl, weil eine begonnene Aufgabe wie Fortschritt aussieht. Sie ist aber erst dann Wert, wenn sie fertig ist — vorher ist sie Bestand, der Aufmerksamkeit bindet.
Dazu kommen die Umschaltkosten: Wer an drei Dingen gleichzeitig arbeitet, verliert einen erheblichen Teil seiner Zeit an das Wiedereinfinden. Bei fünf parallelen Vorgängen ist der produktive Anteil je Vorgang erschreckend gering.
16.4 DMAIC
DMAIC ist der Kernzyklus des Qualitätsmanagementansatzes Six Sigma. Er ist ein strukturiertes, datengetriebenes Verbesserungsverfahren — und einer von mehreren möglichen Rahmen.
| Phase | Frage | Beim KFZ-Rechner |
|---|---|---|
| Define | Was ist das Problem? | Durchlaufzeit 45 Tage, Fachbereich unzufrieden |
| Measure | Wie groß ist es? | Wertstromanalyse, DORA-Kennzahlen erhoben |
| Analyse | Woran liegt es? | Engpass: Bereitstellung der Testumgebung, 9 Tage Wartezeit |
| Improve | Was ändern wir? | Umgebung per IaC automatisch bereitstellen |
| Control | Bleibt es so? | Durchlaufzeit monatlich messen, Abweichung meldet sich |
Die Phase, die am häufigsten übersprungen wird, ist Control.
Eine Verbesserung, die nicht überwacht wird, verfällt. Der automatisierte Ablauf bekommt eine Ausnahme, dann eine zweite, und nach einem Jahr ist der alte Zustand wiederhergestellt — nur mit zusätzlicher Werkzeugschicht.
Control heißt konkret: Die Kennzahl aus der Measure-Phase wird weiterhin erhoben, und es gibt einen vereinbarten Schwellwert, bei dessen Unterschreitung jemand handelt. Ohne diesen Teil ist DMAIC eine Projektmethode statt eines Verbesserungszyklus.
Wann DMAIC passt und wann nicht
| Passt zu | Passt nicht zu |
|---|---|
| wiederkehrenden, messbaren Abläufen | einmaligen Vorhaben |
| Problemen mit unklarer Ursache | Problemen mit offensichtlicher Ursache |
| Umgebungen, in denen Daten vorliegen | Situationen ohne Messgrundlage |
| Verbesserungen mit Formalisierungsbedarf | schnellen Experimenten |
Der bürokratische Aufwand von DMAIC ist nicht gering. Für die Frage „warum dauert die Testumgebung neun Tage„ reicht oft ein Nachmittag mit den Beteiligten und ein Ishikawa-Diagramm. Für ein Problem, das seit zwei Jahren wiederkehrt und dessen Ursache niemand kennt, ist der strukturierte Zyklus dagegen die richtige Wahl.
16.5 Verwandte Verfahren im Überblick
| Verfahren | Kern | Passt zu |
|---|---|---|
| PDCA | Plan-Do-Check-Act, kleiner Zyklus | kontinuierliche kleine Verbesserungen |
| DMAIC | datengetrieben, fünf Phasen | wiederkehrende, messbare Probleme |
| A3 | ein Problem auf einer Seite | Verdichtung, Führungskommunikation |
| Kaizen | Haltung der laufenden Verbesserung | Kultur, nicht Methode |
| Retrospektive | regelmäßige Teamreflexion | agile Teams, kurzer Takt |
| 5 Warum | fünfmal nachfragen | schnelle Ursachensuche |
| Ishikawa | Ursachen nach Kategorien | Sammlung möglicher Ursachen |
Die Wahl ist weniger wichtig als die Regelmäßigkeit. Ein Team, das jede zweite Woche eine halbe Stunde ehrlich zurückblickt und eine Maßnahme daraus umsetzt, verbessert sich zuverlässiger als eines mit einem ausgefeilten Verfahren, das zweimal im Jahr angewendet wird.
16.6 Lab: Wertstrom-Workshop
Vorbereitung: Haftnotizen in drei Farben, eine freie Wand, alle Beteiligten des Ablaufs, zwei Stunden Zeit.
- Schritte sammeln (Farbe 1). Jeder schreibt die Schritte auf, die er selbst ausführt. Anschließend gemeinsam in Reihenfolge bringen.
- Zeiten ergänzen (Farbe 2). Je Schritt Bearbeitungs- und Wartezeit. Schätzen ist erlaubt — grob und ehrlich schlägt genau und geschönt.
- Probleme markieren (Farbe 3). Wo gibt es Nacharbeit, Rückfragen, Blockaden?
- Rechnen. Durchlaufzeit, Bearbeitungszeit, Flow-Effizienz.
- Engpass bestimmen. Wo steckt die längste Wartezeit?
- Eine Maßnahme wählen. Genau eine, mit Verantwortlichem und Termin.
- Nachmessen. Nach vier Wochen dieselbe Analyse für einen neuen Vorgang.
Der sechste Punkt ist der schwierigste, und zwar aus einem menschlichen Grund: Nach zwei Stunden Analyse hat man zwölf Verbesserungsideen und will alle umsetzen. Genau das führt dazu, dass keine davon fertig wird — und bestätigt nebenbei das Prinzip aus Abschnitt 16.3 an der Verbesserungsarbeit selbst.
Eine Maßnahme, die in vier Wochen nachweislich gewirkt hat, ist mehr wert als zwölf angefangene.
16.7 Anti-Pattern
| Anti-Pattern | Folge | Abhilfe |
|---|---|---|
| An der falschen Stelle optimieren | Aufwand ohne Wirkung | Engpass zuerst bestimmen |
| Wertstrom ohne die Beteiligten | bildet den Wunsch ab, nicht die Wirklichkeit | gemeinsam an der Wand |
| Zwölf Maßnahmen gleichzeitig | keine wird fertig | eine, mit Termin |
| Control-Phase weglassen | Verbesserung verfällt | Kennzahl weiter erheben |
| Nur Bearbeitungszeit betrachten | die Wartezeit bleibt unsichtbar | beides erheben |
| Methodenstreit | Diskussion statt Verbesserung | irgendein Verfahren, aber regelmäßig |
| Verbesserung ohne Zeitbudget | „wenn mal Luft ist“ — also nie | feste Kapazität einplanen |
16.8 Reflexionsfrage
Wo steckt in deinem Ablauf die längste Wartezeit — und was wäre nötig, um sie zu halbieren?
Bemerkenswert oft lautet die Antwort auf den zweiten Teil nicht „mehr Personal„, sondern „eine Entscheidung, die niemand trifft“.
Weiter mit Kapitel 17 — DevOps im regulierten Umfeld