Six Sigma entstand in den 1980er-Jahren in der Industrie, um Streuung in Prozessen systematisch zu senken. Sein Kern ist ein fester Ablauf aus fünf Phasen. Er zwingt dazu, ein Problem erst zu verstehen und zu messen, bevor man es löst, und die Lösung abzusichern, bevor man weiterzieht.
Jede Phase hat ihre Werkzeuge. Jede hat aber auch eine typische Falle, die mit Methodik wenig zu tun hat und viel mit Menschen. Beides steht hier nebeneinander, dazu ein Verweis auf die Fallstudie, in der die Phasen an einer simulierten Drehmaschine durchgespielt werden.
DefineWas genau ist das Problem – und woran merken wir, dass es gelöst ist?
Am Anfang steht keine Lösung, sondern eine Beschreibung: Was läuft falsch, wie oft, mit welchen Folgen? Daraus wird ein Ziel, das sich messen lässt. Die Stimme des Kunden – intern oder extern – wird dabei in kritische Qualitätsmerkmale übersetzt, die man später prüfen kann.
Ebenso wichtig ist die Grenze des Projekts: Welcher Prozess gehört dazu, welcher nicht? Ein zu großer Rahmen lähmt, ein zu kleiner verfehlt die eigentliche Ursache.
In der FallstudieMontag – die Lehre meldet 300 von 300 Teilen in Ordnung, das eigentliche Problem bleibt unsichtbar.
MeasureWie groß ist das Problem wirklich – und können wir es überhaupt messen?
Bevor ein Prozess gemessen wird, wird das Messsystem geprüft. Erzeugt es selbst einen großen Teil der Streuung, misst man vor allem sich selbst. Erst danach lohnt es sich, die Ausgangslage zu erheben: Lage und Streuung des Prozesses, seine Fähigkeit und seine Stabilität über die Zeit.
Ein Datenerhebungsplan legt fest, was, wie oft und von wem gemessen wird. Das klingt bürokratisch, verhindert aber den häufigsten Fehler: Daten, die nicht zur Frage passen.
In der FallstudieDienstag – die Regelkarte zeigt, wann eingegriffen werden muss, und der Prüfbericht entsteht aus der Messreihe selbst.
AnalyzeWelche Ursachen sind belegt – und welche nur vermutet?
Zuerst werden mögliche Ursachen gesammelt, breit und ohne Wertung. Dann wird jede Vermutung zu einer prüfbaren Hypothese und mit Daten getestet. Ein Hypothesentest sagt dabei nicht nur, ob ein Unterschied besteht, sondern auch, wie groß das Risiko eines Irrtums ist.
Das Ergebnis ist eine kurze Liste belegter Ursachen. Sie ist oft überraschend – und genau deshalb wertvoll.
In der FallstudieMittwoch – Werners Thesen werden getestet: eine bestätigt, eine nicht belegt.
ImproveWelche Änderung wirkt nachweislich – und hält sie im Alltag?
Lösungen werden entwickelt, bewertet und erprobt. Hängen mehrere Einstellungen zusammen, findet eine Versuchsplanung mit wenigen, planvoll gewählten Läufen heraus, was wirklich wirkt – auch dort, wo sich zwei Einstellungen gegenseitig beeinflussen.
Vor der Einführung werden Risiken der Änderung bewertet, danach wird sie im kleinen Rahmen erprobt. Erst wenn der Pilot überzeugt, wird die neue Arbeitsweise zur Regel.
In der FallstudieMittwoch – der Versuchsplan widerlegt die Vermutung zur Schnittgeschwindigkeit, und die neue SOP-Revision ist in einer Stunde fertig.
ControlWie bleibt die Verbesserung, wenn das Projekt vorbei ist?
Die neue Arbeitsweise wird abgesichert: in einem Kontrollplan, in aktualisierten Arbeitsanweisungen, mit einer Regelkarte, die Abweichungen früh zeigt. Die Menschen, die damit arbeiten, werden geschult – und es wird geprüft, ob die Schulung gewirkt hat.
Zum Schluss geht der Prozess an einen Prozesseigner über, der ihn im Alltag verantwortet. Ohne diese Übergabe endet die Verbesserung mit dem Projekt.
In der FallstudieDonnerstag – 40 Wochen Wareneingangsberichte zeigen eine schleichende Verschlechterung, lange bevor sie auffällt.
Kurz gesagt
- Define: Problem und Ziel beschreiben, die Lösung offenlassen.
- Measure: erst das Messsystem prüfen, dann den Prozess.
- Analyze: Vermutungen als Hypothesen testen, nicht nach Rang entscheiden.
- Improve: planvoll erproben, schrittweise einführen.
- Control: übergeben, messen, schulen – und Wissen festhalten.