Lean Six Sigma und DMAIC: Lean-Prozessverbesserung mit Daten

Lean-Prozessverbesserung zeigt Ihnen systematisch, wo Abläufe Zeit oder Qualität verlieren und wie Sie Änderungen anhand von Daten überprüfen. Dieser Leitfaden erläutert, wie Lean Six Sigma und DMAIC dabei helfen, welche Daten die einzelnen Phasen erfordern und wie sich der Zyklus auf einen Order-to-Cash-Prozess anwenden lässt. Im Mittelpunkt stehen eine nachvollziehbare Ausgangsbasis, eine Analyse, die Annahmen überprüft, und Kontrollen, die Verbesserungen dauerhaft sichern.

Lean-Prozessverbesserung besteht aus mehr als einer Sammlung von Werkzeugen. DMAIC bietet eine praktische Struktur, um einen Prozess zu untersuchen und über Änderungen zu entscheiden.

Was Lean Six Sigma ist und was nicht

Lean, Six Sigma und Lean Six Sigma hängen zusammen, setzen aber an unterschiedlichen Problemen an.

Lean zielt darauf ab, nicht wertschöpfende Arbeit wie Wartezeiten, unnötige Übergaben und Nacharbeit zu vermeiden. Six Sigma soll Abweichungen und Fehler verringern. Lean Six Sigma verbindet beide Ziele in einem strukturierten Verbesserungsprogramm.

Lean-Mapping, einschließlich Value Stream Mapping, hilft Ihnen, darzustellen, wie die Arbeit ablaufen sollte. Prozessdaten zeigen zusätzlich, wie Cases tatsächlich durch die Systeme laufen. Zusammen bieten Prozessmodell und Daten Ihrem Team eine Grundlage, um zu besprechen, wo der Prozess von den Erwartungen abweicht.

Es ist außerdem hilfreich, klar zu benennen, was Lean Six Sigma nicht ist:

• Kein Zertifizierungsprogramm. Belts sind ein Schulungsformat. Ein Zertifikat ersetzt weder eine gemessene Ausgangsbasis noch ein konkretes Verbesserungsprojekt.
• Kein Ersatz für Prozesswissen. DMAIC strukturiert die Untersuchung. Ihr Team muss die Arbeit und ihre Rahmenbedingungen trotzdem verstehen.
• Kein einmaliges Projekt. Die Phase Steuerung ermöglicht es Ihnen, den Prozess weiter zu beobachten, nachdem das Projektteam seine Arbeit abgeschlossen hat.
• Nicht auf die Fertigung beschränkt. Auch Büroprozesse umfassen Wartezeiten, Nacharbeit, Übergaben und unnötige Schritte.

Warum DMAIC Daten statt Meinungen braucht

DMAIC umfasst eine Messphase, denn Sie benötigen eine Ausgangsbasis, bevor Sie beurteilen können, ob sich ein Prozess verbessert hat. Ohne sie kann die Analyse zu einer Diskussion darüber werden, wessen Erinnerung stimmt.

Manuelle Beobachtungen und Stichproben helfen dabei, einen Prozess zu verstehen. Sie decken jedoch nur die Cases und Schritte ab, die Sie beobachten. In Büroprozessen kann sich die Arbeit über ein ERP-, CRM- oder Ticketsystem sowie Tabellen erstrecken. Keine einzelne beobachtende Person sieht jeden Case von Anfang bis Ende.

Wenn Systeme eine Case-Referenz, eine Aktivität und einen Timestamp erfassen, können Sie anhand dieser Ereignisdaten rekonstruieren, wie Cases den Prozess durchlaufen haben. Statt jede Beobachtung manuell zu erfassen, prüfen Sie die Daten und interpretieren die Ergebnisse. Process Mining bietet eine Möglichkeit, diese Aufzeichnungen über den gesamten Prozess hinweg auszuwerten.

Der Vergleich zwischen dokumentierter und tatsächlicher Arbeit kann zwei Arten von Abweichungen aufzeigen:

• Im Diagramm dargestellte Schritte, die in der Praxis nicht mehr stattfinden. Eine Kontrolle wird möglicherweise nicht mehr durchgeführt oder eine Freigabe ist nicht mehr erforderlich.
• Schritte, die in der Praxis stattfinden, aber im Diagramm fehlen. Ein Workaround kann zur Routine geworden sein, ohne dass Zuständigkeit oder Überprüfung klar geregelt sind.

Die fünf DMAIC-Phasen der Lean-Prozessverbesserung

DMAIC umfasst fünf Standardphasen: Definieren, Messen, Analysieren, Verbessern und Steuern. Jede Phase beantwortet eine andere Frage und liefert ein eigenes Ergebnis. Mit diesen Schritten der Lean-Prozessverbesserung gelangen Sie von einem klar definierten Problem zu einer überwachten Veränderung.

Definieren: Problem, Umfang und CTQs festlegen

Welche Daten ersetzen: Annahmen darüber, welche Cases und Aktivitäten zum Umfang gehören.

Definieren Sie das zu lösende Problem, die Prozessgrenzen und die für Kunden oder Unternehmen wichtigen Critical-to-Quality-Kennzahlen (CTQs). Legen Sie zunächst gemeinsam fest, was als Case gilt. Das kann eine Bestellung, ein Ticket, eine Rechnung oder ein Schadensfall sein. Diese Entscheidung bestimmt, welche Ereignisse Sie zusammenfassen, und beeinflusst alle folgenden Messungen.

Prüfen Sie anhand von Prozessdaten, ob die erste Einschätzung des Teams dem heutigen Arbeitsablauf entspricht. Die Analyse kann Abweichungen oder Kennzahlen sichtbar machen, die im Workshop nicht zur Sprache kamen. Dokumentieren Sie den Umfang in einer Prozesslandkarte oder einem BPMN-Diagramm, damit das Team dieselbe Darstellung prüfen kann.

Ein sinnvolles Ergebnis: ein Umfang, für den ein Team Verantwortung übernehmen kann, eine von allen verstandene Case-Definition und CTQs, die sich mit den verfügbaren Daten messen lassen.

Messen: Ausgangsbasis für Zykluszeit, Kosten und Nacharbeit ermitteln

Welche Daten ersetzen: Schätzungen und kleine Stichproben als Ersatz für die aktuelle Prozessleistung.

Messen Sie den Prozess anhand der CTQs, die Sie in der Phase Definieren festgelegt haben. Je nach verfügbaren Daten und Projektumfang kann eine aussagekräftige Ausgangsbasis Zykluszeit, Kosten und Nacharbeit pro Case umfassen.

Wenn sich der Prozess über mehrere Systeme erstreckt, prüfen Sie, wie Sie deren Datensätze zusammenführen. Über eine vereinbarte Case-ID lassen sich Protokolle verknüpfen, um einen Case systemübergreifend nachzuverfolgen. Validieren Sie die Verknüpfung und die zugrunde liegenden Timestamps, bevor Sie sich auf die Ergebnisse stützen. Eine unvollständige oder fehlerhafte Verknüpfung kann die Ausgangsbasis verlässlicher erscheinen lassen, als sie tatsächlich ist.

Beschreiben Sie mit der Ausgangsbasis die aktuelle Leistung, bevor Sie ein Ziel festlegen. Richten Sie die Kennzahlen an der Problembeschreibung aus, statt nur solche auszuwählen, die sich leicht auslesen lassen.

Ein sinnvolles Ergebnis: eine Ausgangsbasis, die die prozessverantwortliche Person prüfen kann, einschließlich der zugrunde liegenden Annahmen und Dateneinschränkungen.

Erfahren Sie, wie Sie anhand realer Prozessdaten einen Ausgangswert ermitteln.

Analysieren: Engpässe, Varianten und Konformitätslücken finden

Welche Daten ersetzen: Workshop-Hypothesen, die noch nicht anhand des tatsächlichen Prozessverlaufs überprüft wurden.

Analysieren Sie die Nachweise, um zu verstehen, warum die Leistung schwankt. Untersuchen Sie, wo sich Verzögerungen summieren, welche Prozessvarianten auftreten, wie viele Cases weniger häufige Pfade durchlaufen und wo Cases vom Sollprozess abweichen.

Eine Prozessvariante ist einer der Pfade, die Cases durch den Prozess nehmen. Der Vergleich von Varianten zeigt, ob eine Verzögerung weit verbreitet ist oder sich auf einen bestimmten Pfad konzentriert. Bei der Konformitätsanalyse vergleichen Sie den tatsächlichen Ablauf mit dem Sollprozess und erkennen, wo beide voneinander abweichen.

Ordnen Sie mögliche Ursachen nach ihrer Wirkung und prüfen Sie sie anhand der Daten. Eine gründliche Analyse kann die ursprüngliche Hypothese des Teams bestätigen. Sie kann aber auch zeigen, dass die wichtigste Einschränkung an anderer Stelle liegt. Eine praktische Anleitung finden Sie unter Prozesse analysieren und Engpässe finden.

Ein sinnvolles Ergebnis: eine nach Priorität geordnete Liste möglicher Ursachen, die durch Nachweise gestützt wird und kritisch geprüft werden kann.

Verbessern: Veränderungen vor der Einführung priorisieren und testen

Welche Daten ersetzen: die Auswahl einer Veränderung, nur weil sie vertraut oder leicht zu verkünden ist.

Leiten Sie aus der Analyse Veränderungen ab, die den ermittelten Ursachen entgegenwirken. Vergleichen Sie die erwartete Wirkung mit dem erforderlichen Aufwand und den Risiken. Modellieren Sie den geplanten Prozess nach Möglichkeit und simulieren Sie verschiedene Szenarien, bevor Sie die Veränderung einführen. So können Sie mögliche Auswirkungen untersuchen, ohne eine Simulation als Garantie für den tatsächlichen Verlauf zu verstehen.

Dokumentieren Sie den Sollprozess, damit die Mitarbeitenden den neuen Ablauf nachvollziehen können. Messen Sie nach der Umsetzung dieselben Kennzahlen wie für die Ausgangsbasis. So können Sie beurteilen, ob die Veränderung die Leistung verbessert oder an anderer Stelle einen neuen Engpass verursacht hat.

Ein sinnvolles Ergebnis: eine anhand der Ausgangsbasis getestete Veränderung und ein Plan, mit dem Sie die tatsächliche Leistung nach der Einführung überprüfen.

Steuerung: Leistung, Dashboards und Zuständigkeiten überwachen

Welche Daten ersetzen: die Hoffnung, Veränderungen der Leistung bei gelegentlichen Audits oder aus dem Gedächtnis zu bemerken.

Die Phase Steuerung hilft Ihnen, Verbesserungen dauerhaft zu sichern. Legen Sie fest, welche Kennzahlen Sie überwachen, welche Schwellenwerte eine Überprüfung auslösen und wer für die Reaktion zuständig ist. Ein Dashboard zeigt der prozessverantwortlichen Person, ob sich die Leistung verändert und wo eine genauere Prüfung nötig ist.

Vereinbaren Sie Prüfintervalle und legen Sie fest, welche Maßnahmen ergriffen werden, wenn eine Kennzahl außerhalb des erwarteten Bereichs liegt. Wenn sich Volumen oder Case-Mix ändern, prüfen Sie, ob der Prozess und seine Zielwerte weiterhin sinnvoll sind.

Ein hilfreiches Ergebnis: eine klar benannte verantwortliche Person, eindeutige Erwartungen an die Überprüfung und Messgrößen, mit denen Sie Rückschritte erkennen und die nächsten Schritte festlegen können. Wie Sie die laufende Messung gestalten, erfahren Sie unter Prozesse kontinuierlich überwachen.

Ein durchgearbeitetes Beispiel: Order-to-Cash

So könnten die fünf Phasen auf einen Order-to-Cash-Prozess angewendet werden. Die folgenden Zahlen veranschaulichen ein Beispiel und sind keine zugesicherten Ergebnisse.

Definieren. Das Projekt umfasst den Order-to-Cash-Prozess für eine Produktfamilie. Ein Case beginnt mit der Annahme einer Bestellung und endet mit der Bezahlung der Rechnung. Die CTQs sind Rechnungsgenauigkeit und Zeit bis zum Zahlungseingang. Da es um verspätete Zahlungseingänge geht, ist die Zahlung ein relevanterer Endpunkt als der Versand.

Messen. Das Team verknüpft Ereignisdaten aus dem ERP- und dem Abrechnungssystem anhand der Bestellnummer. Die Ausgangsbasis zeigt einen Median von 34 Tagen zwischen Bestellannahme und Zahlung. Davon entfallen elf Tage auf den Zeitraum zwischen Rechnungserstellung und Versand.

Analysieren. Die Verzögerung konzentriert sich auf bestimmte Pfade. Im Beispiel durchlaufen 22 % der Bestellungen eine manuelle Bonitätsprüfung, die neun Tage hinzufügt. Jede sechste Rechnung wird erneut ausgestellt, wodurch die Zahlungsfrist von vorn beginnt. Keiner dieser Pfade ist im dokumentierten Prozessmodell enthalten.

Verbessern. Das Team erwägt, den Bonitätsschwellenwert anzuheben, damit manuelle Prüfungen auf Ausnahmefälle beschränkt bleiben. Eine Simulation mit historischen Daten legt nahe, dass sich dadurch bei 18 % der Bestellungen neun Tage einsparen ließen, ohne dass die Ausfallforderungen in diesen Daten steigen. Nach der Umsetzung müsste das Team die tatsächliche Leistung weiterhin überprüfen.

Steuerung. Das Team erfasst den Anteil der Bestellungen, die den manuellen Pfad durchlaufen, und legt einen Schwellenwert für eine Überprüfung fest. Der Bestellservice ist für die Kennzahl zuständig. Das zugehörige Dashboard steht dem für den Prozess verantwortlichen Team zur Verfügung.

Häufige Fehler bei der Lean-Prozessverbesserung

Ein DMAIC-Projekt kann die vorgesehenen Schritte auf dem Papier einhalten und trotzdem keine sinnvolle Veränderung bewirken. Achten Sie auf diese Muster:

• Bürokratie rund um Belt-Zertifizierungen. Das Team investiert Zeit in Projektdokumente, bevor es den Prozess oder die zugehörigen Daten prüft. Projektaufträge und Stakeholder-Übersichten können hilfreich sein, belegen für sich genommen aber keinen Fortschritt.
• Keine belastbare Ausgangsbasis. Wird die Messphase ausgelassen oder stützt sie sich nur auf eine Umfrage, gibt es in der Analyse wenig zu überprüfen. Ohne Ausgangspunkt ist später kein fundierter Vergleich möglich.
• Der Umfang wird auf Programmebene festgelegt. Bei einem breit angelegten Programm gibt es möglicherweise keine einzelne verantwortliche Person, keine Case-Definition und keine Kennzahl, die ein Team beeinflussen kann. Begrenzen Sie den Umfang auf einen Prozess mit klaren Grenzen und Zuständigkeiten.
• Die Verbesserung wird vor der Analyse ausgewählt. Hat das Team bereits entschieden, was automatisiert oder neu gestaltet werden soll, sucht es möglicherweise nur nach Belegen für diese Entscheidung. Nutzen Sie die Analyse, um die vermutete Ursache zu prüfen, nicht um eine vorab festgelegte Lösung zu rechtfertigen.
• Keine Phase Steuerung. Wenn nach Projektende niemand für die Kennzahlen zuständig ist, bleiben Veränderungen der Leistung möglicherweise unbemerkt. Legen Sie vor Projektabschluss Zuständigkeit, Schwellenwerte und Prüfintervalle fest.

So unterstützt ProcessMind die einzelnen DMAIC-Phasen

Mit ProcessMind können Sie Prozessdaten untersuchen, Abläufe dokumentieren, die Leistung analysieren und geplante Veränderungen simulieren. Die Plattform unterstützt die Untersuchung. Ihr Team entscheidet, welche Veränderungen umgesetzt werden, und führt sie durch. Diese Werkzeuge für die Lean-Prozessverbesserung ergänzen den DMAIC-Zyklus um Nachweise, ohne Prozesswissen oder Zuständigkeit zu ersetzen.

Die Phasen bauen auf einer gemeinsamen Prozessdefinition auf. Wenn jede Phase andere Daten oder eine andere Prozessdarstellung verwendet, muss Ihr Team diese Unterschiede möglicherweise erst abgleichen, statt die Verbesserung zu bewerten.

Einen Überblick über den Analyse-Workflow finden Sie unter Prozessdaten analysieren. Wie Prozessmodellierung und Process Mining einander ergänzen, erfahren Sie unter Die kombinierte Rolle von Prozessmodellierung und Process Mining.

So starten Sie ein DMAIC-Projekt

Mit diesen Schritten machen Sie aus einem allgemeinen Verbesserungsziel ein Projekt, dessen Ergebnisse Ihr Team messen kann. Dieses Modell für die Lean-Prozessverbesserung hält den ersten Zyklus auf einen Prozess fokussiert, den Ihr Team definieren, messen und überprüfen kann:

1. Wählen Sie einen Prozess mit klarer Zuständigkeit. Wenn niemand für den Prozess verantwortlich ist, lässt sich auch die Zuständigkeit für die Phase Steuerung nur schwer festlegen.
2. Vereinbaren Sie eine Case-Definition. Dokumentieren Sie, wodurch ein Case beginnt und endet, und ermitteln Sie, welche Systeme diese Ereignisse erfassen.
3. Messen Sie, bevor Sie Verbesserungen umsetzen. Ermitteln Sie eine Ausgangsbasis, bevor Workshops oder eine Neugestaltung den Sollzustand festlegen.
4. Konzentrieren Sie sich im ersten Zyklus auf einen klaren Umfang. Beginnen Sie mit einem Umfang, den Ihr Team untersuchen und überprüfen kann. Nutzen Sie anschließend die Erkenntnisse, um die nächsten Fragen festzulegen.

Nachdem Sie eine Veränderung getestet haben, setzen Sie die Verbesserungen um.

Wie es weitergeht

Starten Sie Ihr DMAIC-Projekt mit einer gemessenen Ausgangsbasis.

Starten Sie Ihr DMAIC-Projekt mit einer gemessenen Ausgangsbasis