Process Mining: Automatisierungspotenziale aus realen Abläufen erkennen

Viele Unternehmen haben einen dokumentierten Sollprozess – ein Flussdiagramm, eine Verfahrensanweisung, eine Folie aus dem letzten Reorganisationsprojekt. Und einen tatsächlichen Prozess, der davon abweicht: zusätzliche Rückfragen, Sonderwege für „wichtige” Kunden, ein Excel-Zwischenschritt, den offiziell niemand kennt. Diese Lücke ist der Grund, warum Automatisierungsprojekte oft an der Praxis vorbeigeplant werden – man automatisiert den Prozess auf dem Papier, nicht den, der tatsächlich läuft.

Dieser Artikel ist Teil unseres Themen-Clusters Prozessautomatisierung und beantwortet die zentrale Frage vor jeder Automatisierungsentscheidung: Wie findet man heraus, was in einem Prozess wirklich passiert – und wann lohnt sich dafür ein eigenes Werkzeug? Er richtet sich an Geschäftsführung, Operations, IT und Fachbereiche in kleinen und mittleren Unternehmen, die selten ein eigenes Process-Mining-Team haben und trotzdem tragfähige Entscheidungen treffen müssen.

Begriffe kurz geklärt

• Process Mining ist eine Analysemethode, die aus digitalen Spuren in IT-Systemen – den sogenannten Event-Logs – automatisiert rekonstruiert, wie ein Prozess tatsächlich abläuft. Microsoft beschreibt es treffend als Werkzeug, um „reale Prozesse” zu verstehen, statt sich auf die dokumentierte Soll-Vorstellung zu verlassen.
• Event-Log ist die Datengrundlage: eine Tabelle, in der jede Zeile ein Ereignis beschreibt – wann welcher Schritt zu welchem Vorgang stattgefunden hat. Für den Austausch solcher Daten zwischen Werkzeugen gibt es mit XES ein offenes, von der IEEE Task Force on Process Mining gepflegtes Format.
• Sollprozess vs. Istprozess. Der Sollprozess ist das, was dokumentiert oder vereinbart wurde. Der Istprozess ist das, was die Systemdaten belegen. Process Mining macht die Differenz zwischen beiden sichtbar – oft zum ersten Mal mit belastbaren Zahlen statt mit Vermutungen.
• Prozessvariante ist ein konkreter, tatsächlich durchlaufener Ablaufpfad. Ein Prozess mit fünf Schritten hat auf dem Papier oft „einen” Ablauf, in der Praxis aber zehn, zwanzig oder mehr Varianten, je nachdem, wie oft Schritte übersprungen, wiederholt oder in anderer Reihenfolge durchlaufen werden.
• Abgrenzung zu Process Mapping/Dokumentation: Klassische Prozessdokumentation entsteht aus Interviews und Beobachtung – sie zeigt, was Beteiligte berichten oder was vereinbart wurde. Process Mining entsteht aus geloggten Systemdaten – es zeigt, was tatsächlich passiert ist. Beide Methoden ergänzen sich, ersetzen sich aber nicht: Wie du einen Prozess strukturiert dokumentierst, behandelt der Cluster-Artikel zum Thema Prozessdokumentation.

Was ist Process Mining?

Process Mining setzt an einer einfachen Beobachtung an: Fast jedes System, mit dem Mitarbeitende arbeiten – CRM, Ticketsystem, ERP, Dokumentenmanagement –, protokolliert im Hintergrund, wann welcher Schritt an welchem Vorgang stattgefunden hat. Diese Protokolle sind meist nicht für Analysezwecke gebaut, enthalten aber genau die Information, die man braucht, um einen Prozess nachzuzeichnen. Process-Mining-Software liest diese Protokolle aus, ordnet die Ereignisse pro Vorgang chronologisch an und baut daraus automatisch ein Prozessdiagramm – inklusive aller tatsächlich durchlaufenen Varianten, nicht nur des Idealwegs.

Der praktische Unterschied zu klassischer Prozessanalyse: Man befragt nicht in erster Linie Menschen über ihre Erinnerung an den Ablauf, sondern lässt die Daten sprechen. Das ist kein Ersatz für das Gespräch mit den Beteiligten – warum ein Schritt oft übersprungen wird, erklärt sich meist erst im Gespräch –, aber es liefert eine objektive Ausgangsbasis, an der sich diese Gespräche orientieren können, statt bei „wie sollte es eigentlich laufen” zu beginnen.

Typische Einsatzfelder, die Microsoft für seine Process-Mining-Fähigkeit nennt, liegen unter anderem in Kundenservice, Finanzprozessen, Fertigung und Lieferkette – überall dort, wo Vorgänge mit klarer Fallkennung (Ticket, Bestellung, Rechnung) durch mehrere Schritte und oft mehrere Systeme laufen.

Welche Daten braucht man?

Für eine Process-Mining-Analyse reichen im Kern drei Datenfelder pro Ereignis, wie sie sowohl Microsoft für seine Process-Mining-Fähigkeit als auch der von der IEEE Task Force on Process Mining gepflegte XES-Standard als Grundgerüst voraussetzen:

Feld	Bedeutung	Beispiel
Case ID (Fallkennung)	Eindeutige ID des Vorgangs, auf den sich der Schritt bezieht	Ticket-Nr., Bestell-Nr., Rechnungs-Nr.
Aktivität	Name des Prozessschritts	„Anfrage eingegangen”, „Freigabe erteilt”
Zeitstempel	Wann der Schritt stattgefunden hat	14.03.2026, 09:12 Uhr

Zusätzlich lassen sich optionale Attribute anreichern, etwa wer eine Aktivität ausgeführt hat (Ressource), welche Abteilung beteiligt war, oder ein finanzieller Wert pro Vorgang – das erweitert die Analyse, ist aber für den Einstieg nicht zwingend.

In der Praxis ist die größte Hürde selten die Analyse-Software, sondern das Zusammentragen der Daten: Viele Systeme speichern den aktuellen Stand eines Vorgangs, aber nicht dessen vollständige Historie – die relevanten Ereignisse liegen dann in separaten Protokoll- oder Aktivitätentabellen, die man erst gemeinsam mit der IT identifizieren muss. Bei größeren Anwendungen wie CRM- oder ERP-Systemen existieren solche Historientabellen häufig bereits, sind aber nicht immer für den fachlichen Blick zugänglich aufbereitet.

Welche Abweichungen werden sichtbar?

Ein Process-Mining-Modell macht typischerweise fünf Arten von Abweichungen sichtbar, die in klassischen Prozessdokumentationen kaum auftauchen, weil sie niemand aktiv berichtet:

1. Zusätzliche oder vertauschte Schritte. Vorgänge, die einen im Sollprozess nicht vorgesehenen Schritt durchlaufen, oder bei denen die Reihenfolge vom dokumentierten Ablauf abweicht.
2. Schleifen. Ein Schritt wird mehrfach durchlaufen – etwa eine Freigabe, die zweimal angefragt werden muss, weil die erste Einreichung unvollständig war. Schleifen sind oft der deutlichste Hinweis auf Nacharbeit.
3. Liegezeiten. Die Zeit zwischen zwei Schritten, in der scheinbar nichts passiert. Diese Wartezeiten summieren sich in vielen Prozessen zum größten Teil der Gesamtdurchlaufzeit – deutlich mehr als die reine Bearbeitungszeit.
4. Seltene Varianten. Pfade, die nur wenige Vorgänge durchlaufen, aber überproportional viel Zeit oder Aufwand binden. Sie sind oft die eigentlichen Sonderfälle, für die klassische Prozessdokumentation blind ist, weil niemand sie als „den” Prozess beschreibt.
5. Engpässe an bestimmten Stationen. Schritte, an denen auffällig viele Vorgänge hängen bleiben oder auf eine bestimmte Person oder Rolle warten – ein klarer Kandidat für Kapazitäts- oder Zuständigkeitsprobleme.

Wichtig für die Einordnung: Process Mining zeigt, dass und wo eine Abweichung existiert, aber nicht automatisch warum. Ob eine Schleife ein Qualitätsproblem, eine unklare Zuständigkeit oder ein legitimer fachlicher Sonderfall ist, klärt sich erst im Gespräch mit den Beteiligten.

Wann reicht eine manuelle Analyse?

Nicht jeder Prozess braucht ein eigenes Analysewerkzeug. Aus meiner Projekterfahrung lohnt sich der Einsatz von Process Mining vor allem, wenn mehrere der folgenden Merkmale zutreffen – bei wenigen oder keinem davon reichen strukturierte Interviews, eine kurze Beobachtung vor Ort und eine einfache Ablaufskizze meist aus:

Merkmal	Manuelle Analyse reicht meist	Process Mining lohnt sich eher
Prozessvolumen	Wenige Dutzend Vorgänge im Betrachtungszeitraum	Hunderte bis tausende Vorgänge
Anzahl beteiligter Systeme	Ein System, überschaubar	Mehrere Systeme, verstreute Historie
Wahrgenommene Prozessvarianz	Beteiligte beschreiben den Ablauf übereinstimmend	Beteiligte beschreiben ihn unterschiedlich
Datenverfügbarkeit	Kaum digitale Spuren vorhanden	Event-Log-fähige Daten liegen bereits vor
Ziel der Analyse	Grobes Verständnis für eine Entscheidung	Belastbare Priorisierung mehrerer Automatisierungskandidaten

Eigene Entscheidungshilfe Philogic Labs, aus Beratungsprojekten abgeleitet.

Eine ehrliche Ergänzung: Für ein kleines Unternehmen mit einem überschaubaren, gut verstandenen Kernprozess ist der Aufwand für ein Process-Mining-Projekt – Datenextraktion, Aufbereitung, Tool-Lizenz – oft größer als der Erkenntnisgewinn gegenüber einem guten Interview mit den zwei oder drei Personen, die den Prozess täglich ausführen. Process Mining zahlt sich vor allem dort aus, wo die Datenmenge oder die Zahl der Beteiligten menschliche Beobachtung an ihre Grenzen bringt.

Wie führt Process Mining zu Automation?

Process Mining ersetzt keine Automatisierungsentscheidung – es liefert die Grundlage dafür, in drei Schritten:

1. Priorisierung. Statt zu raten, welcher Prozess am meisten Zeit bindet, zeigt die Analyse, wo Volumen, Liegezeiten und Schleifen tatsächlich konzentriert sind. Das verhindert, dass Automatisierungsbudget in den lautesten statt den wirklich teuersten Prozess fließt.

2. Eingrenzung des Automatisierungskandidaten. Innerhalb eines Prozesses zeigt die Variantenanalyse, welcher Teilschritt am stärksten standardisiert abläuft (viele Vorgänge folgen demselben Pfad) und welcher Teil die eigentliche Komplexität trägt. Oft ist nicht der ganze Prozess automatisierbar, sondern nur ein klar abgegrenzter, regelmäßiger Kernablauf – während Ausnahmen bewusst bei Menschen bleiben.

3. Erfolgsmessung. Weil Process Mining den Ist-Zustand vor einer Veränderung dokumentiert, liefert es automatisch die Vergleichsbasis für danach: Wie hat sich die durchschnittliche Durchlaufzeit verändert? Sind Schleifen zurückgegangen? Ohne diese Vorher-Messung bleibt jede Aussage über den Erfolg einer Automatisierung eine Behauptung.

Was Process Mining nicht leistet: die Entscheidung, ob ein Schritt regelbasiert (klassische Workflow- oder RPA-Automatisierung) oder mit KI-Unterstützung automatisiert werden sollte, oder ob sich Automatisierung angesichts der Fehlerkosten überhaupt lohnt. Diese Bewertung braucht zusätzliche Kriterien, die der Cluster-Artikel zum Automatisierungspotenzial im Detail behandelt.

Umsetzung: typischer Ablauf eines Process-Mining-Vorhabens

Ein schlankes Vorgehen für ein KMU-Vorhaben besteht aus vier Schritten:

1. Prozess und Fragestellung eingrenzen. Nicht „alles” analysieren, sondern einen konkreten Prozess mit einer klaren Frage – etwa: Warum dauert die Rechnungsfreigabe im Schnitt länger als geplant?
2. Datenquelle identifizieren. Gemeinsam mit der IT klären, in welchem System die relevanten Ereignisse protokolliert sind und ob sich daraus ein Event-Log mit Fallkennung, Aktivität und Zeitstempel extrahieren lässt. Für einen ersten Test reicht oft ein Datenexport als CSV-Datei, ganz ohne Systemanbindung.
3. Analyse und Interpretation. Das automatisch erzeugte Prozessmodell zusammen mit den Menschen lesen, die den Prozess ausführen – die Software zeigt die Abweichung, die fachliche Erklärung liefert das Gespräch.
4. Priorisierte Maßnahmen ableiten. Aus den sichtbaren Engpässen und Varianten die zwei bis drei vielversprechendsten Ansatzpunkte auswählen und erst dann in eine konkrete Automatisierungs- oder Prozessverbesserungsplanung überführen.

Für einen ersten Testlauf braucht es keine unternehmensweite Einführung: Ein einzelner, klar abgegrenzter Prozess mit einem sauberen Datenexport reicht, um zu prüfen, ob die Methode für die eigene Systemlandschaft brauchbare Ergebnisse liefert.

Risiken & Grenzen

• Datenqualität entscheidet über die Aussagekraft. Fehlen Zeitstempel, sind Fallkennungen uneinheitlich vergeben, oder ist die Historie unvollständig, entstehen verzerrte oder unbrauchbare Modelle. Das lässt sich vorab kaum vollständig prüfen – ein kleiner Testexport vor dem eigentlichen Projekt spart hier oft Wochen.
• Process Mining zeigt Symptome, nicht Ursachen. Eine Schleife oder Liegezeit ist ein Befund, keine Erklärung. Ohne das Gespräch mit den Ausführenden bleibt jede abgeleitete Maßnahme eine Vermutung.
• Datenschutz mitdenken. Sobald Ressourcen-Attribute personenbezogen sind – etwa welche Mitarbeiterin welchen Schritt bearbeitet hat –, gelten die üblichen DSGVO-Anforderungen: Zweckbindung, Transparenz gegenüber Betroffenen, ggf. Abstimmung mit dem Betriebsrat vor einer leistungs- oder verhaltensbezogenen Auswertung (Stand Juli 2026, keine Rechtsberatung).
• Kein Automatismus zur Automatisierung. Ein sichtbarer Engpass ist nicht automatisch ein guter Automatisierungskandidat. Diese Bewertung braucht zusätzliche Kriterien wie Regelbasiertheit, Fehlerkosten und Datenlage – Process Mining liefert dafür die Faktenbasis, nicht die fertige Entscheidung.
• Aufwand vor Nutzen prüfen. Für sehr kleine oder sehr seltene Prozesse steht der Aufwand für Datenextraktion und Tool-Einrichtung oft in keinem Verhältnis zum Erkenntnisgewinn – dazu mehr im Abschnitt zur manuellen Analyse oben.

Checkliste: Process Mining sinnvoll einsetzen

1. Wir haben einen konkreten Prozess mit klarer Fragestellung ausgewählt – nicht „alle Prozesse auf einmal”.
2. Wir wissen, in welchem System die relevanten Ereignisse protokolliert werden, und haben das mit der IT geklärt.
3. Ein Event-Log mit Fallkennung, Aktivität und Zeitstempel lässt sich daraus extrahieren – notfalls als CSV-Testexport.
4. Prozessvolumen und Zahl der beteiligten Systeme rechtfertigen den Aufwand gegenüber einer manuellen Analyse.
5. Datenschutzfragen sind vorab geklärt, insbesondere bei personenbezogenen Ressourcen-Attributen.
6. Für die Interpretation der Ergebnisse sind die Menschen eingeplant, die den Prozess tatsächlich ausführen.
7. Aus den Befunden werden priorisierte Maßnahmen abgeleitet – nicht nur eine Visualisierung ohne Konsequenz.
8. Der Ist-Zustand vor einer Veränderung ist dokumentiert, damit sich der Erfolg später messen lässt.

Wenn du unsicher bist, ob sich Process Mining für einen konkreten Prozess in deinem Unternehmen lohnt oder ob ein einfacheres Vorgehen reicht: Ein kostenloses Erstgespräch klärt in kurzer Zeit die nächste sinnvolle Frage. Für strukturiertes Vorgehen bei der Automatisierung selbst – von der Potenzialbewertung bis zur Umsetzung – findest du weitere Grundlagen auf der Startseite, und wer die eigenen Teams im Umgang mit solchen Analysen fit machen will, findet passende Formate in unseren Schulungen.