DMADV: Die 5 Phasen von Design for Six Sigma

DMADV fünfphasiger Ablauf Define Measure Analyze Design Verify

Turn this article into takeaways for your work.

Each assistant summarizes the article only for you and suggests best practices for your work.

DMADV (Define, Measure, Analyze, Design, Verify) ist das Six-Sigma-Framework, um etwas Neues von Grund auf mit nahezu perfekter Qualität zu schaffen, statt Bestehendes zu flicken. Während die meisten Verbesserungswerkzeuge bei einem kaputten Prozess ansetzen und versuchen, ihn zu reparieren, beginnt DMADV mit einem leeren Blatt und gestaltet Qualität von Anfang an ein. Teams setzen es ein, wenn sie eine neue Produktlinie starten, einen neuen Serviceprozess aufbauen oder einen Prozess ersetzen, der so grundlegend fehlerhaft ist, dass schrittweise Korrekturen nicht ausreichen.

Die Methode gehört zu einer breiteren Familie namens Design for Six Sigma (DFSS). Wenn Sie bereits DMAIC verwendet haben, wird Ihnen die Logik vertraut vorkommen, aber die Richtung ist anders. DMAIC verbessert. DMADV gestaltet.

Was ist DMADV?

DMADV ist eine strukturierte, datengetriebene Methodik zur Gestaltung neuer Prozesse und Produkte, die Kundenanforderungen auf Six-Sigma-Qualitätsniveau erfüllen. Der Name ist ein Akronym für seine fünf aufeinanderfolgenden Phasen: Define, Measure, Analyze, Design und Verify.

Die Grundidee ist einfach: Statt Fehler nach dem Launch zu entdecken und hektisch zu beheben, verstehen Sie genau, was Kunden brauchen, bevor Sie überhaupt etwas bauen. Dann gestalten Sie den Prozess oder das Produkt um diese Bedürfnisse herum, testen es rigoros und bringen es erst dann in die reale Welt.

Design for Six Sigma (DFSS) ist der Oberbegriff für eine Familie von Methodiken, zu der DMADV gehört. Es gibt weitere DFSS-Varianten (IDOV, DMADOV, ICOV), aber DMADV ist die am weitesten verbreitete, teils weil ihre fünfbuchstabige Struktur das vertraute DMAIC-Framework spiegelt, das die meisten Six-Sigma-Praktiker bereits kennen.

Wichtige Fakten

  • Six Sigma zielt auf eine Fehlerrate von nur 3,4 Fehlern pro Million Möglichkeiten (DPMO), was einer Genauigkeit von 99,99966 % entspricht. (Quelle: American Society for Quality)
  • Six Sigma wurde 1986 bei Motorola vom Ingenieur Bill Smith entwickelt und von Mikel Harry formal benannt. Es wurde zum Industriestandard, nachdem General Electric es Mitte der 1990er-Jahre unternehmensweit einführte. (Quelle: Motorola Solutions / ASQ)
  • Die DFSS-Familie (zu der DMADV gehört) unterscheidet sich von der DMAIC-Familie: DFSS kommt zum Einsatz, wenn ein Produkt oder Prozess noch nicht existiert oder das bestehende so weit vom Ziel entfernt ist, dass ein Neudesign der einzig gangbare Weg ist. (Quelle: iSixSigma)

DMADV vs. DMAIC

Das ist die Frage, die Teams am häufigsten stellen, und es lohnt sich, hier präzise zu sein. Beide sind Six-Sigma-Methodiken. Beide sind datengetrieben. Beide folgen einer fünfphasigen Struktur. Aber sie lösen grundlegend unterschiedliche Probleme.

Dimension DMADV DMAIC
Zweck Etwas Neues gestalten Etwas Bestehendes verbessern
Ausgangspunkt Leeres Blatt oder Konzept Ein funktionierender (aber fehlerhafter) Prozess
Wann einsetzen Neues Produkt, neuer Prozess oder radikales Neudesign Bestehender Prozess mit messbaren Fehlern
Kundenanforderungen Vor Designbeginn erhoben Oft bereits im Prozess verankert
Ergebnis Ein neu gebauter Prozess oder ein neues Produkt Eine optimierte Version des bestehenden Prozesses
Risikoprofil Höhere Vorabinvestition, geringere Nacharbeitskosten Geringere Vorabkosten, Risiko sinkender Erträge
Letzte Phase Verify (Abgleich mit Kundenspezifikationen) Control (den verbesserten Prozess erhalten)

Eine einfache Faustregel: Wenn Sie auf einen bestehenden, größtenteils funktionierenden Prozess blicken, nutzen Sie DMAIC. Wenn Sie auf ein Whiteboard blicken, nutzen Sie DMADV.

Es gibt auch einen nützlichen Zwischenfall. Manchmal existiert ein Prozess, ist aber so kaputt, dass keine noch so große Verbesserung ihn auf Six-Sigma-Qualität bringt. Dann wechseln Teams mitten im Projekt von DMAIC zu DMADV. Der Entscheidungspunkt kommt meist am Ende der Analyze-Phase eines DMAIC-Projekts, wenn die Daten zeigen, dass ein Neudesign der einzig realistische Weg ist.

Die 5 Phasen von DMADV

1. Define

Die Define-Phase legt Umfang, Zweck und Erfolgskriterien für das gesamte Projekt fest. Teams nutzen sie, um drei Fragen zu beantworten: Was bauen wir? Für wen? Und woran erkennen wir Erfolg?

Wichtige Aktivitäten in Define sind das Verfassen eines Projektauftrags (das einseitige Dokument, das Umfang, Zeitplan, Team und Business Case erfasst), die Identifikation von Stakeholdern und die grobe Kartierung der Critical-to-Quality (CTQ)-Anforderungen. Der CTQ-Baum ist hier ein besonders nützliches Werkzeug: Er verbindet breite Geschäftsziele (Kundenbeschwerden reduzieren) mit konkreten, messbaren Anforderungen (Reaktionszeit unter 4 Stunden, 99 % Erstkontaktlösung).

Eine gut durchgeführte Define-Phase spart später enorm viel Zeit. Wenn sich das Team nicht vor dem Design einigt, was "Erfolg" bedeutet, wird darüber gestritten, nachdem das Produkt gebaut ist.

Verwendete Werkzeuge: Projektauftrag, Stakeholder-Analyse, Voice-of-the-Customer (VOC)-Interviews, CTQ-Baum.

2. Measure

In Measure quantifiziert das Team genau, was Kunden brauchen. Ziel ist es, Kundensprache ("Ich möchte, dass es schnell geht") in messbare Spezifikationen zu übersetzen ("Bestellbearbeitungszeit von maximal 24 Stunden bei 99,7 % der Bestellungen").

Diese Phase umfasst strukturierte Kundenforschung: Umfragen, Interviews, Fokusgruppen und die Analyse von Beschwerdedaten. Teams nutzen oft Quality Function Deployment (QFD), auch House of Quality genannt, um Kundenanforderungen gegen potenzielle Designmerkmale abzubilden und nach Wichtigkeit zu ranken.

Die Measure-Phase legt auch die Ausgangsbasis fest: Wie sieht der aktuelle Zustand aus, falls etwas Vergleichbares existiert? Das gibt dem Team einen Referenzpunkt, wenn es später Designoptionen bewertet.

Verwendete Werkzeuge: Voice of the Customer (VOC), Quality Function Deployment (QFD), Benchmarking, Measurement System Analysis (MSA).

3. Analyze

Analyze ist die Phase, in der das Team den Lösungsraum erkundet, bevor es sich auf ein einzelnes Design festlegt. Statt direkt von Kundenanforderungen zu einem Design zu springen, prüfen Teams mehrere mögliche Ansätze, bewerten Kompromisse und wählen den besten Weg.

Diese Phase nutzt Techniken wie Design of Experiments (DOE), um zu modellieren, wie verschiedene Designvariablen zusammenwirken, sowie Risikoanalysewerkzeuge wie FMEA (Failure Mode and Effects Analysis), um zu identifizieren, wo ein Design scheitern könnte, bevor es gebaut wird. Teams benchmarken auch Wettbewerber und analoge Prozesse, um zu verstehen, wie "exzellent" in vergleichbaren Kontexten aussieht.

Die Analyze-Phase endet mit einer dokumentierten Entscheidung: Das ist das Designkonzept, mit dem wir weitermachen, und das sind die Daten, die diese Wahl stützen.

Verwendete Werkzeuge: FMEA, Design of Experiments (DOE), Benchmarking, Bewertung von Designkonzepten, Risikobewertung.

4. Design

Design ist die praktische Baurphase. Das Team nimmt das gewählte Konzept und arbeitet jedes Detail aus: Workflows, Systemarchitekturen, Personalmodelle, Schulungsanforderungen, technische Spezifikationen und Kontrollmechanismen.

Die zentrale Disziplin in Design ist frühes und häufiges Prototyping. Pilottests, Simulationen und kleine Testläufe lassen Teams Probleme erkennen, während Änderungen noch günstig sind. Ein neuer Kunden-Onboarding-Prozess könnte zum Beispiel mit einer einzelnen Kohorte von 20 Kunden getestet werden, bevor er auf Tausende ausgerollt wird.

Diese Phase umfasst auch detaillierte Dokumentation: Standardarbeitsanweisungen, Kontrollpläne, Schulungsmaterialien und die Messsysteme, die die Leistung nach dem Launch verfolgen.

Verwendete Werkzeuge: Detaillierte Prozesslandkarten, Value Stream Mapping, Simulation, Pilottests, Prototypenentwicklung, Gestaltung des Kontrollplans.

5. Verify

Verify ist das letzte Tor vor dem vollständigen Rollout. Das Team validiert, dass das neue Design tatsächlich die in Define und Measure festgelegten Kundenanforderungen erfüllt. Das ist kein einmaliger Test: Es ist eine systematische Validierung unter realistischen Bedingungen.

Verifikation umfasst typischerweise einen Pilotlaunch (ein kontrolliertes Rollout an eine reale, aber begrenzte Anzahl von Kunden oder Betriebseinheiten), statistische Validierung, dass der Prozess auf oder nahe dem Six-Sigma-Ziel läuft, und einen Übergangsplan für die Übergabe des Prozesses an das operative Team, das ihn im Tagesgeschäft betreiben wird.

Zeigt Verify Lücken zwischen der tatsächlichen Leistung des Designs und den Anforderungen, kehrt das Team zu Design (und manchmal zu Analyze) zurück, um sie zu beheben. Verify schließt erst ab, wenn die Daten bestätigen, dass das Design bereit ist.

Verwendete Werkzeuge: Pilotstudien, Fähigkeitsanalyse, Abnahmetests, Übergangsplanung, Übergabe des Kontrollplans.

Wann DMADV einsetzen

DMADV ist in vier Situationen die richtige Wahl:

1. Sie bauen etwas völlig Neues. Eine neue Produktlinie, ein neues Serviceangebot, ein neuer Markteintritt. Es gibt keinen bestehenden Prozess zu verbessern, weil der Prozess noch nicht existiert.

2. Der bestehende Prozess ist zu weit fortgeschritten kaputt. Manchmal zeigt eine DMAIC-Analyse, dass ein bestehender Prozess so strukturell fehlerhaft ist, dass eine Reparatur mehr kosten würde als ein Neudesign. Wenn die Daten das zeigen, ist der Wechsel zu DMADV der rationale Schritt.

3. Kundenanforderungen haben sich grundlegend verschoben. Ein Prozess, der für eine andere Kundenbasis, eine andere Technologieumgebung oder eine andere Skala gestaltet wurde, ist möglicherweise schlicht nicht mehr zu retten. Wenn sich Anforderungen um 40 % oder mehr geändert haben, schlägt Neudesign schrittweise Verbesserung oft.

4. Sie ersetzen einen Prozess, um neue regulatorische oder Qualitätsstandards zu erfüllen. Wenn neue Compliance-Anforderungen Fähigkeiten verlangen, die der bestehende Prozess nicht liefern kann, gibt Ihnen DMADV einen klaren Weg, die konforme Version von Grund auf zu bauen.

Wofür DMADV nicht geeignet ist: die Reparatur eines Prozesses, der größtenteils funktioniert, aber einen konkreten, identifizierbaren Fehler hat. Das ist DMAIC-Territorium, oder manchmal Zyklen der kontinuierlichen Verbesserung im Rahmen von Total Quality Management.

Vorteile von DMADV

Qualität eingebaut, nicht nachträglich geprüft. Traditionelle Produktentwicklung entdeckt Fehler nach dem Launch. DMADV entdeckt sie, bevor der erste Kunde das Produkt jemals sieht, weil Anforderungen validiert werden, bevor das Design beginnt.

Niedrigere Gesamtkosten. Die Kosten, einen Fehler zu beheben, eskalieren dramatisch im Verlauf des Entwicklungszyklus. Ein in der Analyze-Phase entdeckter Fehler kostet einen Bruchteil dessen, was ein nach vollständigem Rollout entdeckter Fehler kostet. Die Vorabinvestition von DMADV in Anforderungen und Prototyping zahlt sich fast immer aus.

Kundenausrichtung. Weil die Measure-Phase systematisch erfasst, was Kunden tatsächlich brauchen (nicht, was das Team annimmt), kommen von DMADV entwickelte Designs bei echten Nutzern in der Regel besser an.

Klare Verantwortlichkeit. Das strukturierte fünfphasige Gate-System sorgt dafür, dass jedes Teammitglied weiß, welche Entscheidungen in welche Phase gehören. Das reduziert die "Design by Committee"-Drift, die viele neue Produkteinführungen entgleisen lässt.

Skalierbar. DMADV funktioniert auf jeder Skala, von der Gestaltung eines einzelnen internen Workflows bis zum Launch einer globalen Produktlinie.

Häufige Fehler

In Design starten. Teams, die Define und Measure überspringen und direkt mit dem Design beginnen, raten, was Kunden brauchen. Ratereien erzeugen Nacharbeit.

Verify als Checkbox behandeln. Verify ist kein Abnahme-Meeting. Es ist statistische Validierung unter realen Bedingungen. Teams, die Verify hetzen, entdecken nach dem Launch oft, dass ihr Design im Test gut funktioniert, aber im großen Maßstab zusammenbricht.

DMADV mit DMAIC verwechseln. Ein DMAIC-Projekt für einen Prozess zu starten, der eigentlich neu gestaltet werden sollte, verschwendet Monate. Der Entscheidungspunkt liegt früh: Ist der bestehende Prozess unreparierbar kaputt, wechseln Sie das Framework, bevor Sie in Verbesserungsarbeit investieren.

Den Kontrollplan vernachlässigen. DMADV liefert ein Design, aber jemand muss dieses Design über Jahre betreiben. Eine schwache Übergabe an den Betrieb bedeutet, dass der neue Prozess zurück in die Fehler driftet, die er vermeiden sollte. Der Kontrollplan und die Schulungsmaterialien zählen ebenso viel wie das Design selbst.

FMEA in Analyze überspringen. Risikoanalyse in der Analyze-Phase ist der Ort, an dem Teams katastrophale Fehlermodi finden, bevor das Produkt gebaut wird. Teams, die FMEA überspringen oder oberflächlich behandeln, entdecken diese Fehlermodi stattdessen in der Produktion.

DMADV-Beispiel: Gestaltung eines neuen Onboarding-Prozesses für Kunden

Ein B2B-Softwareunternehmen hat durch eine große Partnerschaft die dreifache Menge an Neukunden gewonnen. Der bestehende Onboarding-Prozess wurde für 20 Neukunden pro Monat gebaut. Jetzt muss er 60 bewältigen, und die Kundenzufriedenheitswerte für kürzliche Neukunden sind bereits um 22 Punkte gesunken. Das Team stellt fest, dass der bestehende Prozess ohne grundlegendes Neudesign nicht skalierbar ist. Es startet ein DMADV-Projekt.

Phase Was das Team tat Ergebnis
Define Verfasste einen Projektauftrag mit Ziel: 90-Tage-Onboarding-Abschlussrate über 95 %, NPS von Neukunden über 50, vollständiger Rollout in 90 Tagen. Genehmigter Projektauftrag, CTQ-Anforderungen
Measure Interviewte 30 Neukunden und 10 Client-Success-Manager. Nutzte QFD, um Anforderungen zu ranken: Geschwindigkeit bis zum ersten Wert, klare Kommunikation der nächsten Schritte, einzelner Ansprechpartner. Gerankte VOC-Anforderungen, messbare Spezifikationen
Analyze Bewertete drei Designkonzepte: High-Touch White Glove, Self-Serve digital, Hybrid. Wandte FMEA auf jedes an. Hybrid schnitt bei Kundenanforderungen vs. Betriebskosten am besten ab. Gewähltes Designkonzept mit stützenden Daten
Design Baute den hybriden Onboarding-Workflow: automatisierte Willkommenssequenz, dedizierter Onboarding-Manager für Woche 1-4, Self-Serve-Wissensdatenbank für Woche 4-12. Verfasste SOPs und Schulungsleitfäden. Führte einen 30-Kunden-Pilot durch. Dokumentierter Prozess, Pilotergebnisse, Kontrollplan
Verify Vollständiger Pilot über 90 Kunden. 92 Tage durchschnittliche Abschlusszeit, 96 % Abschlussrate, NPS 54. Übergab den Prozess mit vollständigem Kontrollplan an das Client-Success-Team. Validierter Prozess, Übergabe abgeschlossen

Der neu gestaltete Prozess bewältigte das Volumen und erreichte jedes CTQ-Ziel. Entscheidend war, dass keiner der drei kritischen Fehlermodi, die während Analyze in der FMEA identifiziert wurden, im Pilot auftrat, weil das Design sie bereits adressiert hatte.

Häufig gestellte Fragen

Wofür steht DMADV?

DMADV steht für Define, Measure, Analyze, Design und Verify. Jedes Wort ist eine der fünf aufeinanderfolgenden Phasen der Methodik.

Ist DMADV Teil von Six Sigma oder Lean?

DMADV ist eine Six-Sigma-Methodik, speziell Teil der Design-for-Six-Sigma (DFSS)-Familie. Es ist von Lean getrennt, obwohl Teams gelegentlich Lean-Prinzipien mit DMADV kombinieren, wenn sie Prozesse gestalten. Es unterscheidet sich auch von der Lean-fokussierten DMAIC-Methodik, obwohl beide die Namen der ersten drei Phasen teilen.

Kann ein kleines Team DMADV nutzen, oder ist es nur für große Unternehmen?

DMADV skaliert gut nach unten. Ein Team von drei oder vier Personen kann ein verkürztes DMADV-Projekt für einen neuen internen Workflow in sechs bis acht Wochen durchführen. Die Strenge jeder Phase skaliert mit der Projektkomplexität. Was nicht nach unten skaliert, ist die Datendisziplin: Sie müssen weiterhin Kundenanforderungen messen und Ihr Design dagegen validieren, selbst bei einem kleinen Projekt.

Wie lange dauert ein DMADV-Projekt?

Zeitrahmen variieren je nach Umfang, aber die meisten DMADV-Projekte laufen drei bis neun Monate. Define und Measure zusammen dauern typischerweise vier bis acht Wochen. Analyze und Design nehmen den Großteil der Zeit ein (acht bis sechzehn Wochen kombiniert), und Verify läuft vier bis acht Wochen einschließlich des Pilots. Komplexe Produktdesigns oder großangelegte Prozessneugestaltungen können länger dauern.

Welche Zertifizierungen beziehen sich auf DMADV?

DMADV ist im Standard-Six-Sigma-Zertifizierungspfad abgedeckt. Die Green-Belt-Zertifizierung führt in das Framework ein; die Black-Belt-Zertifizierung schult Praktiker darin, DMADV-Projekte zu leiten. Manche Organisationen bieten spezifische DFSS-Zertifizierungen an. Die American Society for Quality (ASQ) und IASSC sind die anerkanntesten Zertifizierungsstellen.


Wenn Sie etwas gestalten, das noch nicht existiert, oder etwas ersetzen, das zu kaputt ist, um es zu reparieren, gibt Ihnen DMADV einen strukturierten Weg vom Kundenbedürfnis zum validierten Design. Die fünf Phasen erzwingen die richtigen Gespräche zur richtigen Zeit: Was brauchen Kunden tatsächlich (Define und Measure), was sind die besten Wege, diese Bedürfnisse zu erfüllen (Analyze), wie bauen wir es (Design), und funktioniert es tatsächlich (Verify).

Für Teams, die bereits DMAIC-Verbesserungszyklen betreiben, ist DMADV die natürliche Ergänzung: ein Framework, um Bestehendes zu verbessern, eines, um Nichtexistierendes zu gestalten. Die Praktiker, die diese Projekte leiten, erwerben ihre Qualifikationen über das Six-Sigma-Belt-System, und sie validieren ein fertiges Design gegen Qualitätsziele wie DPMO und Sigma-Level. Zusammen mit Werkzeugen wie Value Stream Mapping, FMEA und Total-Quality-Management-Praktiken fügt sich DMADV in ein vollständiges Qualitätsmanagementsystem ein, das darauf ausgerichtet ist, Dinge gleich beim ersten Mal richtig zu machen.

About the author

Tara Minh

Tara Minh

Senior Operations & Growth Strategist

Tara Minh is Senior Operations & Growth Strategist at Rework, helping B2B SaaS leaders scale without breaking their teams. With 8+ years in revenue operations and process optimization, Tara turns messy workflows into systems people actually follow. Readers get practical frameworks they can use to cut waste, align teams, and grow on purpose.