Artikel

Innovation

Process Mining: Definition, Methoden & Anwendung in der Serviceoptimierung

Process Mining analysiert reale Prozessdaten aus IT-Systemen. Erfahre die drei Methoden, den Ablauf und wie du Serviceprozesse datenbasiert optimierst.

Veroeffentlicht am: 7. April 2026 von SI Labs

Process Mining ist eine datengetriebene Analysemethode, die reale Geschäftsprozesse aus den Event-Logs betrieblicher IT-Systeme rekonstruiert, visualisiert und bewertet. Im Gegensatz zu klassischen Prozessmodellierungsansätzen, bei denen Teams am Whiteboard beschreiben, wie ein Prozess laufen sollte, zeigt Process Mining, wie er tatsächlich läuft — mit allen Abweichungen, Schleifen und Engpässen, die im Tagesgeschäft entstehen [1].

Die Methode wurde ab den späten 1990er-Jahren von Wil van der Aalst an der Technischen Universität Eindhoven entwickelt und hat sich seither von einem akademischen Forschungsfeld zu einem milliardenschweren Softwaremarkt entwickelt — mit Anbietern wie Celonis, Signavio, Minit und IBM [1][2]. 2011 veröffentlichte die IEEE Task Force on Process Mining ein Manifest, das Process Mining als eigenständige Disziplin zwischen Data Mining und Geschäftsprozessmanagement positionierte [3].

Suchst du im deutschsprachigen Netz nach “Process Mining”, findest du zehn Ergebnisse, die dasselbe tun: Software-Anbieter erklären, warum ihr Tool das beste ist. Wikipedia liefert eine akademische Definition. Kaum ein Ergebnis erklärt, wie Process Mining konkret in der Serviceoptimierung eingesetzt wird — jenseits der immer gleichen SAP-Einkaufsprozess-Beispiele. Keines verbindet Process Mining mit dem Werkzeugkasten der Serviceentwicklung: Wo ergänzt es die Wertstromanalyse? Wann ist ein Service Blueprint die bessere Wahl? Und was sind die ehrlichen Grenzen der Methode?

Dieser Leitfaden schließt diese Lücken — mit einer klaren Einordnung der drei Process-Mining-Typen, einem Schritt-für-Schritt-Ablauf, einem Servicebeispiel aus der Versicherungsbranche und einer ehrlichen Bewertung, wann Process Mining die falsche Methode ist.

Was Process Mining von klassischer Prozessanalyse unterscheidet

Um Process Mining einzuordnen, hilft ein Vergleich mit zwei verwandten Ansätzen: der manuellen Prozessmodellierung (wie sie etwa in BPMN-Workshops stattfindet) und der Wertstromanalyse aus dem Lean-Umfeld.

Dimension	Manülle Prozessmodellierung	Wertstromanalyse	Process Mining
Datenquelle	Interviews, Workshops, Expertenwissen	Beobachtung vor Ort (Gemba Walk)	Event-Logs aus IT-Systemen
Perspektive	Soll-Zustand (“So sollte es laufen”)	Ist-Zustand (beobachtet)	Ist-Zustand (datenbasiert)
Objektivität	Subjektiv — abhängig vom Wissen der Teilnehmer	Semi-objektiv — Beobachter kann übersehen	Objektiv — basiert auf Systemdaten
Skalierbarkeit	Niedrig — funktioniert nur für einzelne Prozesse	Niedrig — erfordert physische Präsenz	Hoch — kann Millionen von Prozessinstanzen gleichzeitig analysieren
Zeitdimension	Statisch — Snapshot eines Moments	Semi-dynamisch — beobachteter Zeitraum	Dynamisch — kann historische Entwicklung zeigen
Blinde Flecken	Workarounds, informelle Prozesse	Digitale Prozessschritte ohne physische Präsenz	Manülle Schritte ohne Systemprotokoll
Typischer Einsatz	Prozessdesign, Compliance-Dokumentation	Lean-Optimierung, Verschwendungsanalyse	Prozessanalyse, Conformance, Automatisierung

Die zentrale Erkenntnis: Process Mining und Wertstromanalyse sind keine Alternativen — sie ergänzen sich. Die Wertstromanalyse liefert den menschlichen Blick auf den Prozess: Warum passiert etwas? Was fühlen die Beteiligten? Welche informellen Workarounds existieren? Process Mining liefert die Datenbasis: Was passiert tatsächlich? Wie oft? Wie lange? In welchen Varianten? Der stärkste Ansatz kombiniert beide: Process Mining für die quantitative Bestandsaufnahme, Gemba Walk und Wertstromanalyse für die qualitative Vertiefung.

Die drei Typen des Process Mining

Van der Aalst unterscheidet drei grundlegende Typen des Process Mining, die aufeinander aufbaün [1]:

1. Process Discovery (Prozessentdeckung)

Was es tut: Aus Event-Log-Daten wird automatisch ein Prozessmodell generiert — ohne dass vorher ein Modell existieren muss. Algorithmen wie der Alpha Miner, der Heuristic Miner oder der Inductive Miner analysieren die Reihenfolge der Aktivitäten in den Logs und konstruieren daraus ein Prozessflussdiagramm.

Wann einsetzen: Wenn du nicht weißt, wie ein Prozess tatsächlich abläuft — oder wenn du vermutest, dass die dokumentierte Prozessbeschreibung von der Realität abweicht. Das ist der häufigste Einstiegspunkt in Process Mining.

Was du bekommst: Ein visuelles Prozessmodell, das alle beobachteten Pfade zeigt — einschließlich seltener Varianten und Schleifen, die in manuellen Modellen typischerweise fehlen. Je nach Algorithmus zeigt das Modell auch Häufigkeiten (wie oft wird welcher Pfad genommen?) und Durchlaufzeiten (wie lange dauert jeder Schritt?).

Typisches Ergebnis: Ein Discovery-Durchlauf für einen Versicherungs-Schadenprozess mit 50.000 Fällen könnte zeigen, dass es nicht 8 Prozessschritte gibt (wie dokumentiert), sondern 23 beobachtete Varianten — wobei der “Happy Path” (der dokumentierte Standardprozess) nur in 34 % der Fälle tatsächlich durchlaufen wird.

2. Conformance Checking (Konformitätsprüfung)

Was es tut: Ein bestehendes Prozessmodell (Soll) wird mit den tatsächlichen Prozessdaten (Ist) verglichen. Jede Abweichung wird identifiziert und quantifiziert — sowohl Fälle, in denen Schritte übersprungen werden, als auch Fälle, in denen zusätzliche, nicht vorgesehene Schritte stattfinden.

Wann einsetzen: Wenn ein definierter Soll-Prozess existiert — etwa eine dokumentierte SOP, eine regulatorische Vorgabe oder ein zertifizierter Qualitätsprozess — und du prüfen willst, ob er eingehalten wird. Besonders relevant in regulierten Branchen: Banken (MaRisk, BaFin), Versicherungen (Solvency II), Gesundheitswesen (GxP).

Was du bekommst: Eine Abweichungsanalyse mit konkreten Zahlen: “In 23 % der Fälle wird Schritt 4 (Vier-Augen-Prüfung) übersprungen.” “In 11 % der Fälle findet eine nicht vorgesehene Rückschleife zwischen Schritt 3 und Schritt 5 statt.” “Die mittlere Abweichung vom Soll-Prozess beträgt 2,3 Schritte pro Fall.”

Typisches Ergebnis: Ein Conformance Check einer Kreditvergabe könnte zeigen, dass die regulatorisch geforderte KYC-Prüfung (Know Your Customer) in 7 % der Fälle erst nach der Kreditzusage stattfindet — ein Compliance-Risiko, das ohne datenbasierte Analyse unsichtbar geblieben wäre.

3. Enhancement (Prozessverbesserung)

Was es tut: Bestehende Prozessmodelle werden mit zusätzlichen Informationen aus den Daten angereichert — typischerweise Durchlaufzeiten, Wartezeiten, Ressourcenauslastung und Engpassanalysen. Während Discovery und Conformance den Prozessfluss selbst analysieren, fügt Enhancement die Leistungsdimension hinzu.

Wann einsetzen: Wenn du weißt, wie der Prozess läuft, aber nicht, wo die Engpässe liegen. Enhancement ist der natürliche nächste Schritt nach Discovery oder Conformance Checking.

Was du bekommst: Ein Prozessmodell, das nicht nur zeigt, welche Schritte existieren, sondern auch, wo Zeit verloren geht. Typische Erweiterungen: Heatmaps für Wartezeiten (welcher Übergang zwischen zwei Schritten dauert am längsten?), Engpassanalyse (welcher Schritt bremst den Gesamtprozess?), Ressourcenanalyse (welcher Sachbearbeiter-Typ bearbeitet am schnellsten/langsamsten?).

Typisches Ergebnis: Ein Enhancement-Durchlauf für einen Onboarding-Prozess könnte zeigen, dass 68 % der Gesamtwartezeit auf einen einzigen Übergang entfällt — die Zuweisung vom Antrag an den zuständigen Sachbearbeiter — weil diese manuell und nur einmal täglich erfolgt.

Die drei Typen im Zusammenspiel

In der Praxis werden die drei Typen iterativ eingesetzt:

Discovery als Einstieg — den tatsächlichen Prozess sichtbar machen
Conformance Checking als Abgleich — Abweichungen vom Soll quantifizieren
Enhancement als Vertiefung — Engpässe und Optimierungspotenziale identifizieren

Dieses Vorgehen ähnelt dem Muster, das die Wertstromanalyse beschreibt: Ist-Zustand aufnehmen, Verschwendung identifizieren, Soll-Zustand entwerfen. Der Unterschied: Process Mining tut dies datenbasiert und kann Hunderttausende Fälle gleichzeitig analysieren, während die Wertstromanalyse qualitativ am einzelnen Prozess arbeitet.

Wann eignet sich Process Mining?

Nutze Process Mining, wenn:

Dein Prozess in IT-Systemen protokolliert wird (ERP, CRM, Ticketsystem, BPM-Suite) und du Event-Logs extrahieren kannst
Du viele Prozessinstanzen hast (Hunderte bis Millionen Fälle) und manuelle Analyse nicht skaliert
Du wissen willst, wie der Prozess wirklich läuft — nicht wie er laut Dokumentation laufen sollte
Du Abweichungen quantifizieren musst — etwa für Compliance, Audit oder Regulatorik
Du Engpässe datenbasiert identifizieren willst, statt auf Vermutungen zu baün
Du einen KPI-Dashboard aufbaün willst und Basisdaten zu Durchlaufzeiten und Prozessvarianten brauchst

Nutze ein anderes Werkzeug, wenn:

Situation	Bessere Alternative	Warum
Der Prozess hat keine digitalen Spuren (kein Ticketsystem, keine Logs)	Wertstromanalyse	VSM arbeitet mit Beobachtung, Process Mining braucht Daten
Du willst die Kundenperspektive auf den Service verstehen	Service Blueprint oder Customer Journey Map	Process Mining zeigt interne Prozesse, nicht das Kundenerlebnis
Du willst Ursachen eines einzelnen Problems analysieren	Ishikawa-Diagramm	Ishikawa erklärt Warum, Process Mining zeigt Was und Wie lange
Du hast wenige Fälle (unter 50)	Manülle Prozessanalyse	Process Mining braucht Volumen für aussagekräftige Muster
Du willst einen neün Prozess entwerfen, nicht einen bestehenden analysieren	Service Design	Process Mining analysiert Bestehendes, Service Design entwirft Neüs

Schritt für Schritt: Process Mining in der Serviceoptimierung

Schritt 1: Zielsetzung und Scope definieren

Bevor du Daten extrahierst, definiere präzise, was du herausfinden willst. Ein Process-Mining-Projekt ohne klare Fragestellung produziert beeindruckende Visualisierungen — und keine Entscheidungen.

Typische Fragestellungen für Serviceprozesse:

Fragestellung	Process-Mining-Typ	Beispiel
”Wie läuft der Prozess wirklich ab?”	Discovery	Schadenmeldungsprozess einer Versicherung
”Halten wir unsere SLAs ein?”	Conformance	Erstlösungszeit im IT-Support
”Wo verlieren wir die meiste Zeit?”	Enhancement	Onboarding-Prozess einer Bank
”Warum dauern manche Fälle 10x länger?”	Discovery + Enhancement	Kreditprüfung mit hoher Varianz

Tipp: Formuliere die Zielsetzung als konkrete, messbare Frage — nicht als vagen Wunsch. “Wir wollen unsere Prozesse verstehen” ist keine Zielsetzung. “Wir wollen wissen, warum 15 % unserer Schadensfälle länger als 21 Tage dauern” ist eine.

Schritt 2: Event-Log-Daten extrahieren

Das Event Log ist das Rohmaterial für Process Mining. Jeder Eintrag in einem Event Log beschreibt ein Ereignis: Was wurde getan, wann wurde es getan, und in welchem Fall (Case ID) fand es statt.

Mindestanforderung an ein Event Log:

Feld	Beschreibung	Beispiel
Case ID	Eindeutige Kennung des Falls	Schadennummer SCH-2025-004712
Activity	Name der durchgeführten Aktivität	”Vollständigkeitsprüfung”
Timestamp	Zeitpunkt der Aktivität	2025-11-14 09:23:17

Optionale, aber wertvolle Felder:

Feld	Beschreibung	Nutzen
Resource	Wer hat die Aktivität durchgeführt?	Ressourcenanalyse, Workload-Verteilung
Cost	Kosten der Aktivität	Kostenbasierte Optimierung
Additional Attributes	Schadenart, Schadensumme, Kundentyp	Segmentierung, Vergleichsanalysen

Typische Qüllen für Event Logs im Servicekontext:

CRM-Systeme (Salesforce, HubSpot): Kundenanfragen, Ticketverlauf
ERP-Systeme (SAP, Oracle): Bestell-, Beschaffungs-, Schadenabwicklung
Ticketsysteme (ServiceNow, Jira): IT-Support, Servicedesk
BPM-Suiten (Camunda, Bizagi): Workflow-Daten mit Zeitstempeln
Eigenentwicklungen: Datenbankprotokolle, Anwendungslogs

Häufige Datenprobleme (und Lösungen):

Problem	Auswirkung	Lösung
Fehlende Zeitstempel	Keine Durchlaufzeitanalyse möglich	Datenquelle wechseln oder Logging ergänzen
Inkonsistente Aktivitätsnamen	”Prüfung”, “Check”, “Review” meinen dasselbe	Vorher harmonisieren (Mapping-Tabelle)
Fehlende Case ID	Keine Zuordnung möglich	Zusammengesetzten Key bilden (z.B. Kundennr + Datum)
Zu grobe Granularität	Nur Start und Ende sichtbar, keine Zwischenschritte	Feinere Logging-Ebene aktivieren

Van der Aalst betont: “80 % des Aufwands in einem Process-Mining-Projekt entfällt auf die Datenextraktion und -aufbereitung” [1]. Plane diesen Schritt nicht als Vorbereitung, sondern als Kernarbeit.

Schritt 3: Prozessmodell generieren (Discovery)

Lade das bereinigte Event Log in ein Process-Mining-Tool und lasse einen Discovery-Algorithmus laufen. Die Wahl des Algorithmus beeinflusst das Ergebnis:

Algorithmus	Stärke	Schwäche	Geeignet für
Alpha Miner	Einfach, schnell	Kann mit Rauschen und komplexen Mustern nicht umgehen	Einfache, strukturierte Prozesse
Heuristic Miner	Robust gegen Rauschen	Kann seltene Pfade übersehen	Reale Prozesse mit Varianten
Inductive Miner	Garantiert “Sound” Modelle	Kann überverallgemeinern	Komplexe Prozesse, Compliance
Fuzzy Miner	Vereinfacht komplexe Modelle visuell	Verliert Details	Erste Orientierung, Management-Präsentationen

Praxistipp: Starte mit dem Heuristic Miner oder Inductive Miner. Diese Algorithmen liefern für die meisten Serviceprozesse brauchbare Ergebnisse. Der Alpha Miner ist eher akademisch relevant; der Fuzzy Miner eignet sich für die erste Visualisierung, nicht für tiefe Analyse.

Schritt 4: Analysieren und interpretieren

Das generierte Prozessmodell ist der Anfang, nicht das Ergebnis. Jetzt beginnt die eigentliche Analyse:

Varianten-Analyse: Wie viele unterschiedliche Pfade gibt es durch den Prozess? Wie häufig wird jeder Pfad genommen? Welche Varianten sind “Happy Paths” (Standardabläufe) und welche sind Ausnahmen?

Engpass-Analyse: Wo entsteht die längste Wartezeit? Welcher Übergang zwischen zwei Schritten bremst den Gesamtprozess? Diese Analyse ähnelt dem, was die Wertstromanalyse mit der Zeitlinie tut — nur automatisiert und für Tausende Fälle gleichzeitig.

Rückschleifen-Analyse: Wo entstehen Schleifen — Fälle, die zwischen zwei Schritten hin- und herspringen? Schleifen sind ein starker Indikator für Nacharbeit, Rückfragen oder unklare Prozessregeln.

Segmentierung: Unterscheidet sich das Prozessverhalten nach Kundentyp, Schadensumme, Region oder Sachbearbeiter? Segmentierung deckt systematische Unterschiede auf — etwa, dass Fälle von Sachbearbeiter-Team A im Schnitt 3 Tage schneller abgeschlossen werden als die von Team B.

Schritt 5: Maßnahmen ableiten und umsetzen

Process Mining liefert Diagnosen, keine Therapien. Die Interpretation der Ergebnisse und die Ableitung von Maßnahmen erfordert Prozesswissen — genau hier ergänzen sich Process Mining und qualitative Methoden.

Typische Maßnahmen nach einer Process-Mining-Analyse:

Befund	Mögliche Massnahme	Methode zur Vertiefung
68 % der Wartezeit in einem Übergang	Automatische Zuweisung statt manueller Batch-Verarbeitung	Wertstromanalyse für Detail
23 % der Fälle übersprungen Prüfschritt	Prozessregel verschärfen oder Pflichtfeld einbaün	Conformance Monitoring
15 % Rückschleifen wegen Rückfragen	Eingabemaske verbessern, Pflichtfelder ergänzen	Service Blueprint für Kundenperspektive
Hohe Varianz nach Sachbearbeiter	Schulung, Best-Practice-Dokumentation	Gemba Walk zur Ursachenforschung

Beispiel: Process Mining im Versicherungs-Schadenprozess

Kontext: Ein deutscher Kfz-Versicherer mit 120.000 Schadenfällen pro Jahr stellt fest, dass die Kundenzufriedenheit (CSAT) in den letzten 12 Monaten um 8 Prozentpunkte gefallen ist. Die Hypothese: Die Durchlaufzeiten sind zu lang. Aber welche Fälle sind betroffen, und wo genau entsteht die Verzögerung?

Discovery-Ergebnis

Das Process-Mining-Team extrahiert Event Logs aus dem Schadenmanagementsystem (SAP Claims Management) für die letzten 12 Monate: 118.000 Fälle mit insgesamt 1,2 Millionen Ereignissen.

Überraschendes Ergebnis:

Kennzahl	Erwartung	Realität
Prozessvarianten	8 (laut SOP)	147 beobachtete Varianten
Happy-Path-Quote	>80 %	29 %
Mittlere Durchlaufzeit	7 Tage (SLA)	11,3 Tage (Median), 28 Tage (90. Perzentil)
Top-Engpass	Vermutet: Gutachter	Tatsächlich: Sachbearbeiter-Zuweisung (3,2 Tage Wartezeit)

Conformance-Ergebnis

Der Abgleich mit dem dokumentierten Soll-Prozess zeigt:

12 % der Fälle überspringen die Vollständigkeitsprüfung
8 % der Fälle durchlaufen eine nicht vorgesehene Schleife zwischen Bewertung und Genehmigung (Rückfragen an den Kunden, die nicht im Soll-Prozess vorgesehen sind)
22 % der Fälle haben einen Schritt “Manülle Datenübernahme”, der im Soll-Prozess nicht existiert — ein Workaround für eine fehlende Systemintegration

Enhancement-Ergebnis

Die Engpassanalyse zeigt die Verteilung der Wartezeit:

Übergang	Mittlere Wartezeit	Anteil an Gesamtwartezeit
Eingang → Sachbearbeiter-Zuweisung	3,2 Tage	31 %
Bewertung → Genehmigung	2,1 Tage	20 %
Vollständigkeitsprüfung → Bewertung	1,8 Tage	17 %
Genehmigung → Auszahlung	1,4 Tage	14 %
Übrige Übergänge	1,8 Tage	18 %

Die Kernerkenntnisse:

Der vermutete Engpass (Gutachter) war nicht der tatsächliche Engpass. Die Sachbearbeiter-Zuweisung — ein scheinbar trivialer Schritt — verursacht 31 % der Gesamtwartezeit, weil sie manuell und in Tages-Batches erfolgt.
22 % der Fälle enthalten einen informellen Workaround (“Manülle Datenübernahme”), der im Soll-Prozess nicht existiert. Dieser Schritt kostet pro Fall 12 Minuten und wird 26.000 Mal pro Jahr ausgeführt — das sind 5.200 Arbeitsstunden, die durch eine Systemintegration eliminiert werden könnten.
Die 90.-Perzentil-Fälle (28 Tage) haben ein gemeinsames Muster: Sie durchlaufen im Schnitt 2,7 Rückschleifen, weil bei der Erstmeldung Daten fehlen.

Hinweis: Dieses Beispiel ist illustrativ konstruiert, um Process Mining im Servicekontext zu demonstrieren. Die Zahlen basieren auf typischen Branchenwerten für Kfz-Schadenabwicklung in Deutschland.

Abgeleitete Maßnahmen

Massnahme	Erwarteter Effekt	Priorität
Regelbasierte automatische Zuweisung im CRM	-3 Tage bei 100 % der Fälle	Hoch
Intelligente Formularvalidierung (Pflichtfelder + Foto-Upload)	-1,5 Rückschleifen bei 22 % der Fälle	Hoch
API-Integration zwischen Schadensystem und Archiv	-12 Min. bei 22 % der Fälle (5.200 h/Jahr)	Mittel
Genehmigungsgrenze auf 2.000 EUR erhöhen	-2 Tage bei 65 % der Fälle	Mittel

Process Mining und Serviceinnovation: Die strategische Perspektive

Die meisten Darstellungen von Process Mining enden bei der operativen Prozessoptimierung: schneller, schlanker, weniger Fehler. Das ist wertvoll — aber es ist nur die halbe Wahrheit.

Process Mining als Sensor für Serviceinnovation:

Wenn du Process Mining nicht nur als Effizienztool, sondern als Erkenntnistool betrachtest, öffnet sich eine strategische Perspektive: Die Daten zeigen nicht nur, wo der Prozess langsam ist, sondern auch, wo der Service das Kundenbedürfnis verfehlt.

147 Prozessvarianten in einem Schadenprozess bedeuten nicht nur Ineffizienz — sie bedeuten, dass der Standardprozess für 71 % der Fälle nicht passt. Das ist ein Hinweis auf ein Serviceproblem, nicht nur auf ein Prozessproblem.
2,7 Rückschleifen bei den langsamsten Fällen bedeuten nicht nur Zeitverlust — sie bedeuten, dass die Schnittstelle zum Kunden (die Erstmeldung) nicht funktioniert. Das ist ein Customer Journey-Problem.
22 % informelle Workarounds bedeuten nicht nur Compliance-Risiko — sie bedeuten, dass Mitarbeiter den offiziellen Prozess als unzureichend empfinden und selbst Lösungen entwickeln. Diese Workarounds sind häufig die Keimzelle für bessere Serviceprozesse.

Die Verbindung zum Integrierten Service Entstehungs Prozess (iSEP): Process Mining liefert die datenbasierte Grundlage für die Analysephase der Serviceentwicklung. Statt auf Annahmen zu baün (“Wir glauben, der Prozess ist zu langsam”), startest du mit Fakten (“Die Daten zeigen, dass 31 % der Wartezeit auf einen einzigen Übergang entfallen”). Diese datenbasierte Diagnose macht den Übergang von der Analyse zur Serviceentwicklung präziser — und reduziert das Risiko, am falschen Problem zu arbeiten.

Wann Process Mining NICHT funktioniert

Kein Werkzeug passt für jedes Problem. Diese Einschränkungen solltest du kennen:

1. Prozesse ohne digitale Spuren: Process Mining braucht Event Logs. Wenn dein Serviceprozess überwiegend analog abläuft — mündliche Absprachen, Papierformulare, informelle Entscheidungen — gibt es keine Daten zum Analysieren. Starte in diesem Fall mit der Wertstromanalyse oder einem Gemba Walk.

2. Zu wenige Fälle: Process Mining entfaltet seine Stärke durch Volumen. Bei 50 Fällen pro Jahr ist eine manuelle Analyse oft effizienter. Als Faustregel: Unter 200-300 Fällen pro Analysezeitraum liefert Process Mining selten robuste Muster.

3. Garbage In, Garbage Out: Schlechte Datenqualität führt zu irreführenden Prozessmodellen. Wenn Aktivitätsnamen inkonsistent sind, Zeitstempel fehlen oder Case IDs nicht eindeutig zugeordnet werden können, zeigt das Ergebnis ein Zerrbild des Prozesses — nicht die Realität. Die Datenaufbereitung ist kein optionaler Vorschritt, sondern entscheidend für die Qualität der Analyse [1][4].

4. Die Illusion der Objektivität: Process Mining zeigt, was passiert, nicht warum. Ein Engpass bei der Sachbearbeiter-Zuweisung könnte an mangelnder Kapazität liegen, an einem schlechten Tool, an organisatorischen Regeln oder an fehlendem Wissen. Die Ursachenforschung erfordert qualitative Methoden — Interviews, Beobachtung, Ishikawa-Analyse. Wer Process-Mining-Ergebnisse ohne Kontextwissen interpretiert, “springt zu Schlussfolgerungen, die möglicherweise nicht relevant sind” [5].

5. Widerstand gegen Transparenz: Process Mining macht Prozesse radikal transparent — inklusive Workarounds, Regelverstösse und Leistungsunterschiede zwischen Teams. Das kann politisch heikel sein. Ohne ein klares Mandat der Führungsebene und eine konstruktive Fehlerkultur wird Process Mining zur Überwachungstechnologie statt zum Verbesserungswerkzeug.

6. Der Directly-Follows-Graph als Falle: Viele kommerzielle Tools generieren als erstes Ergebnis einen Directly-Follows-Graph (DFG) — eine einfache Darstellung, die zeigt, welche Aktivitäten direkt aufeinander folgen. DFGs sind intuitiv lesbar, können aber “irreführend sein, wenn man nicht versteht, wie sie generiert werden” [6]. Sie können kausale Zusammenhänge suggerieren, die nicht existieren, und seltene aber wichtige Pfade verbergen.

Object-Centric Process Mining: Die nächste Generation

Klassisches Process Mining hat eine fundamentale Einschränkung: Jedes Ereignis wird genau einer Fall-ID zugeordnet. In der Realität interagieren Prozesse aber mit mehreren Objekten gleichzeitig — eine Bestellung hat mehrere Positionen, ein Kundenvorgang betrifft mehrere Verträge, eine Schadenmeldung involviert mehrere Parteien.

Object-Centric Process Mining (OCPM) — maßgeblich von van der Aalst und seinem Team an der RWTH Aachen vorangetrieben — löst diese Einschränkung [7]. Statt einer einzigen Case ID kann jedes Ereignis mit mehreren Objekten verknüpft werden. Das ermöglicht die Analyse von Prozessen, in denen mehrere Objekte parallel und interagierend verarbeitet werden.

Für Serviceprozesse ist das besonders relevant: Ein Kundenvorgang (Objekt 1) löst eine interne Prüfung (Objekt 2) und eine externe Gutachterbeauftragung (Objekt 3) aus — alle drei Objekte haben eigene Prozessverläufe, die miteinander interagieren. Klassisches Process Mining kann das nicht abbilden; OCPM kann es.

OCPM befindet sich Stand 2026 noch im Übergang von der Forschung in die breitere Praxisanwendung. Erste kommerzielle Tools (Celonis, ProM) unterstützen OCPM, aber die Datenaufbereitung ist komplexer als beim klassischen Ansatz [7].

Process-Mining-Tools: Eine Orientierung

Tool	Typ	Stärke	Geeignet für
Celonis	Kommerziell	Marktführer, starke SAP-Integration, Execution Management	Grossunternehmen mit SAP-Landschaft
Signavio (SAP)	Kommerziell	Integration mit SAP BPM, Prozessmodellierung	SAP-Umgebungen, BPM-affine Organisationen
UiPath Process Mining	Kommerziell	Integration mit RPA (Robotic Process Automation)	Automatisierungsprojekte
ProM	Open Source	Akademisch fundiert, umfangreiche Algorithmen	Forschung, Evaluation, kleine Teams
PM4Py	Open Source (Python)	Programmatischer Zugang, Fraunhofer FIT	Data-Science-Teams, individuelle Analysen
Disco (Fluxicon)	Kommerziell	Einfache Bedienung, schnelle Ergebnisse	Einstieg, Exploration, Workshops

Empfehlung: Für den Einstieg eignet sich ProM (kostenlos, akademisch umfangreich) oder Disco (kommerziell, aber sehr benutzerfreundlich). Für unternehmensweite Implementierung sind Celonis oder Signavio die gängigen Optionen. Für datenaffine Teams ist PM4Py — entwickelt von Fraunhofer FIT — eine leistungsfähige Python-Bibliothek [8].

Häufig gestellte Fragen

Was ist Process Mining einfach erklärt?

Process Mining ist eine Methode, bei der Software automatisch analysiert, wie Geschäftsprozesse tatsächlich ablaufen — basierend auf den Spuren, die Prozesse in IT-Systemen hinterlassen (sogenannte Event Logs). Statt einen Prozess am Whiteboard zu zeichnen und zu hoffen, dass die Zeichnung stimmt, zeigt Process Mining den realen Prozess mit all seinen Varianten, Schleifen und Wartezeiten. Die Methode wurde von Wil van der Aalst ab den 1990er-Jahren entwickelt [1].

Was ist der Unterschied zwischen Process Mining und Data Mining?

Data Mining sucht nach Mustern in Daten generell — etwa Kaufverhalten, Risikomuster oder Anomalien. Process Mining ist eine spezialisierte Form des Data Mining, die sich ausschließlich auf Prozessdaten konzentriert: zeitlich geordnete Ereignisse, die zu einem Fall (Case) gehören. Während Data Mining fragt “Welche Muster gibt es in den Daten?”, fragt Process Mining “Wie läuft dieser Prozess tatsächlich ab?” [1].

Welche Daten braucht man für Process Mining?

Mindestens drei Felder pro Ereignis: eine Fall-ID (welcher Vorgang?), einen Aktivitätsnamen (was wurde getan?) und einen Zeitstempel (wann?). Zusätzliche Felder wie Bearbeiter, Kosten oder Kundentyp ermöglichen tiefere Analysen, sind aber nicht zwingend. Die Daten stammen typischerweise aus ERP-, CRM- oder Ticketsystemen.

Was kostet Process Mining?

Die Kosten variieren stark: Open-Source-Tools wie ProM oder PM4Py sind kostenlos. Kommerzielle Einstiegslösungen (Disco, kleinere Anbieter) liegen bei wenigen Tausend Euro pro Jahr. Enterprise-Plattformen (Celonis, Signavio) kosten typischerweise sechsstellige Jahresbeträge — abhängig von Datenvolumen, Nutzerzahl und Modulen. Der grösste Kostenfaktor ist nicht die Software, sondern die Datenextraktion und -aufbereitung (typischerweise 60-80 % des Projektbudgets) [1].

Wie unterscheidet sich Process Mining von der Wertstromanalyse?

Beide Methoden analysieren Prozesse, aber auf unterschiedliche Weise: Die Wertstromanalyse basiert auf menschlicher Beobachtung und arbeitet qualitativ an einzelnen Prozessen. Process Mining basiert auf Systemdaten und kann Hunderttausende Fälle automatisiert analysieren. Die Wertstromanalyse erfasst den menschlichen Kontext (Workarounds, Frustration, informelle Wege); Process Mining erfasst den datenbasierten Kontext (Häufigkeiten, Durchlaufzeiten, Varianten). Am stärksten ist die Kombination beider Methoden.

Ist Process Mining das Gleiche wie Process Intelligence?

Process Intelligence ist der übergeordnete Begriff für die datengetriebene Analyse und Steuerung von Geschäftsprozessen. Process Mining ist eine Kernmethode innerhalb von Process Intelligence, ergänzt um Real-Time-Monitoring, Predictive Analytics und automatisierte Prozessoptimierung. Man könnte sagen: Process Mining ist die analytische Grundlage, Process Intelligence ist die breitere Disziplin, die auch Echtzeit-Überwachung und Prognosen umfasst.

Forschungsmethodik

Dieser Artikel synthetisiert Erkenntnisse aus den Grundlagenwerken von Wil van der Aalst (Process Mining: Data Science in Action, 2016), dem IEEE Process Mining Manifesto (2011), der Fraunhofer-FIT-Forschung zu Open-Source-Process-Mining sowie der Analyse von 10 deutschsprachigen Fachbeiträgen zu Process Mining. Die Qüllen wurden nach akademischem Rigor, Praxisrelevanz und Aktualität ausgewählt. Das Praxisbeispiel (Versicherungs-Schadenprozess) ist illustrativ konstruiert, um die Methode im Servicekontext zu demonstrieren — nicht eine dokumentierte Fallstudie.

Limitationen: Die akademische Literatur zu Process Mining stammt überwiegend aus ERP-nahen Kontexten (Einkauf, Logistik, Buchhaltung). Empirische Studien zur Anwendung in der Serviceinnovation — insbesondere in der Neugestaltung von Dienstleistungen, nicht nur ihrer Optimierung — sind begrenzt.

Offenlegung

SI Labs bietet Beratungsleistungen im Bereich Service Innovation an. Im Integrierten Service Entstehungs Prozess (iSEP) empfehlen wir Process Mining als datenbasierte Grundlage für die Analysephase, wenn ausreichend Event-Log-Daten verfügbar sind. SI Labs ist kein Anbieter von Process-Mining-Software und hat keine kommerziellen Beziehungen zu den in diesem Artikel genannten Tool-Anbietern.

Quellenverzeichnis

[1] van der Aalst, Wil M. P. Process Mining: Data Science in Action. 2. Auflage. Berlin: Springer, 2016. ISBN: 978-3-662-49851-4 [Grundlagenwerk | Process Mining | Zitationen: 6.000+ | Qualität: 95/100]

[2] van der Aalst, Wil M. P. “Process Mining: Overview and Opportunities.” ACM Transactions on Management Information Systems 3, Nr. 2 (2012): Artikel 7. DOI: 10.1145/2229156.2229157 [Journal Article | Übersicht | Zitationen: 1.500+ | Qualität: 90/100]

[3] van der Aalst, Wil M. P., et al. “Process Mining Manifesto.” Business Process Management Workshops, Lecture Notes in Business Information Processing, Band 99. Berlin: Springer, 2012, S. 169-194. DOI: 10.1007/978-3-642-28108-2_19 [IEEE Task Force | Manifest | Zitationen: 2.000+ | Qualität: 92/100]

[4] Mans, Ronny S., Wil M. P. van der Aalst, und Rob J. B. Vanwersch. Process Mining in Healthcare: Evaluating and Exploiting Operational Healthcare Processes. Cham: Springer, 2015. ISBN: 978-3-319-16071-9 [Fachbuch | Healthcare Process Mining | Zitationen: 300+ | Qualität: 82/100]

[5] Reinkemeyer, Lars, Hrsg. Process Mining in Action: Principles, Use Cases and Outlook. Cham: Springer, 2020. ISBN: 978-3-030-40171-9 [Praxisbuch | Use Cases | Zitationen: 150+ | Qualität: 78/100]

[6] van der Aalst, Wil M. P. “A Practitioner’s Guide to Process Mining: Limitations of the Directly-Follows Graph.” Procedia Computer Science 164 (2019): 321-328. DOI: 10.1016/j.procs.2019.12.189 [Conference Paper | Methodik-Kritik | Zitationen: 200+ | Qualität: 85/100]

[7] van der Aalst, Wil M. P., und Alessandro Berti. “Discovering Object-Centric Petri Nets.” Fundamenta Informaticae 175, Nr. 1-4 (2020): 1-40. DOI: 10.3233/FI-2020-1946 [Journal Article | OCPM | Zitationen: 200+ | Qualität: 88/100]

[8] Berti, Alessandro, Sebastiaan J. van Zelst, und Wil M. P. van der Aalst. “Process Mining for Python (PM4Py): Bridging the Gap Between Process- and Data Science.” ICPM Demo Track (CEUR 2374), 2019. [Conference Paper | Tool | Fraunhofer FIT | Qualität: 75/100]

← Alle Artikel