Process Mining liefert DMAIC-Teams Ereignisdaten zur Untersuchung von Prozesspfaden und sich wiederholenden Aktivitäten. Die in der Zeitschriftenausgabe von 2021 veröffentlichte Studie „Process Mining for Six Sigma“ hat einen Leitfaden entwickelt, der diese Techniken auf DMAIC abstimmt. Vor dem Extrahieren eines Protokolls muss das Team die Optimierungsentscheidung definieren, die durch diese Daten unterstützt werden soll.
Definieren Sie die DMAIC-Grenze vor der Ereignisextraktion
Die DMAIC-Praxis ordnet Projektumfang und Kundenanforderungen der Phase Define zu. Ein SIPOC hilft dem Team, sich auf die Untersuchungseinheit und deren Grenzen zu einigen. Der Projektauftrag definiert dann einen Fall sowie dessen Messstartpunkt. Er legt auch das Ergebnis fest, das als erfolgreicher Abschluss gilt.
Übermäßige verstrichene Zeit und fehlerhafte Ausgaben, die eine Korrektur erfordern, benötigen separate operative Definitionen im problem statement des Projekts. Die Review des Sponsors in der Define-Phase sollte klären, welche Kundenanforderung Priorität hat. Sie sollte auch die Qualitätsmaßnahme identifizieren, die geschützt werden muss, wenn das Team den Prozess ändert.
Measure: Festlegen, was das Ereignisprotokoll darstellen kann
Ein konventionelles Ereignisprotokoll verknüpft jede Aktivität mit einem Fall und zeichnet auf, wann sie aufgetreten ist. Ressourceninformationen sind optional, wie im PMSS-Paper beschrieben. Der DMAIC-Messplan benötigt eine Definition für jedes Feld, bevor das Team die Leistung berechnet:
- Fall-Identifikator: die Prozessinstanz, die durch die vereinbarte SIPOC-Grenze verfolgt wird.
- Aktivität: der Geschäftsschritt, der durch jedes aufgezeichnete Ereignis dargestellt wird.
- Zeitstempel: der vom System aufgezeichnete Zeitpunkt, wie etwa Start oder Abschluss einer Aktivität.
- Zusätzliche Attribute: die Ressourcen- oder Falleigenschaften, die für geplante Vergleiche benötigt werden.
Das Measure-Review muss auch festlegen, wie viel Arbeit das Protokoll erfasst. In einer 2024-Studie in Data & Knowledge Engineering beobachteten Forscher sechs Mitarbeiter eines Dienstleistungsunternehmens. Sie fanden heraus, dass ein Protokoll aus dem Haupttransformationssystem etwa 69 % der beobachteten Datentransformations- und Validierungszeit abbilden würde. Die Abdeckung fiel auf 32.5 %, wenn sie am gesamten relevanten kundenbezogenen Arbeitsaufwand gemessen meinte. Diese Prozentsätze gelten für das untersuchte Unternehmen.
Für ein Lean Six Sigma-Team wirft diese Abdeckungslücke eine Umfangsentscheidung auf: Erfasst das vorgeschlagene Protokoll die im Projektauftrag genannte Arbeit? Ein gemba walk zusammen mit der Extraktionsprüfung hilft, Arbeiten zu identifizieren, die in den Systemaufzeichnungen fehlen. Das Ergebnis der Measure-Phase sollte diese ausgelassenen Aktivitäten nennen und erklären, wie deren Fehlen die Analyse einschränkt.
Eine Engpassuntersuchung erfordert mehr als nur ein langes Intervall
Ein langes Intervall zwischen Zeitstempeln benötigt eine Erklärung, bevor das Analyze-Team es als Kapazitätsproblem behandelt. Eine Information-Systems-Studie aus dem Jahr 2024 unterteilt das Warten zwischen Aktivitäten in fünf Ursachen: Chargenbildung (Batching), Ressourcenkonflikte, Priorisierung, Nichtverfügbarkeit von Ressourcen und externe Faktoren. Die Forscher evaluierten ihren Ansatz mit synthetischen Protokollen und demonstrierten ihn an einem realen Prozess. Diese Kategorien geben Lean Six Sigma-Teams spezifische Ursachen an die Hand, die sie untersuchen können, bevor sie zusätzliche Kapazitäten vorschlagen.
Der DMAIC-Analyseplan sollte die verstrichene Zeit zwischen aufgezeichneten Ereignissen von der Wartezeit unterscheiden, bevor eine Aktivität starten kann. Diese Unterscheidung hängt davon ab, was die Zeitstempel aufzeichnen und wie die Analyse Arbeitskalender handhabt. Sobald Verzögerungskategorien bestätigt sind, ordnet ein Pareto chart diese nach kumulierter Zeit innerhalb der Projektgrenze.
Konkurrierende Erklärungen gehören in ein Ishikawa diagram. Wenn das Team eine Stapelverarbeitung (Batching) vermutet, benötigt die Review der Analyze-Phase Beweise, die Freigaberegeln mit den beobachteten Verzögerungen verknüpfen. Ein Pilotprojekt, das diese Regeln ändert, testet eine andere Ursache als ein Pilotprojekt, das die Ressourcenverfügbarkeit verändert.
Klassifizierung von Nacharbeit vor dem Zählen von Fehlern
Die Rechnungsstellungs-Demonstration des PMSS-Papers vergleicht Fälle mit Aktivitätswiederholungen mit anderen Fällen und untersucht deren Pfade und Bearbeitungszeiten. Dieser Vergleich identifiziert untersuchungswürdige Fälle. Das Zählen von Wiederholungen als Fehler erfordert eine vom Process Owner genehmigte Geschäftsregel, die Korrekturarbeiten von zulässigen Wiederholungen unterscheidet.
Für DMAIC ist eine vorgeschlagene Kennzahl der Anteil der berechtigten Fälle, die mindestens eine bestätigte Korrekturwiederholung enthalten. Eine separate Zählung zusätzlicher Wiederholungen erfasst die Korrekturarbeitslast. Die Fehlermessung auf Fallebene hat dann eine festgelegte Regel, welche die Untersuchung mittels 5 Whys an einzelnen Fällen testen kann.
Improvement durch ein Pilotprojekt, das an die vermutete Ursache gebunden ist
Die Lösungsbewertung gehört in die Phase Improve. Der Pilotvorschlag sollte die ausgewählte Änderung mit einer Erkenntnis aus Analyze verknüpfen. Das Beibehalten der Falldefinition der Baseline gibt dem Team eine konsistente Vergleichsgrundlage; ein festgelegtes Akzeptanzergebnis setzt den Maßstab für die Überprüfung der Änderung. In einem Nacharbeitsprojekt sollte der Pilotversuch einen Poka-Yoke-Vorschlag vor der breiteren Einführung gegen die bestätigte Korrekturkategorie testen.
Beim Improve-Review würde ich fragen, wie die Test- und die Baseline-Fallgruppe im Vergleich stehen, einschließlich etwaiger Unterschiede im Arbeitsaufwand oder Fallmix. Der Sponsor muss neben der verstrichenen Zeit auch die geschützte Qualitätskennzahl sehen. Ein kürzeres Intervall auf dem Process-Mining-Dashboard ist kein ausreichender Nachweis für eine Akzeptanz, wenn sich der Fallmix verändert oder die Anzahl der Fehler zugenommen hat.
Control-Pläne müssen die Ereignis-Datenpipeline enthalten
Die Control-Phase umfasst langfristige Messungen und Reaktionspläne. Der Control Plan sollte auch den Verantwortlichen für die Aktivitätsdefinitionen der Ereignisextraktion benennen und festlegen, wer Änderungen an der Prozessdarstellung genehmigt. Fehlende Datensätze erfordern eine dokumentierte Handhabung. Wiederkehrende Nacharbeit und eine sich verschlechternde Log-Abdeckung benötigen jeweils eine zugewiesene Reaktion.
Dokumentierte Messdefinitionen müssen sich in die control charts fortsetzen. Wenn eine Systemänderung das verändert, was ein Zeitstempel aufzeichnet, benötigt der Process Owner eine Messüberprüfung, bevor er das nächste Leistungssignal interpretiert.
Quellen
- Business & Information Systems Engineering (2021), Process Mining for Six Sigma: https://link.springer.com/article/10.1007/s12599-020-00649-w
- Data & Knowledge Engineering (2024), Capturing and Analysing Employee Behaviour: An Honest Day’s Work Record: https://research-portal.uu.nl/ws/portalfiles/portal/239370240/1-s2.0-S0169023X24000740-main.pdf
