DMAIC

Ziel

DMAIC ist ein Projektvorgehen, das einen bestehenden Prozess verbessert, dessen Leistung unter der Erwartung seiner Kunden oder unter der gesetzten Norm bleibt. Es ordnet die Arbeit in fünf feste Phasen. Jede stellt eine Frage und endet mit einem Ergebnis, das ein Review freigibt.

Das Vorgehen klärt eine Frage: Welche Ursache, durch Daten verifiziert, erzeugt die Abweichung, und welche Änderung am Prozess beseitigt sie dauerhaft? Es schützt das Projekt vor der im Voraus beschlossenen Lösung. Niemand schlägt eine Änderung vor der Phase Improve vor, der vierten von fünf.

Das Projekt liefert einen geänderten Prozess und ein Dossier: den Projektauftrag, die Baseline, die verifizierten Ursachen, das Pilotergebnis und den Prozesslenkungsplan, den der Prozesseigner beim Abschluss übernimmt.

DMAIC weist ausserdem jedem Lean- und Six-Sigma-Werkzeug seine Phase zu: das Pareto-Diagramm der Phase Measure, das Ishikawa-Diagramm der Phase Analyse, die Regelkarte der Phase Control.

Einsatz

Wann einsetzen

• Bestehender Prozess unter dem erwarteten Niveau: eine Durchlaufzeit, eine Fehlerquote oder ein Kostenwert weicht von der Kundenerwartung oder der internen Norm ab.
• Wiederkehrendes Problem mit unbekannter Ursache: das Team hat schon mehrmals korrigiert, und die Abweichung kehrt zurück.
• Komplexes Problem oder hohes Risiko: mehrere Ursachen kommen in Frage, und eine falsch gezielte Korrektur kostet viel.
• Dienstleistungs- oder Verwaltungsprozess: Rechnungen, Dossiers und Anträge durchlaufen dasselbe Vorgehen wie die Produktion.
• Daten vorhanden oder erhebbar: Zeitstempel, Mengen und Fehlerzählungen liegen vor, oder die Phase Measure kann sie in wenigen Wochen erheben.
• Verbesserung, die dauerhaft zu sichern ist: die Phase Control übergibt dem Prozesseigner eine Kennzahl und eine Reaktionsregel.
• Sponsor, der ein Team in Teilzeit stellen kann: ein Teamprojekt dauert mehrere Monate.
• Geschäftsleitung, die ihre Annahmen widerlegt sehen will: die Phase Analyse verwirft manchmal die Ursache, die das Management für gesichert hielt.

Wann nicht einsetzen

• Fehler beim Kunden, der sofort eingedämmt werden muss: ein Projekt von mehreren Monaten kommt zu spät, die 8D-Methode wählen.
• Produkt oder Prozess, der ganz neu zu gestalten ist: es gibt noch nichts zu messen, DMADV wählen.
• Bekannte Ursache und günstige Korrektur: fünf Phasen kosten mehr, als sie einbringen, die Korrektur in einer Runde des PDCA-Zyklus erproben.

Beschreibung

Die ASQ, der amerikanische Fachverband für Qualität, hält fest, dass jede Phase auf der vorherigen aufbaut. Die Norm ISO 13053-1 beschreibt die gute Praxis jeder Phase eines Six-Sigma-Projekts, in Produktions-, Dienstleistungs- und Transaktionsprozessen.

Define: das Problem ohne die Lösung formulieren

Das Team schreibt den Projektauftrag. Er enthält die Problembeschreibung, das Ziel, den Umfang, die verfolgte Kennzahl, das Team und einen groben Zeitplan. Der Sponsor unterschreibt ihn.

Die Problembeschreibung nennt eine bezifferte, datierte und verortete Abweichung: "36% der Physiotherapie-Rechnungen werden nach mehr als 15 Arbeitstagen vergütet, bei 4'820 Rechnungen im ersten Quartal". Sie nennt weder Ursache noch Lösung. "Der Abteilung fehlt Personal" ist eine vermutete Ursache, "die Erfassung automatisieren" eine Lösung. Beide schliessen die Analyse ab, bevor sie beginnt.

Das Team bestimmt die Kunden des Prozesses, interne wie externe, und was sie erwarten. Die Voice of the Customer übersetzt diese Erwartungen in qualitätskritische Merkmale, kurz CTQ (Critical to Quality): eine Durchlaufzeit, eine Fehlerquote, eine Konformität. Die Projektkennzahl, die Six Sigma mit Y bezeichnet, misst eines davon. Ein SIPOC grenzt den Prozess ab, von seinen Lieferanten bis zu seinen Kunden.

Measure: die Baseline festlegen

Das Team bildet den Prozess so ab, wie er tatsächlich abläuft, mit seinen Schritten, Eingaben und Ausgaben. Die Karte hält fest, was die Leute tun. Das weicht oft von der schriftlichen Verfahrensanweisung ab.

Danach prüft das Team das Messsystem. Ein von Hand erfasstes Eingangsdatum, zwei Abteilungen, die ein Dossier je auf ihre Art zählen, ein Datenauszug, der sistierte Fälle verliert: Jeder dieser Mängel ergibt eine falsche Baseline. Eine Zahl, die das Team im Review nicht verteidigen kann, taugt nicht als Ausgangspunkt.

Zuletzt legt das Team die Baseline fest: den Wert von Y vor jeder Änderung, für einen benannten Zeitraum und eine benannte Grundgesamtheit. Die Prozessfähigkeit vergleicht diese Leistung mit der Grenze, die der Kunde toleriert. Das Pareto-Diagramm zeigt, wo sich die Fehler häufen. Die Baseline dient dem Piloten in Improve und der Überwachung in Control als Bezugswert.

Analyse: die Ursachen verifizieren

Die Phase Analyse sucht die Eingangsgrössen des Prozesses, die Y schwanken lassen. Six Sigma bezeichnet sie mit X. Das Team listet zuerst die möglichen Ursachen auf, mit einem Ishikawa-Diagramm, den fünf Warum oder einer FMEA. Danach prüft es jede ausgewählte Ursache an den Daten: Eine Ursache gilt als verifiziert, wenn Y deutlich verschieden ausfällt, je nachdem ob sie vorliegt oder nicht, und zwar über das hinaus, was der Zufall erklärt. Der Pilot in Improve beweist die Wirkung.

Ein Analyse-Review, das ein ausgefülltes Ishikawa-Diagramm ohne Daten vorlegt, legt eine Liste von Verdachtsmomenten vor. Das vollständige Vorgehen der Ursachenanalyse gehört in diese Phase.

Eine Hypothese, die die Daten widerlegen, scheidet aus dem Projekt aus, auch wenn die Geschäftsleitung sie für gesichert hielt. Damit stoppt das Team eine Investition, die nichts behoben hätte.

Improve: die Lösung erproben

Das Team entwickelt Lösungen, die an den verifizierten Ursachen ansetzen, mit Brainstorming oder Benchmarking. Es bewertet sie nach vorab festgelegten Kriterien: erwartete Wirkung auf Y, Kosten, Frist, Risiko. Wirken mehrere X zusammen, misst die statistische Versuchsplanung die Wirkung jedes Faktors und ihrer Kombinationen mit einer begrenzten Zahl von Versuchen. Das Team schätzt den finanziellen Gewinn und die erwartete Prozessfähigkeit. Es bestimmt ausserdem die kritischen X, die der Prozesslenkungsplan überwachen wird.

Die gewählte Lösung durchläuft einen Piloten: ein reduzierter Umfang, eine feste Dauer, dieselbe Definition von Y und dieselbe Art von Rechnungen wie die Baseline. Ein Vergleichsteam, in denselben Wochen ohne die Änderung gemessen, trennt die Wirkung der Lösung von einem saisonalen Effekt.

Eine Lösung, die im Arbeitsablauf verankert ist, hält besser als eine, die dem Gedächtnis der Leute überlassen bleibt. Eine Sperre in der Anwendung wiegt mehr als eine Schulung, eine Erinnerung per E-Mail oder eine interne Mitteilung.

Control: die Verbesserung sichern

Die Phase Control übergibt dem Prozesseigner, was er braucht, um die Verbesserung ohne das Projektteam zu sichern. Das englische Wort meint die Lenkung des Prozesses im Sinn der statistischen Prozesslenkung. Wer "Kontrolle" liest, denkt an eine Prüfung und missversteht die Phase.

Der Prozesslenkungsplan legt für Y und für jedes kritische X fest: die Messung, ihre Häufigkeit, die Person, die sie erhebt, die Grenze und die vorgesehene Reaktion, wenn die Grenze überschritten wird. Eine Regelkarte unterscheidet eine echte Verschiebung von der gewöhnlichen Streuung des Prozesses. Standardverfahren legen die neue Arbeitsweise fest. Eine Fehlerverhütung, Poka-Yoke genannt, macht den Fehler unmöglich oder sofort sichtbar.

Das Projekt endet, wenn der Prozesseigner den Plan übernommen hat und Y über den im Projektauftrag festgelegten Zeitraum auf dem neuen Niveau bleibt. Ein Projekt, das am Tag nach dem Piloten abgeschlossen wird, hat die Phase Control nicht durchlaufen.

Die Werkzeuge jeder Phase

Die Phasenreviews

Ein Phasenreview, im Six-Sigma-Vokabular Tollgate genannt, schliesst jede Phase ab. Sponsor, Projektleitung und Prozesseigner prüfen darin das Ergebnis anhand einer Liste von Austrittskriterien. Das Review entscheidet, ob das Projekt zur nächsten Phase übergeht, die laufende Phase ergänzt oder abbricht.

Die Reihenfolge der Phasen ergibt sich daraus, dass jede das Ergebnis der vorherigen braucht. Measure braucht das in Define definierte Y. Analyse prüft die Ursachen an der Baseline aus Measure. Improve zielt auf die in Analyse verifizierten Ursachen, und Control überwacht das verbesserte Y. Wird eine Phase übersprungen, fehlt der nächsten die Grundlage für ihre Arbeit.

Der Abbruch ist ein vollwertiger Ausgang. Ein Measure-Review kann eine kleinere Abweichung finden, als die Problembeschreibung angibt. Ein Analyse-Review kann eine Ursache aufdecken, die sich an einem Tag beheben lässt. In beiden Fällen spart der Abbruch Monate an Arbeit.

Die Norm ISO 13053-1 beschreibt auch die Rollen, das Fachwissen und die Ausbildung der Personen in diesen Projekten. Das Six-Sigma-Vokabular benennt sie nach Gürteln: Der Black Belt leitet Projekte in Vollzeit, der Green Belt leitet sie neben seiner Stelle. Der Sponsor, oft Champion genannt, vertritt das Projekt gegenüber der Geschäftsleitung.

Teamprojekt oder Kaizen-Event

In einem Teamprojekt leitet nach der ASQ eine Fachperson für Verbesserung ein Team in Teilzeit über mehrere Monate.

Das Kaizen-Event, das die ASQ ebenfalls beschreibt, durchläuft die fünf Phasen in etwa einer Woche. Die Fachperson bereitet Define und Measure vor der Woche vor. Das Team, für die Dauer des Events von seinen Aufgaben freigestellt, führt die drei übrigen Phasen durch und pilotiert die Änderungen vor Ort. Die vollständige Einführung folgt auf das Event, zusammen mit der Überwachung seiner Wirkungen. Dieser Takt passt zu einem eng gefassten Problem, dessen Daten schon vorliegen.

DMAIC und seine Nachbarn

Der Zyklus von Shewhart und Deming ist der Vorläufer des Vorgehens. Walter Shewhart legt in den 1920er-Jahren die Grundlagen der statistischen Prozesslenkung und veröffentlicht 1939 die Schleife, die Deming später als PDSA aufgreift. In den 1980er-Jahren wendet Bill Smith, Ingenieur bei Motorola, diese Ideen auf die Verringerung der Streuung an, unter dem Namen Six Sigma. Mikel Harry und Richard Schroeder erklären die Methode 1999 einem Publikum von Führungskräften.

Lea Monday nennt zwei Unterschiede zum PDSA-Zyklus, der Form von Deming. DMAIC misst und analysiert, bevor es eine Änderung vorschlägt, im vierten von fünf Schritten, während der Zyklus schon im zweiten eine Änderung erprobt. Ausserdem setzt DMAIC die Lenkung des Prozesses als letzten Schritt. Das sichert die Verbesserung auch dann, wenn niemand einen neuen Zyklus anstösst.

Die 8D-Methode antwortet auf einen Fehler, der einen Kunden getroffen hat. Sie schützt zuerst den Kunden mit Sofortmassnahmen zur Eindämmung, sucht dann die Ursache und verhindert, dass sie wiederkehrt. DMAIC verbessert einen Prozess, der keinen offenen Vorfall haben muss, im Takt eines Projekts. DMADV (Define, Measure, Analyse, Design, Verify) gestaltet ein neues Produkt oder einen neuen Prozess, während DMAIC das Bestehende verbessert.

Die QC Story stammt aus den japanischen Qualitätszirkeln. Sie führt ein Verbesserungsprojekt in festen Schritten und hält es in einem einzigen Dokument fest. Das Blatt der A3-Problemlösung erfüllt dieselbe Aufgabe auf einer einzigen Seite.

Die Fehler, an denen ein DMAIC-Projekt scheitert

Die Lösung im Projektauftrag ist ein häufiger Fehler. Ein Projekt mit dem Titel "Elektronische Dokumentenverwaltung einführen" hat vor Define entschieden. Measure und Analyse rechtfertigen dann einen bereits gefassten Entscheid. Das Define-Review weist jede Problembeschreibung zurück, die eine Ursache oder eine Lösung enthält.

Das Team kann auch in Define und Measure stecken bleiben. Es schreibt den Projektauftrag um und sucht eine perfekte Baseline. Das Projekt erreicht Improve nie. Abhilfe schafft der Zeitplan: Der Projektauftrag datiert jedes Review, und die Baseline muss nur die Abweichung vom Messrauschen trennen. Eine Phase lässt sich kürzen, aber nicht überspringen: Ein Team, das mit seinen vorhandenen Daten startet, ohne zu prüfen, wie sie erhoben wurden, analysiert Erfassungsfehler statt des Prozesses.

Die in der Sitzung abgestimmte Ursache ersetzt die verifizierte. Das Team füllt ein Ishikawa-Diagramm aus, behält die drei Ursachen mit den meisten Stimmen und geht zu Improve über. Das Projekt behebt dann, was das Team glaubte, und Y bewegt sich nicht.

Ein Pilot ohne Vergleichsteam beweist nichts. Im Sommer kann die Verspätung in allen Teams sinken, und der Pilot schreibt sich einen Rückgang zu, den die Saison bewirkt hat.

Eine Phase Control, die auf einen Schlussbericht schrumpft, bringt den Prozess innert weniger Monate auf sein ursprüngliches Niveau zurück. Ohne benannten Prozesseigner, ohne Grenze und ohne vorgesehene Reaktion sieht niemand die schleichende Verschlechterung, bevor sie die Verbesserung aufgezehrt hat.

Streuung, die zur Arbeit selbst gehört, widersteht dem Vorgehen. Monday hält das für das Gesundheitswesen fest: Jede Patientin, jeder Patient ist ein anderer Fall. Medizinische Leitlinien unterscheiden sich im Evidenzgrad und lassen Raum für das klinische Urteil. DMAIC gilt dann für den Teil des Prozesses, der sich standardisieren lässt, etwa die Übermittlung eines Befunds oder die Abgabe eines Medikaments. Der klinische Entscheid bleibt bei der Ärztin oder beim Arzt.

KI-Überlegungen

Ein Assistent liest den Projektauftrag gegen. Er meldet eine Problembeschreibung, die eine Ursache oder eine Lösung enthält, ein Ziel ohne Zahl und ohne Datum, einen Umfang, der nicht sagt, was er ausschliesst. Diese Durchsicht dauert wenige Minuten und hält die Lösung aus dem Projektauftrag heraus.

Er schreibt den Analysecode. Ein Modell erzeugt in R oder Python das Pareto-Diagramm, die Regelkarte, die Berechnung der Prozessfähigkeit oder den Test, der den Piloten mit der Baseline vergleicht. Die Analystin prüft, ob der Code die richtigen Spalten liest und ob der gewählte Test zu den Daten passt. Ein ungeeigneter Test erzeugt eine Ursache, die nur auf dem Papier verifiziert ist.

Er schlägt mögliche Ursachen für das Ishikawa-Diagramm vor. Die Liste erweitert das Spektrum der Ursachen, die das Team prüft, doch das Modell kennt den tatsächlichen Prozess nicht: Jede Ursache bleibt eine Hypothese, bis die Daten sie bestätigen.

Ein Modell kennt die Baseline nicht. Nach einem Prozess gefragt, den es nie gesehen hat, liefert es plausible Zahlen. Eine erfundene Baseline verfälscht den Piloten und danach den Prozesslenkungsplan. Gesundheitsrechnungen enthalten besonders schützenswerte Personendaten im Sinne von Art. 5 Bst. c DSG. Sie gehen nur an einen externen KI-Dienst, wenn ein Vertrag über die Auftragsbearbeitung nach Art. 9 DSG vorliegt, den die Krankenkasse abschliesst.

Beispiele

Jedes Review eines DMAIC-Projekts gibt dem nächsten eine Zahl weiter. Das Register folgt einem Projekt einer Westschweizer Krankenkasse zur Vergütungsdauer von Physiotherapie-Rechnungen.

Die Zeile Analyse trägt den Entscheid, der am meisten eingebracht hat. Die Geschäftsleitung wollte das Prüfteam aufstocken. Die Analyse zeigt, dass der Personalbestand die Verspätung nicht erklärte: Zusätzliches Personal hätte die Quote bei 34% belassen.

Visualisierungen

Die Roadmap ist ein Diagramm. Ihre Information ist eine Abfolge, in der ein Review jeden Übergang bewacht, und die Grafik zeigt auf einen Blick, dass die erste Änderung in der vierten Phase kommt. Die Werkzeuge je Phase, die Kreuztabelle der Verspätungen nach Verordnung, der Vergleich mit den benachbarten Vorgehen und das Register der Reviews bestehen aus Zeilen und Spalten, also aus Tabellen.

Aufwand

Werkzeuge

Eine Vorlage für den Projektauftrag und eine Liste von Austrittskriterien je Review, in einem geteilten Dokument, genügen, um die Struktur des Projekts zu halten. Eine Tabellenkalkulation erzeugt das Pareto-Diagramm und die deskriptive Statistik der Baseline.

Statistiksoftware wird ab der Messsystemanalyse nötig, für die Berechnung der Prozessfähigkeit, die Regelkarten und die Versuchsplanung. Minitab und JMP sind die Referenzen des Fachs. R und Python leisten dasselbe, mit Code, den das Team gegenliest.

Die Prozesskarte entsteht im Workshop am Whiteboard und dann in einem Werkzeug zur Prozessmodellierung, wenn sie Bestand haben soll. Eine Tafel neben dem Prozess zeigt die Kennzahl der Phase Control, vor den Augen der Personen, die sie bewegen.

Quellen

• American Society for Quality, "DMAIC Process: Define, Measure, Analyze, Improve, Control": die Definition des Vorgehens, Inhalt und Werkzeuge jeder Phase, die Abgrenzung zu DMADV und die zwei Durchführungsformen, als Teamprojekt oder als Kaizen-Event.
• ISO 13053-1:2011, Quantitative methods in process improvement, Six Sigma, Part 1: DMAIC methodology: die gute Praxis jeder Phase, die Projektführung, Rollen und Ausbildung der Beteiligten, die Anwendung auf Dienstleistungs- und Transaktionsprozesse.
• Monday, Lea M. (2022), "Define, Measure, Analyze, Improve, Control (DMAIC) Methodology as a Roadmap in Quality Improvement", Global Journal on Quality and Safety in Healthcare, Bd. 5, Nr. 2: die Schritte und ihre Werkzeuge, der Vergleich mit dem PDSA-Zyklus, der Ursprung bei Motorola und die Grenzen des Vorgehens im Gesundheitswesen.
• Harry, Mikel und Schroeder, Richard (1999), Six Sigma: The Breakthrough Management Strategy Revolutionizing the World's Top Corporations, Currency: die Einführung in die Methode Six Sigma für Führungskräfte.