DMAIC: Die 5 Phasen der Six-Sigma-Verbesserung (mit Werkzeugen und Beispielen)

Die meisten Prozessprobleme werden auf dieselbe Weise gelöst: Jemand bemerkt einen Fehler, eine Besprechung findet statt und eine Lösung wird umgesetzt. Wochen später ist der Fehler zurück. Das ist kein schlechtes Glück, das ist das, was passiert, wenn man direkt zu Lösungen springt, ohne zu messen, was tatsächlich kaputt ist, oder zu beweisen, was es verursacht hat. DMAIC unterbricht diesen Kreislauf, indem es in jedem Schritt Strenge einfordert, bevor Sie den Prozess anfassen dürfen.

DMAIC (ausgesprochen "duh-may-ick") ist die strukturierte Verbesserungsmethodik im Kern von Six Sigma. Jeder Buchstabe ist ein Tor, das passiert werden muss: Problem definieren, Ist-Zustand messen, Grundursache analysieren, mit einer getesteten Lösung verbessern, und die Gewinne kontrollieren, damit sie nicht verfallen. Eine Phase überspringen und das gesamte Projekt ist gefährdet.

Was ist DMAIC?

DMAIC ist der 5-phasige Verbesserungszyklus, der das operative Rückgrat von Six Sigma bildet. Das Akronym steht für Define (Definieren), Measure (Messen), Analyze (Analysieren), Improve (Verbessern) und Control (Steuern). Es gibt Teams einen wiederholbaren, datengetriebenen Fahrplan, um Fehler zu reduzieren, Zykluszeiten zu verkürzen und Qualitätsgewinne zu sichern.

Die Methode wurde Mitte der 1980er-Jahre bei Motorola vom Zuverlässigkeitsingenieur Bill Smith und Statistiker Mikel Harry als Teil ihres ursprünglichen Six-Sigma-Rahmens kodifiziert. Motorola benötigte einen strukturierten Weg, um die Qualität auf 3,4 Fehler pro Million Möglichkeiten (DPMO) in seinen Fertigungslinien zu steigern. DMAIC war das Mittel dazu. Als Jack Welch Six Sigma 1995 im gesamten GE-Konzern einführte, wurde DMAIC weltweit zum Standard-Verbesserungsrahmen für große Unternehmen und verbreitete sich von der Fertigung in das Gesundheitswesen, die Finanzbranche, Logistik und Software.

Was DMAIC von einfacheren Rahmenwerken unterscheidet, ist das Bestehen auf Messung vor Handlung. Sie definieren keine Grundursache, bis Sie Daten haben. Sie starten kein Pilotprojekt für eine Lösung, bis Sie die Grundursache statistisch bestätigt haben. Sie erklären keinen Erfolg, bis ein Steuerungssystem vorhanden ist. Diese Abfolge ist sowohl seine Stärke als auch der Grund, warum Projekte ins Stocken geraten, wenn Teams versuchen, sie abzukürzen.

Key Facts

• Motorola, das Six Sigma und DMAIC 1986 ins Leben rief, schrieb der Methodik bis 2006 kumulierte Einsparungen von über 17 Milliarden US-Dollar zu, laut Zahlen der American Society for Quality (ASQ).
• GE meldete zwischen 1996 und 2001 kumulierte Six-Sigma-Vorteile von 10 Milliarden US-Dollar in seinen Jahresberichten, was es zur meistzitierten Unternehmensfallstudie für DMAIC im großen Maßstab macht.
• Six Sigma und Lean Six Sigma gehören konsistent zu den gefragtesten Prozesskenntnissen in der Fertigung und im Betrieb, mit Hunderttausenden aktiver Belt-Zertifizierungen, die von der International Association for Six Sigma Certification (IASSC) verfolgt werden.

Die 5 Phasen von DMAIC erklärt

DMAIC ist von Natur aus sequenziell. Jede Phase liefert ein Ergebnis, das den Eintritt in die nächste bestimmt. Teams, die Phasen parallel durchführen oder die Messphase überspringen, lösen fast immer das falsche Problem. Hier ist, was in jeder Phase passiert.

D - Define (Definieren)

Die Define-Phase beantwortet eine Frage: Welches Problem lösen wir eigentlich, und lohnt es sich zu lösen? Teams erstellen einen Projektauftrag (Project Charter), ein einseitiges Dokument, das das Problem, das Ziel, den Umfang, den Business Case und die Teammitglieder enthält. Ohne ihn gerät der Projektumfang außer Kontrolle und Sponsoren verlieren das Engagement.

Die anderen zwei Kernelemente in Define sind das SIPOC-Diagramm (Suppliers, Inputs, Process, Outputs, Customers) und Voice of the Customer (VOC)-Recherche. SIPOC gibt allen einen Überblick über den Prozess, bevor jemand ins Detail geht. VOC übersetzt Kundenbeschwerden, Umfragen und Support-Tickets in messbare Qualitätsanforderungen. Sie können "Fehler" nicht definieren, bis Sie wissen, was dem Kunden tatsächlich wichtig ist. Define endet, wenn das Team sich auf die Problembeschreibung und Erfolgskennzahlen geeinigt hat und der Sponsor den Projektauftrag unterzeichnet hat.

M - Measure (Messen)

Measure etabliert die Baseline. Bevor Sie etwas verbessern können, müssen Sie wissen, wie schlecht der Ist-Zustand ist, und ob Ihr Messsystem vertrauenswürdig genug ist, um Verbesserungen zu verfolgen. Das Kernergebnis ist der Prozessfähigkeitsindex (Cp und Cpk), der Ihnen sagt, wie gut der aktuelle Prozess in die Spezifikationsgrenzen des Kunden passt.

Der Datenerhebungsplan dokumentiert genau, welche Daten Sie erheben werden, wie und woher. Ohne ihn enden Teams mit inkonsistenten Datensätzen, die eine Analyse unmöglich machen. Viele Teams führen auch eine Measurement System Analysis (MSA) durch, die prüft, ob die Messinstrumente, Software oder menschlichen Bewerter, die zur Datenerhebung verwendet werden, zuverlässig sind. Measure endet, wenn Sie eine bestätigte Baseline haben: eine Fehlerquote, eine Zykluszeit, eine Fehlerrate, was auch immer der Projektauftrag zu verbessern versprach.

A - Analyze (Analysieren)

Analyze ist der Punkt, an dem das Team von "hier sind die Daten" zu "hier ist der Grund" übergeht. Das Ziel ist es, die Grundursache mit Belegen zu bestätigen, nicht nur plausible Theorien zu entwickeln. Die zwei häufigsten Ausgangswerkzeuge sind das Fishbone-Diagramm (auch Ishikawa- oder Ursache-Wirkungs-Diagramm genannt) und die 5-Warum-Technik, die von der Ursache zur systemischen Ursache führt, indem sie wiederholt "warum" fragt.

Aber Analyze stoppt nicht bei qualitativen Werkzeugen. Teams verwenden Hypothesentests (t-Tests, Chi-Quadrat-Tests, Regressionsanalyse), um zu bestätigen, welche vermuteten Ursachen statistisch signifikant sind. Das ist es, was DMAIC von bauchgefühlbasierter Problemlösung unterscheidet: Sie können erst zu Improve übergehen, wenn Sie mit Daten gezeigt haben, dass die Beseitigung der identifizierten Grundursache die Lücke zwischen Ihrer aktuellen Baseline und Ihrem Ziel schließen würde. Analyze endet mit einer validierten Grundursache und einer klaren Aussage, wie viel des Problems sie erklärt.

I - Improve (Verbessern)

Improve entwirft, testet und wählt die Lösung aus. Das Team entwickelt mehrere Lösungsoptionen gegen die bestätigte Grundursache und verwendet dann eine Priorisierungsmatrix oder Failure Mode and Effects Analysis (FMEA), um Risiko, Kosten und Auswirkungen zu bewerten, bevor ein Pilot durchgeführt wird. Design of Experiments (DOE) ist das statistische Werkzeug der Wahl, wenn mehrere Faktoren interagieren und Sie die optimale Kombination von Einstellungen finden müssen, ohne jede Permutation zu testen.

Der Pilot ist unverzichtbar. Ein kleiner, kontrollierter Test bestätigt, dass die vorgeschlagene Lösung die Kennzahl tatsächlich bewegt, bevor das Team in einen vollständigen Rollout investiert. Pilotergebnisse werden gegen die Measure-Phase-Baseline gemessen: Ist die Fehlerquote gesunken? Ist die Zykluszeit geschrumpft? Wenn die Verbesserung bestätigt ist, dokumentiert das Team den neuen Prozess und bereitet die Übergabe vor. Improve endet, wenn die Pilotdaten beweisen, dass die Lösung funktioniert.

C - Control (Steuern)

Control verwandelt einen Piloterfolg in eine dauerhafte Prozessänderung. Das Kernergebnis ist ein Kontrollplan, ein Dokument, das definiert, was überwacht wird, wie oft, wer es verantwortet und welche Maßnahmen ergriffen werden, wenn die Kennzahl außerhalb akzeptabler Grenzen driftet. Ohne Kontrollplan verfallen Verbesserungsprojekte: Mitarbeiter wechseln, Workarounds schleichen sich wieder ein, und die Fehlerquote steigt.

Statistical Process Control (SPC)-Charts sind das Standard-Überwachungswerkzeug. Sie tragen die Kennzahl über die Zeit mit Kontrollgrenzen auf und machen es visuell offensichtlich, wenn der Prozess driftet versus normale Streuung zeigt. Schulungsmaterialien und aktualisierte Standard Operating Procedures (SOPs) formalisieren die neue Arbeitsweise. Das Projekt schließt formal, wenn der Prozessverantwortliche die Verantwortung für die Aufrechterhaltung der Gewinne übernimmt und der Sponsor die abschließenden Ergebnisse unterzeichnet. Control ist die Phase, in die die meisten Teams zu wenig investieren, und sie ist der Grund, warum die meisten Gewinne zwei Jahre später noch vorhanden sind, oder es nicht sind.

In jeder DMAIC-Phase eingesetzte Werkzeuge

Jede Phase hat eine kurze Liste bevorzugter Werkzeuge. Sie werden sie nicht alle bei jedem Projekt einsetzen, aber das Wissen um das Angebot ermöglicht es Ihnen, das richtige Werkzeug für die benötigten Belege zu wählen.

CTQ steht für Critical to Quality, die Übersetzung von Kundenanforderungen in messbare interne Prozessspezifikationen. MSA steht für Measurement System Analysis. FMEA steht für Failure Mode and Effects Analysis. DOE steht für Design of Experiments. SPC steht für Statistical Process Control. RACI steht für Responsible, Accountable, Consulted, Informed.

Praxisbeispiel: Rechnungsfehler bei einem B2B-Unternehmen reduzieren

Ein mittelständisches Logistikunternehmen, nennen wir es FreightCo, hatte eine Fehlerquote von 8 % bei ausgehenden Rechnungen. Das Finanzteam verbrachte etwa 40 Stunden pro Monat mit Korrekturen, und zwei Kunden hatten formale Streitigkeiten eingeleitet. Der CFO sponserte ein DMAIC-Projekt mit dem Ziel, die Fehlerquote innerhalb eines Quartals unter 1 % zu bringen.

Define. Der Projektauftrag begrenzte das Problem auf ausgehende B2B-Rechnungen, die über das ERP-System verarbeitet werden. Das SIPOC bildet den Fluss vom Eingang der Bestellung bis zur Genehmigung und dem Versand der Rechnung ab. VOC-Interviews mit den zwei streitenden Kunden identifizierten den Fehlertyp: falsche Stückpreise wurden auf Positionen angewendet.

Measure. Das Team zog drei Monate Rechnungsdaten und bestätigte die Fehlerquote von 8,1 % (412 Fehler aus 5.087 Rechnungen). Eine MSA des manuellen Prüfprozesses zeigte, dass Prüfer in 18 % der Fälle nicht übereinstimmten, ob eine Preisabweichung ein "Fehler" oder eine "Rundung" war, ein Messsystemproblem an sich, das das Team durch Verschärfung der Fehlerdefinition behob, bevor es fortfuhr. Die Prozessfähigkeit zeigte, dass der Rechnungsprozess bei etwa 2,8 Sigma lief.

Analyze. Ein Fishbone-Diagramm generierte 11 Kandidatenursachen in den Kategorien Mensch, Prozess, Systeme und Daten. Die Fünf-Warum-Analyse der drei Hauptkandidaten landete immer wieder an einem Ort: Die Lieferantenstammdatentabelle im ERP hatte keine automatische Validierung. Preisänderungen von Lieferanten wurden manuell eingepflegt, und die Aktualisierungsrate lief zwei bis fünf Tage hinter dem tatsächlichen Änderungsdatum her. Hypothesentests bestätigten, dass 73 % der Preis-Fehler-Rechnungen während des Verzögerungsfensters nach einer Lieferantenpreisänderung generiert worden waren.

Improve. Das Team erarbeitete zwei Lösungen: (1) eine automatische Validierungsregel, die die Rechnungsgenerierung blockierte, wenn ein Positionspreis außerhalb eines lieferantenspezifischen Toleranzbands lag, und (2) ein SLA, das verlangte, dass Lieferantenpreisänderungen innerhalb von 24 Stunden eingetragen werden. Sie führten einen vierwöchigen Pilot mit der aktiven Validierungsregel für ein Kundensegment durch. Die Fehlerquote für dieses Segment sank auf 0,9 %, innerhalb des 1 %-Ziels. FMEA bestätigte, dass die Regel keine unzulässigen Fehlalarme über einer akzeptablen Rate erzeugen würde.

Control. Die Validierungsregel wurde für alle Konten aktiviert. Ein monatliches SPC-Chart zur Verfolgung der Rechnungsfehlerquote wurde dem Manager des Kreditorenbuchhaltungsteams zugewiesen. Der Kontrollplan definierte einen Aktionsauslöser bei 2 %, wenn die Quote diese Grenze überschritt, wurde das Lieferantenstammdaten-Auditprotokoll automatisch gestartet. Sechs Monate nach Abschluss hielt die Fehlerquote bei 0,8 %.

Das Projekt reduzierte den Korrekturaufwand von 40 Stunden pro Monat auf unter 5, und die zwei Kundenstreitigkeiten wurden beigelegt. Gesamtprojektlaufzeit: 11 Wochen.

DMAIC vs. PDCA vs. DMADV

DMAIC ist eines von mehreren iterativen Verbesserungsrahmenwerken. Die zwei, die Sie am häufigsten daneben sehen werden, sind PDCA und DMADV. Siehe auch unseren Leitfaden zur Prozessoptimierung für einen umfassenderen Vergleich.

Der Kernunterschied: DMAIC repariert, was vorhanden ist. DMADV, manchmal DFSS (Design for Six Sigma) genannt, gestaltet etwas Neues. PDCA ist leichtgewichtiger und schneller zu durchlaufen; es erfordert keine statistischen Hypothesentests, was es für Teams ohne einen Black Belt zugänglich macht. Aber die Geschwindigkeit von PDCA kann bei komplexen Problemen, bei denen die Grundursache nicht offensichtlich ist, ein Nachteil sein. Lesen Sie unseren Artikel zu PDCA für eine vollständige Analyse.

DMAIC und Lean Methodology werden häufig zu Lean Six Sigma kombiniert, das Lean-Werkzeuge (Value Stream Mapping, 5S, Kanban) in den Analyze- und Improve-Phasen neben dem statistischen Werkzeugkasten von DMAIC einsetzt. Das Ergebnis ist ein Rahmenwerk, das gleichzeitig Verschwendung (Leans Domäne) und Streuung (Six Sigmas Domäne) bekämpft.

Wann DMAIC einsetzen (und wann nicht)

DMAIC ist ein Präzisionswerkzeug, kein universelles. Es auf das falsche Problem anzuwenden, verschwendet Monate.

Ein Kaizen-Event, ein fokussierter 3-bis-5-Tage-Workshop, ist oft schneller bei Problemen, bei denen das Team die Grundursache bereits vermutet und nur handeln muss. DMAIC verdient seinen Overhead, wenn das Problem chronisch ist, die Grundursache wirklich mehrdeutig ist und der Einsatz hoch genug ist, um sechs bis zwölf Wochen strukturierter Arbeit zu rechtfertigen.

Häufige Fehler, die DMAIC-Projekte zum Scheitern bringen

• Measure überspringen, um Zeit zu sparen. Teams, die von Define direkt zu Analyze auf Basis von Bauchgefühl springen, enden in Analyze ohne Baseline, ohne bestätigte Fehlerdefinition und ohne Möglichkeit, zu beweisen, dass ihre Lösung funktioniert hat. Measure ist die am häufigsten übersprungene Phase und der folgenreichste Sprung.
• Das Problem als Lösung definieren. Ein Projektauftrag, der sagt "wir müssen System X implementieren", definiert kein Problem, sondern wählt bereits eine Lösung aus. Define sollte die Lücke zwischen aktuellem und gewünschtem Leistungsniveau beschreiben, nicht die Antwort vorschreiben.
• Korrelation mit Grundursache verwechseln. Fishbones und 5 Whys liefern Kandidaten. Hypothesentests bestätigen sie. Teams, die zu Improve übergehen, basierend nur auf einem Fishbone-Brainstorming, stellen oft fest, dass die Lösung die Kennzahl nicht bewegt.
• Die Control-Phase zu gering besetzen. Control erhält am wenigsten Aufmerksamkeit und bekommt nach dem Projekt am meisten Schuld. Kein Kontrollplan bedeutet keinen Prozessverantwortlichen. Kein Prozessverantwortlicher bedeutet, dass die Gewinne innerhalb von sechs Monaten verfallen.
• Scope-Creep nach Unterzeichnung des Projektauftrags. DMAIC-Projekte erweitern sich, weil das Lösen eines Problems drei weitere aufdeckt. Halten Sie sich an den vereinbarten Umfang; öffnen Sie separate Projekte für die angrenzenden Themen.
• DMAIC ohne einen Black Belt oder erfahrenen Moderator durchführen. Die statistischen Werkzeuge in Analyze und Improve, Hypothesentests, DOE, SPC, erfordern Schulung. Teams ohne jemanden, der die Analyse korrekt durchführen kann, produzieren tendenziell Charts, die bestätigen, was das Team bereits glaubte.

Einen umfassenderen Blick auf Business Process Management und wo DMAIC in den Gesamtverbesserungs-Werkzeugkasten passt, finden Sie in diesem Artikel. Und für ein grundlegendes Verständnis der Prozessmanagement-Konzepte, bevor Sie ein DMAIC-Projekt starten, lohnt sich die Lektüre dieses Überblicks.

Häufig gestellte Fragen

Ist DMAIC dasselbe wie Six Sigma?

Nein, aber sie sind untrennbar. Six Sigma ist die übergeordnete Qualitätsphilosophie und Methodik, die auf 3,4 Fehler pro Million Möglichkeiten abzielt. DMAIC ist der spezifische Projektroadmap, der eingesetzt wird, um Six-Sigma-Verbesserungen in bestehenden Prozessen zu erzielen. Betrachten Sie Six Sigma als das Ziel und DMAIC als den Weg dorthin. Six Sigma umfasst auch DMADV für die Gestaltung neuer Prozesse und ein Belt-Zertifizierungssystem (White, Yellow, Green, Black, Master Black Belt), das definiert, wer DMAIC-Projekte auf verschiedenen Komplexitätsniveaus leiten kann.

Wie lange dauert ein DMAIC-Projekt?

Die meisten DMAIC-Projekte laufen zwischen 3 und 6 Monaten vom Unterzeichnen des Projektauftrags bis zur Control-Übergabe. Einfache, gut abgegrenzte Projekte in einem einzelnen Team können in 8 bis 10 Wochen abgeschlossen werden. Komplexe funktionsübergreifende Projekte, insbesondere solche, die DOE oder umfangreiche Datenerhebung erfordern, können 9 bis 12 Monate dauern. Die Measure- und Analyze-Phasen dauern in der Regel am längsten, weil die Datenerhebung Zeit braucht und Hypothesentests Stichprobengrößen benötigen, die statistisch bedeutsam genug sind. Das Überstürzen beider Phasen ist der häufigste Grund, warum DMAIC-Projekte ihre Gewinne nicht aufrechterhalten.

Kann DMAIC ohne Six-Sigma-Zertifizierung verwendet werden?

Ja, mit Einschränkungen. Die Define- und Control-Phasen sind für jeden zugänglich, der mit Projektmanagement vertraut ist. Die Measure-Phase erfordert Vertrautheit mit grundlegender Statistik und Messsystemanalyse. Analyze, insbesondere Hypothesentests und Regression, benötigt wirklich jemanden mit Green-Belt- oder Black-Belt-Ausbildung, um korrekt durchgeführt zu werden. Viele Teams führen DMAIC mit einem zertifizierten Moderator in der Führungsrolle und nicht zertifizierten Mitgliedern durch, die in Define und Improve beitragen. Die DMAIC-Struktur ohne die statistische Strenge in Analyze zu verwenden, ist besser als keine Struktur, aber das Risiko besteht darin, eine Grundursache zu bestätigen, die den Fehler nicht wirklich treibt.

Was ist der Unterschied zwischen DMAIC und DMADV?

Beide gehören zur Six-Sigma-Familie und teilen die ersten drei Phasen (Define, Measure, Analyze). Sie divergieren in Phase vier. DMIACs vierte Phase ist Improve: Sie reparieren einen bereits vorhandenen Prozess. DMADVs vierte Phase ist Design: Sie bauen etwas Neues. DMADV endet mit Verify statt Control, weil Sie ein neues Design gegen Anforderungen validieren und nicht Gewinne in einem etablierten Prozess aufrechterhalten. Verwenden Sie DMAIC, wenn ein Prozess kaputt, aber reparierbar ist. Verwenden Sie DMADV, wenn der Prozess von Grund auf neu erstellt werden muss oder wenn DMAIC bereits angewendet wurde und der Prozess immer noch die Anforderungen nicht erfüllen kann.

---

DMAIC ist nicht der schnellste Weg zur Lösung eines Prozessproblems. Aber bei chronischen, hochriskanten Fehlern, bei denen die Grundursache nicht offensichtlich ist, ist es der zuverlässigste. Definieren Sie, was kaputt ist, bevor Sie es messen. Messen Sie es, bevor Sie es analysieren. Analysieren Sie es, bevor Sie es verbessern. Steuern Sie es, damit es verbessert bleibt. Diese Abfolge ist langweilig, diszipliniert und sie funktioniert.

Für Teams, die ihre Qualitätsreise beginnen, ist die 5S-Methodik oft ein nützlicher Ausgangspunkt vor einem formalen DMAIC-Projekt: Sie stabilisiert die Arbeitsumgebung und macht die Messung zuverlässiger.