Process Mapping erzeugt durch Beobachtung, Interviews, Workshops und Modellierung ein gemeinsames Bild der Arbeit. Es kann Ist-Prozess, beabsichtigte Policy oder Zielbild beschreiben. Process Mining rekonstruiert Verhaltensmuster aus zeitgestempelten Ereignissen in Informationssystemen. Mapping erklärt Bedeutung, Urteil und Arbeit ausserhalb von Systemen. Mining misst aufgezeichnete Pfade, Zeiten, Varianten und Conformance in grossem Umfang. Die Methoden beantworten verschiedene Fragen und ergänzen einander.
Organisationen automatisieren oft den Prozess, den sie beschreiben können, nicht den tatsächlich ausgeführten. Eine Workshop-Map glättet möglicherweise Rework, lokale Workarounds und stille Entscheide. Ein Event Log kann präzise wirken und dennoch E-Mail, Urteil, Gespräche oder nie erfasste Schritte auslassen. Gilt eine der Darstellungen als alleinige Wahrheit, optimiert das Team ein Teilbild, automatisiert unnötige Komplexität oder erklärt berechtigte Variation voreilig zur Abweichung.
Beginnen Sie mit Entscheid, Prozessgrenze und Folgen, danach wählen Sie die nötige Evidenz. Mappen Sie den Prozess für Sprache, Absicht, Rollen und Hypothesen. Minen Sie ein validiertes Event Log, wenn Systemspuren vollständig und vergleichbar genug sind. Gleichen Sie beide Bilder mit Praktikerinnen und Praktikern ab, bevor Sie redesignen. Process Mining ersetzt keine menschliche Untersuchung, Process Mapping belegt keine Häufigkeit oder Performance. Automation braucht ein trianguliertes Bild dessen, was geschieht, warum und welches Ergebnis besser werden soll.
Evidenz
Eine Map erfasst Bedeutung; ein Mining-Modell erfasst aufgezeichnetes Verhalten
Process Mapping ist eine soziale und analytische Tätigkeit. Eine Moderation kann fragen, warum ein Reviewer wartet, weshalb ein Kundensegment anders läuft, was in einem Telefonat geschieht und welche Regel nur im Kopf erfahrener Mitarbeitender existiert. Das Ergebnis kann ein einfacher Flow, Service Blueprint, Value-Stream-Bild oder eine formale Notation sein. BPMN ist eine nützliche standardisierte Notation, wenn Präzision und Austauschbarkeit helfen, aber nicht jede Mapping-Arbeit braucht BPMN. Die Darstellung muss dem Entscheid dienen und für die Prozessverantwortlichen verständlich sein.
Process Mining startet mit einem Event Log statt einer leeren Fläche. Mindestens müssen Events einem Fall, einer Aktivität und einer Zeit zugeordnet sein. Daraus zeigt die Analyse Varianten, Warteschlangen, Wiederholungen und Sequenzen über weit mehr Fälle, als ein Workshop besprechen kann. Sie kann Verhalten mit einem Referenzmodell vergleichen und Änderungen überwachen. Die scheinbare Objektivität hat eine Grenze: Beschrieben wird die Instrumentierung des Prozesses. Ohne weitere Evidenz erkennt sie kein unaufgezeichnetes Gespräch, keine Entscheidqualität und keinen Grund für eine Ausnahme.
| Dimension | Process Mapping | Process Mining |
|---|---|---|
| Primäre Evidenz | Beobachtung, Menschen, Policy und Moderation | System-Event-Logs |
| Stärkste Sicht | Bedeutung, Rollen, Entscheide und Zielbild | Skala, Zeiten, Varianten und Conformance |
| Blinder Fleck | Häufigkeit und Erinnerungsverzerrung | Unaufgezeichnete Arbeit und Fachbedeutung |
| Typisches Ergebnis | Gemeinsame Prozessdarstellung | Verhaltensmodell, Traces und Performance |
| Bester Einsatz | Framing und Redesign | Hypothesenprüfung und laufende Diagnose |
Datenreife
Ein brauchbares Event Log ist ein semantisches Produkt, kein Zeitstempel-Export
Datenreife beginnt beim Fallbegriff. Bestellung, Schaden, Antrag oder Supportanfrage wirken eindeutig, bis sie geteilt, zusammengeführt, wiedereröffnet oder in mehreren Systemen durch andere IDs dargestellt werden. Auch jede Aktivität braucht eine Fachdefinition. Ein Datenbank-Update kann Arbeitsbeginn, Abschluss oder nur den Retry einer Integration bedeuten. Wählen Sie den relevanten Zeitstempel, normalisieren Sie Zeitzonen, erhalten Sie Eventreihenfolge und erkennen Sie Batch-Verarbeitung. Dokumentieren Sie Quellenabdeckung, Retention, spät eintreffende Events und bekannte Lücken.
Validieren Sie das Log mit echten Fällen, bevor Sie die ganze Population minen. Wählen Sie normale, aussergewöhnliche, schnelle, langsame und kürzlich veränderte Beispiele. Fragen Sie Praktikerinnen und Praktiker, ob der rekonstruierte Trace erkennbar ist, und prüfen Sie die Quelle bei Abweichungen. Regeln Sie rechtmässigen, verhältnismässigen Zugriff, minimieren Sie Personendaten und beschränken Sie Fallansichten. Die Analyse von Business Events unterscheidet sich von Task Mining, das detaillierte Interaktionen am Arbeitsplatz beobachtet. Task Mining kann Variation innerhalb einer Aufgabe zeigen, schafft aber eigene Datenschutz-, Personal-, Security- und Interpretationsrisiken.
- Fall, Aktivität und Zeit in Fachsprache definieren.
- Joins über Systeme und ID-Wechsel prüfen.
- Fehlende, doppelte und verspätete Events quantifizieren.
- Repräsentative Traces mit Praktizierenden validieren.
- Fallzugriff begrenzen und legitime Nutzung dokumentieren.
Kombinierte Methode
Soll, Erfahrung und Aufzeichnung vor der Automationswahl abgleichen
Eine praktische Sequenz beginnt mit einer leichten Map, die Grenze und Hypothesen festhält. Danach baut das Team ein validiertes Event Log und prüft die Hypothesen über die Population. Mining kann einen langen Variantenschwanz zeigen, doch Häufigkeit allein sagt nicht, welche Unterschiede relevant sind. Prozessbeteiligte trennen Datenartefakte, berechtigte Segmentierung, Kontrollschritte, Kapazitätsengpässe und vermeidbaren Rework. Das abgeglichene Modell zeigt sowohl gemessene Muster als auch Betriebsbegründung und verbleibende Unsicherheit.
Redesign kommt vor Tooling. Entfernen Sie Freigaben, die kein relevantes Risiko mehr kontrollieren, klären Sie mehrdeutige Eingangskriterien und verringern Sie unnötige Übergaben. Bewerten Sie Automationskandidaten nach Ergebniswert, technischer Machbarkeit, Ausnahmestruktur, Reversibilität und Evidenzbedarf. Pilotieren Sie den Zielprozess mit Vergleichsbaseline und Instrumentierung, die die Änderung überlebt. Eine erfolgreiche Analyse endet nicht in einem Dashboard. Sie erzeugt einen sichereren Betriebsentscheid und einen weiter beobachtbaren Prozess.
- Hypothese und Unsicherheit mappen.
- Erst nach validierter Eventsemantik minen.
- Varianten mit Prozessbeteiligten erklären.
- Policy und Flow vor Automation redesignen.
- Ergebnis, Ausnahme und menschliche Last messen.
Woran gute Arbeit erkennbar ist
Konkrete Ergebnisse für Process Mining vs Process Mapping
- Das Team trennt Policy, wahrgenommene Praxis und aufgezeichnetes Verhalten.
- Eine explizite Prozessgrenze erlaubt vergleichbare Fälle und sinnvolle Metriken.
- Eventdaten werden vor der Interpretation eines Mining-Bildes semantisch geprüft.
- Menschliche Entscheide, Offline-Schritte und undokumentierte Workarounds bleiben sichtbar.
- Häufige Varianten werden von seltenen, aber folgenreichen Ausnahmen unterschieden.
- Conformance-Fragen nutzen ein vereinbartes Referenzmodell und fachliche Begründungen.
- Automationskandidaten folgen Ergebnis, Machbarkeit und Kontrolle statt nur Verzögerung.
- Der neue Prozess erhält Instrumentierung für Nutzen, Ausnahmen und Nebenwirkungen.
Betriebsmodell
So wird die Arbeit ausgeführt
- 01
Betriebsentscheid rahmen
Benennen Sie Ergebnis, Kundschaft oder interne Nutzende, Trigger, Endpunkt und den zu unterstützenden Entscheid. Grenzen Sie Prozess und Fallpopulation ab. Erfassen Sie relevante Policy-, Service-, Risiko- und Datenschutzbedingungen vor der Datenanforderung.
- 02
Prüfbare Hypothese mappen
Beobachten Sie die Arbeit und erstellen Sie mit Beteiligten eine Ist-Map. Markieren Sie Systeme, Übergaben, Entscheide, Warteschlangen, Offline-Arbeit, bekannte Varianten und Unsicherheit. Behandeln Sie die Map als prüfbare Hypothese, nicht als zertifizierte Beschreibung.
- 03
Event Log bauen und validieren
Definieren Sie Fall-ID, Aktivitätsbedeutung und Zeitstempelsemantik. Klären Sie Joins, Zeitzonen, Duplikate, fehlende Zustände und wechselnde Identifikatoren. Prüfen Sie repräsentative Fälle und dokumentieren Sie, was das Log nicht sieht.
- 04
Minen, abgleichen und erklären
Analysieren Sie Pfade, Dauern, Rework, Engpässe und Conformance. Prüfen Sie ausgewählte Traces mit den Menschen, welche die Arbeit ausführen und erhalten. Erklären Sie Unterschiede zwischen Map und Log, bevor Sie Ursachen behaupten oder Chancen priorisieren.
- 05
Redesignen, pilotieren und messen
Entfernen Sie unnötige Schritte und klären Sie Policy vor der Automation. Pilotieren Sie einen begrenzten Zielprozess mit expliziten Kontrollen und menschlicher Eskalation. Messen Sie akzeptierte Ergebnisse, Durchlaufzeit, Ausnahmen und Betriebsaufwand gegen die Baseline.
Bewertung
Fragen, die den Entscheid verändern
- Dient die Analyse Discovery, Compliance, Performance, Redesign oder Automationsauswahl?
- Welches Ereignis startet einen Fall und welche Evidenz belegt einen akzeptierten Abschluss?
- Erfassen Quellsysteme genug vom Prozess für die beabsichtigte Aussage?
- Bleiben Fall-IDs über Systeme, Kanäle, Wiedereröffnungen und Teilprozesse stabil?
- Welche Aktivitäten brauchen menschliche Erklärung, weil ihre Bedeutung im Log fehlt?
- Beschreibt die Referenz-Map Policy, beobachteten Ist-Zustand oder vorgeschlagenes Zielbild?
- Welche Varianten sind Verschwendung, berechtigte Segmentierung, Kontrolle oder Fachurteil?
- Kann das Team dasselbe Ergebnis nach der Prozessänderung weiterhin messen?
Fehlermuster
Wo Teams die Kontrolle verlieren
Eine elegante Map kann Hierarchie oder Policy spiegeln und Alltagspraxis verbergen.
Ein unvollständiges Log lässt nicht aufgezeichnete Arbeit als nichtexistent erscheinen.
Ein Systemevent wird mit einer abgeschlossenen fachlichen Aktivität verwechselt.
Fall-Joins vermischen fremde Arbeit oder teilen eine Reise in künstliche Fälle.
Fehler bei Zeitstempel und Zeitzone erzeugen Verzögerungen oder falsche Reihenfolgen.
Der häufigste Pfad wird optimiert, während folgenreiche Ausnahmen schlechter werden.
Conformance-Labels stigmatisieren einen nötigen Workaround, bevor die Ursache klar ist.
Task Mining erfasst sensible Desktop-Aktivität über die legitime Prozessfrage hinaus.
Automation schreibt schlechte Policy fest oder verschiebt Arbeit in unsichtbare Queues.
Eine einmalige Analyse veraltet bei Änderungen von System, Produkt, Team und Definition.
Messung
Das fertige Ergebnis messen
Gemessen wird der abgeschlossene Prozess inklusive Review-Aufwand und Ausnahmen. Reines Output-Volumen beweist noch keine bessere Arbeitsweise.
- akzeptierte End-to-End-Ergebnisse je Fallsegment
- Fallabdeckung und Eventvollständigkeit je Quellsystem
- Durchlauf-, Aktiv- und Wartezeit je Variante
- Rework, Wiedereröffnung und Aktivitätswiederholung je Fall
- First-Pass-Abschluss und menschliche Korrektur
- Häufigkeit, Folge und Recovery-Aufwand von Ausnahmen
- Conformance-Abweichung mit dokumentierter Fachbegründung
- Fälle mit offenen Joins, Duplikaten oder Zeitstempelanomalien
- Intervention, Override und Eskalation nach Automation
- Beständigkeit des Nutzens nach Volumen-, Policy- oder Systemänderung
Fragen
Häufige Fragen
Ist Process Mining besser als Process Mapping?
Keine Methode ist immer besser. Mapping ist stärker bei Bedeutung, Fachurteil, Offline-Arbeit und Zielbild. Mining ist stärker bei aufgezeichneter Skala, Zeit, Varianten und Conformance. Wählen Sie nach dem Entscheid und kombinieren Sie beide, wenn Kontext und Verhaltensdaten zählen.
Welche Daten braucht Process Mining?
Ein Event Log ordnet Events einem Fall, einer sinnvollen Aktivität und einer Zeit zu. Zusätzlich müssen Teams ID-Joins, Eventsemantik, Zeitzonen, Duplikate, fehlende Events, Quellenabdeckung und Zugriffsrechte validieren. Die nötige Qualität hängt von der beabsichtigten Aussage ab.
Was unterscheidet Process Mining von Task Mining?
Process Mining analysiert gewöhnlich Business Events über Fälle und Systeme. Task Mining beobachtet detaillierte User-Interaktionen innerhalb einer Aufgabe. Das kann Desktop-Variation zeigen, erzeugt aber zusätzliche Datenschutz-, Security- und Interpretationsfragen. Es ist keine Voraussetzung für Process Mining.
Soll Process Mining vor der Automation stattfinden?
Nutzen Sie es vorher, wenn Eventdaten wichtige Annahmen zu Flow, Verzögerung, Rework oder Variation prüfen können. Verbinden Sie es mit Beobachtung und Mapping, damit unaufgezeichnete Arbeit und Gründe sichtbar bleiben. Vereinfachen Sie zuerst und pilotieren Sie dann gegen eine explizite Ergebnisbaseline.
Quellen
Primärquellen
- IEEE Task Force on Process Mining IEEE Task Force on Process Mining
- Business Process Model and Notation Version 2.0.2 Object Management Group
Über den Autor
Malcolm Ferguson
Malcolm schreibt aus Käufersicht über Beschaffung, Sourcing, Due Diligence und die Nachweise für eine belastbare Lieferantenbewertung.
Zenith
KI-Workflow-Automatisierung für repetitive, dokumentenintensive und researchlastige Abläufe.
Operations, Finance, Commercial und Transformation. Ausgangspunkt sind der bestehende Ablauf, seine Grenzen und die vorhandenen Nachweise.
Zenith ansehen→