Der Kerngedanke ist einfach und zugleich folgenreich: Jede Handlung in einem digitalen System hinterlässt eine Spur. Wird eine Bestellung angelegt, eine Rechnung geprüft, ein Auftrag freigegeben oder eine Zahlung verbucht, schreibt das System einen Datensatz mit einem Zeitstempel. Aus tausenden dieser Spuren lässt sich der reale Prozess so rekonstruieren, wie ein Röntgenbild die innere Struktur eines Körpers sichtbar macht: Man sieht nicht die Oberfläche, sondern das, was wirklich darunter passiert. Genau darin liegt der Wert – Process Mining ersetzt Meinungen durch Belege.
Drei Eigenschaften definieren die Methode und erklären, warum sie sich in den vergangenen Jahren vom akademischen Nischenthema zum festen Baustein der Prozessoptimierung entwickelt hat:
Process Mining ist keine Marketing-Erfindung, sondern hat wissenschaftliche Wurzeln. Die Methode entstand in der Prozesswissenschaft und der Datenanalyse und wurde maßgeblich in der akademischen Forschung geprägt, bevor sie den Sprung in die betriebliche Praxis schaffte. Diese Herkunft erklärt zwei Dinge: Erstens ist die Methodik theoretisch gut fundiert – es gibt etablierte Verfahren, wie man aus Ereignisdaten Prozessmodelle ableitet und wie man deren Qualität bewertet. Zweitens ist Process Mining herstellerneutral als Disziplin definiert; es gibt viele Werkzeuge, die sie umsetzen, aber die Methode selbst gehört keinem einzelnen Anbieter. Genau diese Unterscheidung zwischen Methode und Werkzeug ist für eine fundierte Auswahl entscheidend und zieht sich durch diesen Artikel.
In nahezu jedem Projekt wiederholt sich derselbe Moment. An der Bürowand hängt ein aufgeräumtes Flussdiagramm des Soll-Prozesses: von der Bestellung geradlinig zur Bezahlung, wenige klare Schritte. Die Process-Mining-Analyse derselben Prozessdaten zeigt dagegen ein dichtes Geflecht aus Pfaden – hunderte Varianten, unerwartete Schleifen, manuelle Korrekturen, übersprungene Schritte. Nicht weil die Mitarbeitenden schlecht arbeiten, sondern weil die Realität komplexer ist als jedes Diagramm. Genau diese Abweichung zwischen gedachtem und gelebtem Prozess ist der Hebel: Sie kostet Zeit, bindet Geld und erzeugt Compliance-Risiken. Process Mining macht sie zum ersten Mal messbar sichtbar.
Process Mining entfaltet seinen Wert dort, wo Prozesse hohes Volumen haben, überwiegend durch IT-Systeme laufen und wirtschaftlich relevant sind. Ein Einkaufsprozess mit zehntausenden Bestellungen pro Jahr ist ein idealer Kandidat; ein selten durchlaufener Sonderprozess, der kaum digitale Spuren hinterlässt, dagegen nicht. Für den DACH-Mittelstand mit gewachsenen ERP-Landschaften ist die Methode besonders anschlussfähig, weil hier die nötigen Datenspuren in großer Menge vorliegen. Wo diese Voraussetzungen fehlen – sehr kleine Fallzahlen, kaum digitalisierte Abläufe – ist der Aufwand oft nicht gerechtfertigt, und eine klassische Prozessaufnahme bleibt das passendere Mittel.
Process Discovery ist die grundlegendste und meist der erste Schritt. Aus dem Ereignisprotokoll wird ohne jede Vorannahme ein Prozessmodell abgeleitet, das zeigt, welche Aktivitäten in welcher Reihenfolge tatsächlich vorkamen. Weil reale Prozesse selten einem einzigen Pfad folgen, entstehen dabei viele Varianten – unterschiedliche Wege, auf denen ein Vorgang das Ende erreicht. Häufig folgt ein Großteil der Fälle wenigen Standardvarianten, während ein langer „Schwanz“ aus seltenen Sonderwegen die eigentliche Komplexität und die versteckten Kosten erzeugt. Discovery macht diese Verteilung sichtbar und beantwortet damit die Frage, wo überhaupt hingeschaut werden muss.
Wo Discovery beschreibt, prüft Conformance Checking. Es legt das entdeckte Ist-Modell über den definierten Soll-Prozess oder über explizite Regeln und misst, wie gut beide zusammenpassen. Jede Abweichung wird benannt: die Rechnung, die ohne die vorgeschriebene Freigabe bezahlt wurde; die Bestellung, die nachträglich verändert wurde; der Auftrag, der eine Kontrollstufe übersprungen hat. Für interne Revision, Compliance und das interne Kontrollsystem ist das ein objektiver, lückenloser Prüfblick statt punktueller Stichproben – und oft der erste Anwendungsfall, der Prüfabteilungen für die Methode gewinnt.
Enhancement – teils auch als Extension oder Model Repair beschrieben – schließt den Kreis. Das entdeckte Modell wird mit zusätzlichen Datenperspektiven angereichert: Wie lange dauert jeder Schritt? Wo entstehen Wartezeiten und Engpässe? Welche Ressourcen sind beteiligt, wo häufen sich Rückläufer? Aus dieser Anreicherung entstehen konkrete Ansatzpunkte für die Optimierung und für die laufende Prozesssteuerung. Damit ist Enhancement die Brücke von der reinen Analyse zur eigentlichen Prozessverbesserung – dem Punkt, an dem Process Mining wirtschaftlichen Wert schafft.
Quer zu den drei Grundarten liegt eine zeitliche Dimension. Klassisch wertet Process Mining die Vergangenheit aus – abgeschlossene Fälle eines zurückliegenden Zeitraums. Moderne Ansätze verschieben den Fokus zunehmend in Richtung Gegenwart und Zukunft: Beim Operational Support werden laufende Fälle nahezu in Echtzeit begleitet, sodass Abweichungen früh auffallen. Und mit prädiktiven Verfahren lässt sich abschätzen, wie ein noch offener Vorgang voraussichtlich weiterläuft. Diese Verschiebung von der reinen Nachschau zur laufenden Steuerung führt direkt zum Thema künstliche Intelligenz, dem sich Kapitel 04 widmet.
Herzstück jeder Analyse ist das Ereignisprotokoll, das Event-Log. Im Kern besteht es aus einer langen Liste von Ereignissen, von denen jedes mindestens drei Angaben trägt: eine Fall-ID (englisch Case-ID), die angibt, zu welchem Vorgang das Ereignis gehört – etwa eine bestimmte Bestellung oder ein bestimmter Auftrag; eine Aktivität, die beschreibt, was geschah – etwa „Rechnung erfasst“ oder „Freigabe erteilt“; und einen Zeitstempel, der festhält, wann es geschah. Aus der Fall-ID ergibt sich, welche Ereignisse zusammengehören, aus Aktivität und Zeitstempel ihre Reihenfolge. Damit lässt sich für jeden einzelnen Vorgang der komplette Pfad rekonstruieren und über alle Vorgänge hinweg das Gesamtbild.
Ergänzend enthalten Event-Logs oft weitere Attribute: den beteiligten Bearbeiter oder die Ressource, die Organisationseinheit, Beträge, Materialien, Kunden- oder Lieferantenkennungen. Diese Zusatzangaben ermöglichen tiefere Analysen – etwa nach Region, Werk oder Warengruppe – erhöhen aber zugleich die Datenschutz-Relevanz, insbesondere wenn sie einen Personenbezug herstellen. Auf diesen Punkt geht Kapitel 09 ausführlich ein.
Die Rohdaten stammen aus den operativen IT-Systemen, in denen die Prozesse ablaufen. Am häufigsten sind das ERP-Systeme wie die verbreiteten SAP-Landschaften, in denen Einkauf, Finanzen und Logistik zusammenlaufen. Hinzu kommen CRM-Systeme für Vertrieb und Kundenservice, Ticket- und Servicemanagement-Werkzeuge, Dokumentenmanagement, Fertigungssteuerung und zahllose Fachanwendungen. Entscheidend ist nicht die Art des Systems, sondern dass es die Prozessschritte mit Zeitstempeln protokolliert. Fast jedes moderne Geschäftssystem tut das – die Kunst liegt darin, die relevanten Daten zu identifizieren und in die Form eines sauberen Event-Logs zu bringen.
Zwischen den Rohdaten in den Quellsystemen und einer belastbaren Analyse liegt der aufwendigste Schritt: die Datenaufbereitung. In der Praxis bedeutet das, die relevanten Tabellen zu extrahieren, die drei Kernangaben zu identifizieren und zu vereinheitlichen, Aktivitäten konsistent zu benennen, Zeitstempel zu bereinigen und die einzelnen Ereignisse korrekt den Fällen zuzuordnen. Klingt technisch, ist aber der Punkt, an dem Projekte gewonnen oder verloren werden. Denn Process Mining folgt einem unbestechlichen Prinzip: Sind die Eingangsdaten unsauber, ist auch das Ergebnis unsauber – ganz gleich, wie ausgefeilt der Algorithmus ist.
Klassisches Process Mining betrachtet einen Prozess immer aus der Perspektive einer einzigen Fall-ID – etwa „die Bestellung“. Reale Prozesse hängen aber an mehreren Objekten gleichzeitig: Eine Bestellung umfasst mehrere Positionen, hängt an einem Lieferanten, führt zu mehreren Wareneingängen und mehreren Rechnungen. Wer alles auf eine einzige Fall-ID zwingt, verzerrt das Bild oder verliert Zusammenhänge – ein Effekt, der in der Fachwelt als „Konvergenz und Divergenz“ bekannt ist. Object-Centric Process Mining (OCPM) modelliert den Prozess stattdessen über mehrere verknüpfte Objekttypen hinweg. Das ist datenmodellseitig anspruchsvoller, bildet die Realität in komplexen ERP-Welten aber deutlich präziser ab und gilt als wichtige Entwicklungsrichtung der Methode.
Ein verbreitetes Missverständnis lohnt die Klarstellung: Process Mining ist zunächst weder eine Simulation noch eine reine KI-Prognose und schon gar kein Ersatz für die Fachkenntnis der Prozessverantwortlichen. In seiner Grundform ist es eine faktenbasierte Rekonstruktion dessen, was nachweislich passiert ist. Der Wert liegt genau darin, dass es Diskussionen versachlicht: Statt darüber zu streiten, ob ein Prozess „eigentlich rund läuft“, liegt der tatsächliche Verlauf mit Zahlen auf dem Tisch. Es ist ebenso wenig ein Reporting-Werkzeug – Kapitel 06 grenzt es sauber gegen Business Intelligence ab. Voraussetzung bleibt, dass die zugrunde liegenden Logs den Prozess vollständig genug abbilden; schlichte Lücken im Datenmodell führen sonst zu falschen Schlüssen.
Der erste große KI-Beitrag ist die prädiktive Prozessanalyse (Predictive Process Monitoring). Auf Basis der historischen Prozessverläufe lernen Modelle, wie ein noch offener Vorgang voraussichtlich weiterlaufen wird: Wird diese Bestellung wahrscheinlich zu spät bezahlt? Droht dieser Auftrag eine kritische Durchlaufzeit zu überschreiten? Statt erst im Nachhinein festzustellen, dass etwas schieflief, verschiebt die Vorhersage den Eingriff nach vorn – solange noch gegengesteuert werden kann. Das ist der Übergang vom rückblickenden Analyseinstrument zum vorausschauenden Steuerungswerkzeug.
Discovery zeigt, dass ein Prozess an bestimmten Stellen klemmt. Die Ursachenanalyse (Root-Cause-Analyse) fragt nach dem Warum. KI-gestützte Verfahren durchsuchen die vielen Attribute eines Event-Logs nach Mustern und Korrelationen: Häufen sich Verzögerungen bei einer bestimmten Lieferantengruppe, in einem bestimmten Werk, bei bestimmten Auftragstypen? Diese Analyse ersetzt das mühsame manuelle Filtern durch systematische Mustererkennung und liefert Hypothesen, wo die eigentlichen Treiber eines Problems liegen. Wichtig bleibt: Korrelation ist keine Kausalität – die fachliche Prüfung der gefundenen Muster durch die Prozessverantwortlichen bleibt unverzichtbar.
Die dritte Ebene sind Handlungsempfehlungen. Aufbauend auf Vorhersage und Ursachenanalyse schlagen moderne Werkzeuge priorisierte Maßnahmen vor – und ordnen sie idealerweise nach ihrem erwarteten Nutzen. Hinzu kommt eine jüngere Entwicklung: generative KI und sprachbasierte Assistenten, mit denen Anwender Prozessfragen in natürlicher Sprache stellen können, statt Analysen manuell aufzubauen. „Zeig mir die häufigsten Ursachen für verspätete Zahlungen im letzten Quartal“ wird so für Fachanwender ohne Analyse-Hintergrund zugänglich. Der strukturierte Prozesskontext aus dem Mining wirkt dabei als Faktenanker, der die KI erdet und die Gefahr freier Erfindungen reduziert.
KI im Process Mining bleibt selten bei der Erkenntnis stehen. Der logische nächste Schritt ist die Verbindung zur Automatisierung: Eine erkannte, wiederkehrende Ineffizienz kann eine Maßnahme auslösen – bis hin zu einem robotergestützten Prozessschritt (RPA) oder einem angestoßenen Workflow. Damit wird Process Mining zum analytischen Kern eines größeren Ansatzes, der Analyse, Entscheidung und Ausführung verzahnt und häufig als Hyperautomatisierung beschrieben wird. Process Mining übernimmt darin die entscheidende Rolle, die Automatisierung dorthin zu lenken, wo sie den größten Hebel hat – statt nach Bauchgefühl zu automatisieren.
Grob lassen sich die Anbieter in einige Gruppen einteilen, die sich zunehmend überlappen. Die folgende Übersicht beschreibt Typen und nennt bekannte Vertreter beispielhaft – herstellerneutral und ohne Anspruch auf Vollständigkeit.
Am einen Ende stehen spezialisierte Plattformen, die sich ganz auf Process Mining und die darauf aufbauende Prozessintelligenz konzentrieren; sie sind oft besonders tief und wertorientiert. Am anderen Ende bündeln große Plattform-Ökosysteme Process Mining als einen Baustein unter vielen und punkten mit der nahtlosen Anbindung an eine ohnehin vorhandene Systemlandschaft. Dazwischen liegen Anbieter mit BPM- oder ERP-Erbe, die die datenbasierte Analyse mit klassischer Prozessmodellierung verbinden – ein Ansatz, der besonders dort überzeugt, wo Ist-Analyse und Soll-Gestaltung eng zusammenspielen sollen. INAGRO führt zu mehreren dieser Werkzeuge eigene Tiefenartikel; die Verlinkungen in der Seitenleiste helfen beim Einstieg.
Neben den kommerziellen Werkzeugen existiert eine lebendige Open-Source- und Forschungslandschaft. Sie ist flexibel und lizenzkostenfrei, verlangt aber mehr eigenes Know-how für Betrieb und Datenaufbereitung. Für den Mittelstand ist sie meist eher für erste Experimente, für datenaffine Teams oder für sehr spezifische Anforderungen interessant als für den produktiven Dauerbetrieb. Wichtig für die Zukunftssicherheit ist zudem, dass sich der Austausch von Ereignisdaten zunehmend standardisiert – etwa über etablierte Log-Formate. Solche Standards verringern die Abhängigkeit von einem einzelnen Werkzeug und erleichtern einen späteren Wechsel.
Ein Blick auf die Marktdynamik hilft bei der Einordnung. Process Mining, RPA und BPM verschmelzen zunehmend – erkennbar daran, dass Automatisierungsanbieter Mining-Fähigkeiten zukaufen und ERP-Häuser eigene Angebote bündeln. Für Anwenderunternehmen bedeutet das zweierlei: Erstens verwischen die Grenzen zwischen den Kategorien, weshalb die Frage „welches Tool“ immer häufiger zur Frage „welche Gesamtarchitektur“ wird. Zweitens steigt der Wert einer bewussten, herstellerneutralen Auswahl – gerade im DACH-Mittelstand, der über Jahre mit gewachsenen Systemlandschaften lebt.
ERP-Logs zeigen, was im System passiert ist – aber nicht, was davor auf dem Bildschirm der Sachbearbeiterin geschah. Task Mining schließt diese Lücke, indem es Tätigkeiten am Arbeitsplatz erfasst: manuelle Übertragungen zwischen Systemen, wiederholtes Nachschlagen, Copy-and-paste, Medienbrüche. Damit macht es Automatisierungspotenziale sichtbar, die im reinen ERP-Log unsichtbar bleiben. Task Mining ist also kein Gegensatz, sondern eine feinkörnige Ergänzung von Process Mining – allerdings eine mit erhöhter Datenschutz-Relevanz, weil es sehr nah an der einzelnen Person misst. Betriebsrat und Datenschutz gehören hier besonders früh eingebunden (siehe Kapitel 09).
Business Process Management (BPM) in seiner klassischen Ausprägung modelliert Prozesse – wie sie sein sollen. Es entstehen saubere Soll-Diagramme, Rollen und Regeln, oft in Workshops erarbeitet. Genau hier liegt der Unterschied: BPM beschreibt die Absicht, Process Mining misst die Wirklichkeit. Beide ergänzen sich hervorragend – das im Mining entdeckte Ist-Modell kann mit dem BPM-Soll-Modell abgeglichen werden (Conformance Checking), und die Erkenntnisse fließen zurück in eine Neugestaltung. Moderne Werkzeuge verbinden beide Welten deshalb zunehmend unter einem Dach.
Der häufigste Denkfehler ist die Gleichsetzung von Process Mining mit Business Intelligence (BI). BI und klassisches Reporting liefern aggregierte Kennzahlen – Umsatz pro Monat, offene Posten, Bestände. Sie beantworten, wie die Zahlen stehen. Process Mining zeigt dagegen den End-to-End-Prozessfluss: jeden tatsächlich vorgekommenen Pfad, jede Schleife, jede Nacharbeit, und beantwortet, wo und warum ein Prozess klemmt. Ein BI-Dashboard sagt Ihnen, dass die durchschnittliche Durchlaufzeit gestiegen ist; Process Mining zeigt Ihnen, an welchem Schritt und für welche Fallgruppe das passiert. BI ersetzt keine Prozesssicht, Process Mining ersetzt kein Reporting – sie beantworten unterschiedliche Fragen und ergänzen sich.
Der häufigste Fehler ist der zu große erste Schritt. Wer gleich fünf Prozesse gleichzeitig analysieren will, verzettelt sich in Datenanbindung und Abstimmung, bevor der erste belastbare Wert vorliegt. Ein einzelner, wertstarker Use Case dagegen hält den Aufwand überschaubar, macht den Wertnachweis sauber führbar und liefert die Argumente für die Ausweitung. In unseren Projekten ist nicht der technische Go-live der kritische Punkt, sondern der erste Moment, in dem eine Fachabteilung sagt: „So läuft unser Prozess also wirklich.“ Ab da trägt sich die Einführung meist von selbst.
Eine seriöse Einführung ist kein Wochenprojekt. Die Use-Case-Definition und vor allem die Datenanbindung beanspruchen je nach Systemlandschaft und Datenqualität spürbare Zeit; der Pilot inklusive Wirkungsmessung weitere Wochen. Der zeitintensivste und am häufigsten unterschätzte Teil ist die Datenaufbereitung – sind die Logs uneinheitlich oder die Quellsysteme komplex, verschiebt das den ganzen Plan. Wer von Anfang an realistisch plant und mit einem Prozess beginnt, kommt schneller und sicherer zum belegten Wert als ein ambitioniertes Programm, das sich an zu vielen Prozessen gleichzeitig verhebt.
Es ist kein Zufall, dass nahezu jedes Process-Mining-Projekt mit Purchase-to-Pay oder Order-to-Cash beginnt. Beide Prozesse sind hochvolumig, laufen sauber durch ERP-Systeme (also gut messbar) und ihre Ineffizienzen lassen sich unmittelbar in wirtschaftliche Größen übersetzen: verpasste Skonti, gebundenes Working Capital, verspätete Zahlungseingänge. Damit ist der Wertnachweis vergleichsweise einfach zu führen – die wichtigste Voraussetzung, um ein Process-Mining-Programm intern zu rechtfertigen und schrittweise auszuweiten.
In unserer Beratungspraxis sehen wir immer wieder denselben Bruch: Die Analyse ist beeindruckend, das Dashboard glänzt – und dann passiert nichts. Der Wert eines Use Case entsteht erst, wenn aus der Erkenntnis eine umgesetzte Maßnahme wird. Deshalb empfehlen wir, jeden Use Case von Anfang an mit einer konkreten Maßnahme, einem Verantwortlichen und einem Wertziel zu hinterlegen. „Wir analysieren mal den Einkauf“ ist kein Use Case. „Wir heben die Skonto-Quote spürbar, verantwortet vom Einkaufsleiter, gemessen monatlich“ ist einer.
Die zentrale Wahrheit über Process Mining lautet: Es ist ein Analyseinstrument, kein Ergebnis. Der wirtschaftliche Nutzen entsteht nicht durch die Analyse selbst, sondern durch die Maßnahmen, die daraus folgen. Eine Organisation, die beeindruckende Prozessgrafiken erzeugt, aber nichts verändert, hat Geld ausgegeben ohne Gegenwert. Deshalb ist die wichtigste Erfolgsbedingung nicht technischer, sondern organisatorischer Natur: die Bereitschaft und Fähigkeit, aus Erkenntnissen Handlungen zu machen. Wo diese Umsetzungskraft vorhanden ist, gehört Process Mining zu den wirksamsten Instrumenten der Prozessoptimierung; wo sie fehlt, bleibt selbst die beste Analyse folgenlos.
Der häufigste Stolperstein ist nicht die Methode, sondern die eigene Datengrundlage. Event-Logs beantworten oft die Frage „wer hat wann was getan“ – und damit sind sie potenziell eine Leistungs- und Verhaltenskontrolle der Beschäftigten. Das berührt nicht nur die DSGVO, sondern in Deutschland regelmäßig die betriebliche Mitbestimmung. Die zentralen Prinzipien: Datensparsamkeit – nur die Felder extrahieren, die der Use Case wirklich braucht; Pseudonymisierung oder Anonymisierung von Bearbeiter-Kennungen, wo der Personenbezug nicht zwingend ist; Zweckbindung – die Daten ausschließlich zur Prozessverbesserung nutzen, nicht zur Überwachung Einzelner; und Transparenz gegenüber den Beschäftigten darüber, was zu welchem Zweck ausgewertet wird.
Neben dem Umgang mit personenbezogenen Feldern stellt sich die Frage der Datenhoheit. Wo werden die Prozessdaten verarbeitet, und wer hat Zugriff? Je nach Werkzeug und Betriebsmodell – Cloud, private Umgebung oder lokaler Betrieb – lassen sich Verarbeitungsort und Kontrolle unterschiedlich weit fassen. Für besonders sensible Bereiche ist die Wahl einer EU-seitigen Verarbeitung und die vertragliche Klärung von Subprozessoren und etwaigen Drittlandbezügen ratsam. Der wirksamste Hebel bleibt jedoch organisatorisch: Je konsequenter bereits bei der Extraktion auf nicht benötigte personenbezogene Felder verzichtet wird, desto kleiner wird die Angriffsfläche – rechtlich wie sicherheitstechnisch. Datenschutz ist hier kein nachgelagerter Haken auf einer Liste, sondern ein Gestaltungsprinzip von der ersten Datenanbindung an.
