DMAIC - Teil 1: Verstehen

Überblick

DMAIC bzw. DMAIC(R) ist die praktische Umsetzung von Six Sigma. Dabei durchläuft man fünf aufeinanderfolgende Phasen mit dem allgemeinen Ziel ein Problem zu lösen und die Lösung sicherzustellen. 
 

Wir haben ein Problem!

Als Problem bezeichnet man dabei die bedeutsame Abweichung (gap) der Kundenanforderung gegenüber dem dafür spezifizierten Prozess. 
Basis der Problemlösung sind ausreichend belastbare Daten: Daten, die der Kunde uns mitteilt (Voice Of the Customer, VOC), Daten, die der Prozess uns mitteilt (Voice Of the Process, VOP) und eventuell auch Daten die auf Vorschriften des Gesetzgebers beruhen (Voice Of Regulatory, VOR). Kurz und knapp: DMAIC(R) ist eine "Datenbasierte Problemlösungsstrategie". Noch Fragen? Klar, jede Menge!
"Wenn DMAIC(R) die praktische Umsetzung von Six Sigma ist, was ist Six Sigma dann eigentlich, also theoretisch? Und ab wann ist ein Problem komplex genug um DMAIC(R) anwenden zu können? Welche Eigenschaften muss das Problem haben? Und was teilt uns ein Kunde oder ein Prozess in welcher Form mit? Und überhaupt, warum steht das R in Klammern, und...". STOP! Das sind alles gute Fragen, aber eins nach dem andern, bitte!

Six Sigma bezeichnet dreierlei:

• Eine Managementphilosophie,
  zur strukturierten phasenorientierten Qualitätssicherung und Steuerung von Geschäftsprozessen mit dem Ziel die Kundenzufriedenheit vollständig und profitabel zu erfüllen. Dabei sollen fundierte wissenschaftliche Werkzeuge aus der Statistik zum Einsatz kommen. Die praktische Umsetzung dessen ist der vom damaligen Motorola Mitarbeiter Dr. Mikel Harry 1986 veröffentlichte Regelkreis DMAIC
• Ein Maß für die Prozessfähigkeit (Prozess-Sigma, Sigma Level)
  das ist die Fähigkeit eines Prozesses die Kundenanforderung in den spezifizierten Grenzen zu erfüllen. Dahinter steckt das statistische Qualitätsziel möglichst wenige Fehler, idealerweise 0 Fehler, zuzulassen (6𝜎 entspricht rechnerisch einer Fehlerwahrscheinlichkeit von 0.000000024%. Real driften Prozesse allerdings, über längere Zeit hinweg, im Mittel um 1.5𝜎 vom Idealzustand fort, so dass man langfristig die höhere Fehlerrate von 4.5𝜎, entsprechend 0.000034%, erwarten muss. Dass entspricht 3.4 Fehler pro Million Fehlermöglichkeiten)
• Die Standardabweichung (𝜎)
  Sie bildet nach Johann Carl Friedrich Gauß (1777-1855) die mathematische Grundlagen für Six Sigma und beschreibt den mittleren Abstand der Datenpunkte von ihrem Mittelwert. In der Wahrscheinlichkeitsrechnung, der mathematischen Kunst des Vermutens (Stochastik), lassen sich damit die verrücktesten Dinge mehr oder weniger vertrauensvoll berechnen: die Fägigkeit eines Prozesses mit Hilfe des Sigma Level (s.o.), die Annahme oder Ablehnung einer Vermutungen (Hypothese) oder den Effekt, den mehrere Eingangsparameter bei gleichzeitiger Veränderung, auf das Ausgangsverhalten eines Systems haben (Design of Experiments, DoE: Wie muss ich meine Eingangsparameter justieren, damit das System optimal arbeitet?).

Der Begriff Six Sigma stammt übrigens von Bill Smith, ebenso wie Dr. Mikel Harry (s.o.), damals ein Mitarbeiter von Motorola.

Wann ist ein Problem komplex oder vielschichtig genug und welche Eigenschaften  muss es haben?

Ich denke, wenn man aus ihnen Erkenntnisse gewinnen, also etwas wesentliches daraus lernen und verbessern kann. Das ist der Fall, wenn:

• die Lösung für das Problem strategische Bedeutung besitzt, also wichtig ist und finanziell groß (das ist natürlich abhängig vom Unternehmen. Aber es gibt Anhaltspunkte, wie etwa das Verbesserungspotenzial OTOQD >= 20% und Einsparungen von wenigstens 150.000 €/Jahr, siehe Lean vs. Six Sigma)
• eine Lösung nicht 'auf der Hand' liegt, nicht offensichtlich ist, für uns etwas Neues darstellt (d.h. wenn wir unsere Wohlfühlecke verlassen und in unbekanntes Terrain vorstoßen, was immer auch mit Risiken einhergeht. Mit anderen Worten: eine Lösung kann auch scheitern, beispielsweise zu teuer sein! Dann muss eine andere Lösung gesucht und gefunden werden!)
• Wenn wir zur Problembearbeitung mehrere Personen, ein Team, benötigen und das Ganze als Projekt organisatorisch, zeitlich, inhaltlich und finanziell strukturiert werden muss 

Das Problem darf aber auch nicht akut schädlich sein, so dass Leib und Leben gefährdet sind oder enorme Schäden jedweder Art bevorstehen. Dafür wäre DMAIC(R) nicht die erste Wahl. Hier wären Modelle die schnelle Schadensbegrenzung (fire fighting) berücksichtigen zu bevorzugen, etwa das 8D Stufenmodell. 

Was sind belastbare Daten? 

Belastbar sind Daten dann, wenn sie nachweisbare Ereignisse oder Handlungen (Fakten) darstellen die unsere Welt, unsere Prozesse, unsere Probleme in ihrer spezifischen Eingenart und Form (repräsentativ) beschreiben.

Was teilt uns ein Kunde oder ein Prozess in welcher Form mit?

Das hängt natürlich ab vom Kunden und kann verbal in Form von "diese blöde Software funktioniert nicht", bis hin zu: "Wenn ich die Installationsroutine ihrer Software XY, Release 3.8.4, Built 1845, gemäß Installationshandbuch V1.1, S. 27, starte, erhalte ich, reproduzierbar, den Fehlercode -23. Das entsprechende LOG-File mit den Systemdaten finden Sie im Anhang". Auf alle Fälle müssen wir die Sicht des Kunden respektieren und seine Wahrnehmung und Aussagen wie etwa die o.g. verbale unspezifische Beschwerde, in eine spezifische nachprüfbare Form bringen die letztendlich mess- oder zählbar ist. Dafür gibt es Werkzeuge (z.B. den Critical To Quality oder CTQ Tree).

Und überhaupt, warum steht das R in Klammern?

Das R steht für Reinforce und bedeutet verfestigen, stützen. Dahinter verbergen sich einige hilfreiche Aktivitäten die nach der Projektübergabe an die Fachabteilungen (also nach der kleinen Feier :-) stattfinden und helfen, den Projekterfolg sicherzustellen. R ist somit den DMAIC-Phasen nachgelagert und nicht Teil des eigentlichen Projektes. Diese Maßnahmen sind wichtig, um nicht im Nachhinein in 'alte Gewohnheiten' zurückzufallen - desshalb R und in Klammern.

DMAIC

Wahrscheinlich sind mit der Beantwortung der Fragen jetzt neue Fragen aufgetaucht? Nein? Gut, dann weiter: Das Vorgehensmodell DMAIC(R) besteht aus den Projektphasen DEFINE, MEASURE, ANALYZE, IMPROVE, CONTROL und (in Klammern) den unsterstützenden Stabilisierungsmaßnahmen REINFORCE. 

DMAIC(R) Phasen

Will man ein Problem untersuchen, dann muss man verstehen was die Anforderungen sind und was der aktuelle Stand der Dinge zur Erfüllung dieser Anforderungen ist. Dazu dienen die ersten beiden Phasen DEFINE und MEASURE. Wenn wir verstanden haben können wir die Abweichung bestimmen und Maßnahmen zur Schließung der Lücke kreieren. Dazu dienen die Phasen ANALYZE und IMPROVE. Kennen wir die Lösung unseres Problems, dann können wir ihre Implementierung und Sicherstellung vornehmen. Dazu dienen CONTROL und REINFORCE. 

Kurz gesagt: wir wollen

1. Verstehen
2. Analysieren
3. Implementieren

Praktisch stellen sich die Phasen wie folgt dar:

DEFINE

Beschreibe das Problem und mach ein Projekt daraus!

 

DEFINE: Phasen und Werkzeuge (Auswahl)

In der DEFINE-Phase beschreiben wir das Problem. Seine strategischen, zeitlichen und finanziellen Auswirkungen und Risiken formulieren wir am besten als Busines Case (Geschäftsszenario), so dass wir unseren Vorgesetzten und die Geschäftsleitung informieren und von der Notwendigkeit einer Lösung (die wir noch nicht kennen!) überzeugen können. Ist uns das gelungen und haben wir eine Aussage wie: "Gute Idee, dann machen Sie mal! Herr Sowieso wir Sie unterstützen!", erstellen wir in Absprache mit Herrn Sowieso (er ist ab jetzt unser Sponsor) und 'der Linie' (den jeweiligen Line-Managern), ein operatives Kern-Team von 3 bis 7 geeigneten Personen; sie decken idealerweise alle betroffenen Bereiche gut ab (End-to-End Sicht) und: sie wollen mitmachen. 

Als nächstes benötigen wir einen ganz groben Prozessplan (als Ergebnis eines Workshop (SIPOC) und/oder der Analyse vor Ort (Gemba)), alles sequenziell, fünf bis sieben Stufen, nicht mehr. Er soll uns einen ersten Überblick über den Prozess geben und die zugehörigen internen und externen Kunden darstellen. Dann sammeln und gruppieren wir die kritischen Kundenanforderungen, verstehen was damit gemeint ist (oder fragen nach!) und formen sie um in messbare Kriterien. Diese Kriterien bilden die für die Qualität, das Geschäft und die Gesetzesvorgaben kritischen Kennzahlen, die Key Output Characteristics. Wir betreiben Change Management und finden heraus, welche Schlüsselpersonen (Stakeholder) und Interessensgruppen von einer möglichen Änderung betroffen sind und schätzen ab, welche Personen dem Projekt wie gegenüberstehen: eher zugeneigt, neutral oder abgeneigt (letztere könnten unserem Projekt u.U. richtig schaden! Das wollen wir nicht!). Mit all diesen Informationen und Daten lässt sich nun ein grobes Projekt, mitsamt Kommunikationsplan, (wer muss wann, wie, worüber informiert werden) aufsetzen. 

Wir erstellen den Projektauftrag (Project Charter) und lassen uns Projektinhalt, Ressourcen, Meilensteine und Budget vom Sponsor prüfen (Gate Review) und authorisieren. Herr Sowieso hat unterschrieben? Prima! Der Projektleiter ebenfalls? Super! DEFINE beendet, jetzt kann's los geh'n (GO).

MEASURE

Slogan: Bestimme den IST-Zustand des Prozesses! 

MEASURE: Phasen und Werkzeuge (Auswahl)

Wir bestimmen den aktuellen Prozesszustand, den IST-Zustand, in Form einer Prozess-Landkarte (map). Dafür sind funktionsübergreifende Flow-Charts, sogenannte Swim Lane Charts oder Wertstromkarten gut geeignet. Und: wir benötigen Mitarbeiter, die den Prozess richtig gut kennen und im Projekt helfen wollen (Wichtig: Teamwork). Zusammen bereiten wir die Messungen der Key Output Charakteristics vor und definieren die Leistungskennzahlen des IST-Prozesses, die Key Performance Indicators, KPI. Die Messungen und Zählungen müssen zuverlässig, nachvollziehbar und glaubwürdig sein und sie sollen den Prozess so repräsentieren, dass man anhand der gewonnenen Daten später signifikante (wesentliche) Aussagen treffen kann. Wie bekommt man solche Daten? Die Antwort: man nutzt die Erkenntnisse statistischer Methoden, erstellt einen Plan warum, was, wer, wann, wo und wie bestimmen (messen, zählen, benennen) soll und sammelt die Rohdaten (so genau wie möglich). Wie sehen die Daten aus? Plausibel? Oder eher unglaubwürdig? Ist unser Messsystem in Ordnung? Ist die Messgenauigkeit unserer Messinstrumente ausreichend hoch (rule of ten)? Hat das Personal, dass die Messungen durchgeführt hat, korrekt gearbeitet? Keine Datenwerte gerundet? Oder aus Zeitnot heraus 'sicherheitshalber ergänzt'? Wäre das möglich? Um solche Erhebungsfehler abschätzen zu können, die Güte der Daten sicherzustellen, nutzt man die MSA, die Messsystemanalyse. Aber obacht: jede Analyse kostet zusätzlich Zeit und Geld (wenn man das nicht vorsichtshalber schon als Risiko eingeplant hat!).
  
Mit dem IST-Prozess in Form einer Prozesslandschaft und den zugrundeliegenden Daten lässt sich jetzt die sogenannte Baseline des IST-Prozesses bestimmen, unsere Basis für spätere Vergleiche. Wie sieht der IST-Prozess aus? Ist er stabil, d.h. haben wir ihn unter Kontrolle (in control) oder zeigen die zeitlich aufeinander folgenden Daten im Run-Chart, dass etwas aus 'dem Ruder' zu laufen droht? Entsprechen die Daten inetwa dem, was der Kunde fordert, wo weichen sie ab, wie sind sie verteilt? Normal? Nicht normal? Gibt es einen Datenmittelwert, einen Median, wie groß ist die Standardabweichung, wie fähig ist unser IST-Prozess, die Kundenanforderungen zu erfüllen, wieviele Fehler erwarten wir? Zu alledem existieren mathematische Methoden die man praktisch mit geeigneter Software schnell und zuverlässig nutzen kann: Microsoft EXCEL ist dazu, bis zu einem gewissen Grad, gut geeignet (wenn man in den EXCEL Optionen die Add-Ins 'Analyse-Funktionen' aktiviert hat) oder man schafft sich spezielle Statistik-Software an - Open Source (gut und günstig, aber gelegentlich eingeschränkt) oder kommerziell (perfekt und manchmal teuer, aber an die Thematik angepasst) wie etwa Minitab.

Nun wissen wir wie unser IST-Prozess funktioniert und was er leistet bzw. nicht leistet - die Abweichung. Die Erkenntnisse, die wir daraus gewinnen, könnten aber auch bedeuten, unser ursprüngliches Problem und die betroffenen Personen und Personengruppen passen irgendwie nicht mehr so recht zusammen oder müssen erweitert (oder reduziert) werden. Wir überarbeiten unsere ursprüngliche Problemdefinition entsprechend und modifizieren unsere Change Managementaktivitäten. Bei alledem vergessen wir auch nicht Herrn Sowieso immer auf dem Laufenden zu halten, unseren Sponsor.

Die MEASURE-Phase nähert sich dem Ende und wir haben unseren IST-Prozess, so wie er sich im Bezug auf die Kundenanforderungen darstellt, verstanden. Die Abweichungen (Gaps) sind nun plausibel offengelegt und wir haben großes Interesse daran festzustellen, was denn die grundsätzlichen Ursachen, die Root-Causes, dafür sind?

Es bleibt spannend...

Bis bald...
Thomas