Process Mining bietet DMAIC -Teams Ereignisaufzeichnungen zur Untersuchung von Prozesspfaden und sich wiederholenden Aktivitäten. Die Studie „Process Mining for Six Sigma“, die im Jahrbuch 2021 veröffentlicht wurde, hat einen Leitfaden entwickelt, der diese Techniken mit DMAICabstimmt. Vor dem Extrahieren eines Protokolls muss das Team die Optimierungsentscheidung identifizieren, die durch diese Datensätze unterstützt werden soll.
Definieren Sie die DMAIC-Grenze vor der Ereignisextraktion
Der DMAIC-Leitfaden der ASQ ordnet den Projektumfang und die Kundenanforderungen der Phase Define zu. Ein SIPOC hilft dem Team, sich auf die Analyseeinheit und deren Grenzen zu einigen. Der Projektauftrag definiert dann einen Fall und dessen Messstartpunkt. Er legt auch das Ergebnis fest, das als erfolgreicher Abschluss gilt.
Übermäßige Durchlaufzeiten und fehlerhafte Ergebnisse, die eine Korrektur erfordern, benötigen separate operative Definitionen in der Problembeschreibungdes Projekts. Das Define-Review des Sponsors sollte klären, welche Kundenanforderung Priorität hat. Es sollte auch die Qualitätskennzahl 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-ID: die Prozessinstanz, die durch die vereinbarte SIPOC Grenze verfolgt wird.
- Aktivität: der Betriebsschritt, der durch jedes aufgezeichnete Ereignis dargestellt wird.
- Zeitstempel: der vom System aufgezeichnete Zeitpunkt, wie z. B. 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 Lösungsentscheidung bezüglich des Umfangs auf: Erfasst das vorgeschlagene Protokoll die im Projektauftrag genannte Arbeit? Ein Gemba-Walk parallel zur Extraktionsprüfung hilft dabei, im System fehlende Arbeitsschritte zu identifizieren. Das Ergebnis der Measure-Phase sollte diese ausgelassenen Aktivitäten benennen 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 verstreichende Zeit zwischen aufgezeichneten Ereignissen vom Warten vor dem Start einer Aktivität unterscheiden. Diese Unterscheidung hängt davon ab, was die Zeitstempel aufzeichnen und wie die Analyse Arbeitskalender handhabt. Sobald die Verzögerungskategorien bestätigt sind, ordnet ein Pareto-Diagramm sie nach der aufgelaufenen Zeit innerhalb der Projektgrenzen ein.
Konkurrierende Erklärungen gehören in ein Ishikawa-Diagramm. Wenn das Team Chargenbildung vermutet, benötigt das Analyze-Review Belege, 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 ä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 infrage kommenden Fälle, die mindestens eine bestätigte Korrekturwiederholung enthalten. Eine separate Zählung zusätzlicher Wiederholungen erfasst den Korrekturaufwand. Die Fehlermessung auf Fallebene verfügt dann über eine definierte Regel, die die 5 Whys -Untersuchung an einzelnen Fällen testen kann.
Improvement durch ein Pilotprojekt, das an die vermutete Ursache gebunden ist
ASQ ordnet die Lösungsevaluierung der Phase Improve zu. Der Pilotprojektvorschlag sollte die ausgewählte Änderung mit einer Erkenntnis aus der Analyze-Phase verbinden. Behält man die Falldefinition der Baseline bei, hat das Team eine konsistente Vergleichsbasis; ein festgelegtes Akzeptanzergebnis definiert den Test für die Änderung. In einem Nacharbeitsprojekt sollte das Pilotprojekt einen Poka-Yoke -Vorschlag vor dem breiteren Rollout 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 der ASQ umfasst langfristige Mess- und Reaktionspläne. Der Erstellen Sie einen sollte auch den Verantwortlichen für die Aktivitätsdefinitionen der Ereignisextraktion benennen und festlegen, wer Zuordnungsänderungen genehmigt. Fehlende Datensätze benötigen eine dokumentierte Behandlung. Wiederkehrende Nacharbeit und eine sich verschlechternde Protokollabdeckung erfordern jeweils eine zugewiesene Maßnahme.
Dokumentierte Messdefinitionen müssen bis in den Qualitätsregelkartenübernommen werden. Wenn eine Systemänderung das verändert, was ein Zeitstempel aufzeichnet, benötigt der Process Owner ein Mess-Review, 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
