Nichts als die Wahrheit über Process Mining

Klageschriften sind – ähnlich wie Geschäftsberichte – inhaltlich gut überprüft, da sie gerichtlicher Prüfung durch Anwälte, Wirtschaftsprüfer und Richter standhalten müssen. Sie liefern daher wertvolle Einblicke in die aktuelle Marktsituation. Ein aktuelles Beispiel für die Wirkung gerichtlicher Stellungnahmen zeigt die Aussage eines Apple-Managers zur Suchfunktion, die einen Kursrückgang bei Alphabet auslöste². 

Führende PM-Anbieter

Besonders brisant: Celonis, laut Gartner der führende Anbieter im Bereich Process Mining (PM), sieht sich gezwungen, rechtlich gegen SAP vorzugehen. Dies deutet auf erhebliche Schwierigkeiten im Zusammenspiel der beiden Unternehmen hin. Konkret wirft Celonis SAP vor, den Zugriff auf SAP-Daten mit Drittanbietertools – also auch mit Lösungen von Celonis – gezielt zu blockieren. Viele der in der Klageschrift genannten Vorwürfe sind juristischer Natur und für diesen Artikel zweitrangig. Interessant sind vielmehr die Aussagen, die Einblick in den praktischen Stand der Process-Mining-Nutzung geben: Gibt es neue Erkenntnisse? Technologische oder inhaltliche Fortschritte?

Dieser Beitrag knüpft an einen Artikel³ aus dem Jahr 2022 im E3-Magazin an. Damals ging es um sechs Missverständnisse zwischen Anforderungen der Kunden und den Möglichkeiten bzw. Grenzen von „Process Mining“. Die Conclusio war damals, dass Process-Mining-Werkzeugen manche Fähigkeiten unterstellt werden, für die es geeignetere Ansätze in anderen Tools oder direkt im SAP-ERP-System gibt. Warum stößt Process Mining bei SAP oft an Grenzen? 

Die Wahrheit über Event Logs

Ein zentrales Versprechen von PM ist die Analyse realer Geschäftsprozesse auf Basis sogenannter Event Logs – digitaler Spuren, die jede Transaktion im System hinterlässt. In der Klageschrift (Punkt 24) wird genau das betont: Jeder Geschäftsprozess erzeugt einen digitalen Fußabdruck, der analysierbar sein sollte. Die Realität in SAP-Systemen sieht jedoch anders aus. Solche Event Logs existieren dort meist nicht in der Tiefe und Struktur, wie sie für effektives PM notwendig wären. Zwar gibt es Tabellen, die bestimmte Abläufe abbilden – etwa Vorgänger-Nachfolger-Beziehungen (z. B. Tabelle VBFA) oder Protokolle von Änderungen (z. B. CDHDR). Doch diese Informationen zeigen nur einen Teil des Gesamtbilds.

Ein Beispiel: Im Rahmen einer Kundenauftragsbearbeitung werden automatisch zahlreiche Folgeprozesse angestoßen – etwa die Übergabe des Bedarfs an die Disposition. Diese integrativen Abläufe, häufig durch sogenannte „Verbucher“ ausgeführt, werden in den Standard-Logs oft nur unvollständig erfasst. Besonders komplex wird es, wenn Preiskalkulationen oder Kontenfindungen ins Spiel kommen – Bereiche, die in vielen Process-Mining-Tools kaum berücksichtigt werden. In der Praxis führt das dazu, dass Unternehmen auf aufwendige Zusatzanalysen zurückgreifen müssen. Je nach Fragestellung müssen weitere Datenquellen ausgewertet und individuell kombiniert werden. Das ist zwar möglich – aber nur mit tiefem SAP-Know-how und erheblichem technischem Aufwand.

Fazit: Wer glaubt, Process Mining sei in SAP-Systemen einfach „auf Knopfdruck“ möglich, irrt. Die Realität ist komplex – und die Wahrheit über Event Logs deutlich weniger glatt, als es Marketingversprechen vermuten lassen.

Process Mining oder ERP?

In der Praxis wird PM oft mit dem Argument beworben, dass es konkrete Vorteile im Tagesgeschäft bringt – zum Beispiel bei der Prüfung von Kreditorenrechnungen oder der Vermeidung von Doppelzahlungen (Punkt 27 der Klageschrift). Doch genau dieses Beispiel zeigt, wie redundant manche PM-Analysen tatsächlich sind: Denn solche Prüfmechanismen existieren längst in jedem gängigen ERP-System – inklusive SAP. Wenn PM-Hersteller dennoch mit solchen Funktionen werben, geraten sie schnell in Erklärungsnot. Denn sie laufen Gefahr, bereits vorhandene ERP-Features lediglich nachzubilden – oft zu höheren Kosten und potenziellen Lücken bei Aktualität und Datenqualität. 

Gerade im Vergleich zu einem modernen ERP-System wie SAP S/4 Hana, das mit leistungsfähigen Analysetools ausgestattet ist, wird es für externe PM-Lösungen zunehmend schwierig, einen echten Mehrwert zu bieten. SAP S/4 Hana bietet rund 100 standardisierte Analyse-Apps, etwa zur Nachverfolgung von Kundenaufträgen, die genau solche Einblicke ermöglichen – direkt im ERP-System, ohne externe Tools.

Fazit: Wenn PM-Systeme Funktionen versprechen, die das ERP längst beherrscht, entsteht nicht nur Verwirrung, sondern auch eine fragwürdige Doppelinfrastruktur. Mit dem technischen Fortschritt moderner ERP-Plattformen wird der Handlungsspielraum für externe PM-Tools daher zunehmend kleiner. 

Wo liegt die Wahrheit über den Soll-Prozess? In Punkt 30 der Klageschrift wird behauptet, dass sich aus den realen Ist-Daten eines Event Logs der ursprüngliche Soll-Prozess ableiten lasse. Doch das ist so nicht haltbar. Ein Event Log – zumal ein unvollständiges – zeigt lediglich, was tatsächlich passiert ist, nicht aber, was geplant oder vorgesehen war.

Um den beabsichtigten Ablauf (den „Soll-Fluss“) eines Prozesses zu verstehen, müssten die Customizing-Einstellungen im ERP-System analysiert werden. Diese definieren die konkreten Prozessvorgaben, die bei der Systemeinführung oder laufenden Anpassung vom Kunden festgelegt wurden. Ohne diese Konfiguration bleibt der Blick auf den Soll-Prozess lückenhaft.

Ein weiteres Problem: In der Process-Mining-Welt fehlen häufig fundierte Ursache-Wirkungs-Analysen. Steuerungsparameter aus den Stammdaten – etwa wie ein Material disponiert oder wie ein Auftrag bewertet wird – werden kaum berücksichtigt. Dabei beeinflussen genau diese Parameter maßgeblich das Prozessverhalten.

Diese Vernachlässigung ist kein neues Phänomen: Schon die klassische Prozessmodellierung hatte damit zu kämpfen. Der PM-Ansatz konzentriert sich traditionell auf beobachtbare Abläufe, nicht auf die tieferliegenden systemseitigen Steuermechanismen.

Fazit: Wer den Soll-Zustand eines Prozesses wirklich verstehen will, kommt um die Analyse von Customizing und Stammdaten nicht herum. Dafür braucht es jedoch spezialisierte Methoden – etwa Reverse Business Engineering (RBE)⁴ –, die genau dafür entwickelt wurden. Process Mining allein reicht hier nicht aus.

12 bis 36 Stunden bis zur Wahrheit

Ein zentraler Schwachpunkt in der Praxis des PM scheint die Datenextraktion zu sein. Aus Punkt 124 wird ersichtlich, dass Celonis für die Datenanbindung eine veraltete SAP-Technologie verwendet hat: den Remote Function Call (RFC) mit Abap. Das Problem dabei: SAP unterstützt diese Methode inzwischen nicht mehr. In Punkt 141 wird deutlich, wie ineffizient die alte Lösung war: Das Extrahieren von Daten aus 100 Tabellen dauerte rund zwölf Stunden. 

Neue Ansätze, etwa über OData, brauchen sogar bis zu 36 Stunden. Das zeigt, dass eine echte Echtzeit-Datenanbindung zwischen PM-System und ERP-System nie existierte – denn die analysierten Daten waren immer mindestens einen halben Tag alt. Eine (hoffentlich überzogene) Kostenabschätzung zeigt, dass das alternative Herunterladen von 100 GB Daten über SAP Datasphere bis zu 30.000 Dollar kosten könnte. In der Cloud-Welt scheint es also keine kostenlose Datenbereitstellung mehr zu geben. 

Zusätzlich stellt sich die Frage: Warum müssen für die PM-Analytik pauschal
100 GB Daten übertragen werden? Mit einem gezielteren Analyseansatz könnten deutlich weniger Daten ausreichen – oft würde schon 1 GB pro Abfrage reichen.

Eine alte und zwei neue Wahrheiten

Der Process-Mining-Ansatz ist mittlerweile in die Jahre gekommen. Man könnte Parallelen zur Geschichte von Onlineshop-Anbietern wie Intershop ziehen: In den 2000er-Jahren galten sie als Hoffnungsträger des digitalen Marktes. Heute, wenn überhaupt noch vorhanden, sind sie meist nur Nischenanbieter mit begrenztem wirtschaftlichen Erfolg. Schon Ende der 2000er war klar: Die integrierte ERP-Suite setzt sich langfristig durch. Ähnlich scheint es nun den Anbietern von PM-Tools zu ergehen.

Außerdem haben PM-Tools ihren ursprünglichen Fokus – die Analyse von Event Logs – längst aufgegeben. Ihr wachsender „Datenhunger“ belastet Systeme zunehmend. Gleichzeitig haben sich mit S/4 Hana und dessen In-memory-Datenbank die Analysefähigkeiten innerhalb des ERP-Systems stark verbessert. Analysen im Sinne des Process Monitoring lassen sich heute direkt im ERP abbilden – PM-Tools werden dafür zunehmend überflüssig. Ihr sinnvoller Einsatzbereich wird dadurch deutlich kleiner.

Hinzu kommt: In der Cloud-Welt sind unbegrenzte Datenabfragen und hohe Ressourcennutzung keine Selbstverständlichkeit mehr. Wenn künftig auch noch KI-Modelle für PM trainiert werden sollen – was wahrscheinlich ist –, wird die Konkurrenz um Rechenleistung und Datenzugriff weiter steigen. Es bleibt abzuwarten, zu welchen rechtlichen Lösungen oder Kompromissen es hier kommen wird. Fortsetzung folgt …

Missverständnis vs. Realität

Missverständnis 

• Schnelle Problemdiagnose
• Umfassender Überblick
• Compliance-/Risikoanalyse
• Analyse über mehrere Systeme
• End-to-End-Sicht
• Automatisierung

Realität

• Hoher Aufwand mit PM-Tools
• Andere Tools einfacher
• Nicht Bestandteil von PM
• Grenzen vorhanden
• Nur eingeschränkt möglich
• Meist über ERP oder Add-ons

(1) Link zur Klageschrift.

(2) Link zum Frankfurter Allgemeine Artikel

(3) Reverse Engineering für Softwarebibliotheken wie SAP R/3; (4) Artikel: Hufgard, Wenzel (1999): Reverse Business Engineering – Modelle aus produktiven R/3-Systemen ableiten. In: Electronic Business Engineering. 4. Internationale Tagung Wirtschaftsinformatik. S. 425–441.