Process Mining – Warum, wofür, wie?

Process Mining ist ein Thema, welches schon seit ein paar Jahren Relevanz hat, aber gerade in jüngster Vergangenheit Schwung aufgenommen hat. 1.100.000 Treffer bietet Google aktuell bei der Suche danach, im letzten „Market Guide for Process Mining“ von Gartner vom Juni 2019 „“ werden im Abschnitt „Representative Vendors“ 19 Lieferanten gelistet.

Wir beschäftigen uns übrigens schon lange im Detail damit; Sie finden hier in unserem Blog erste Beiträge schon im Jahre 2015: Mein Kollege Martin Riedl geht dort ins Detail in Sachen Event Log.

In diesem Blogpost gebe ich Ihnen in einer kurzen Einführung ein paar High-Level Informationen was die zu Grunde liegende Technik aus Datensicht anbelangt. Weiter zeige ich, wie sich Process Mining im Vergleich zur klassischen, transaktionsbasierten Datenanalyse positioniert, und mache auf ein paar potenzielle Fallstricke aufmerksam, die Sie im Rahmen einer Einführung beachten sollten. Nach einem kurzen Zwischenfazit beschreibe ich zwei Anbieter, mit denen wir gerne zusammenarbeiten, erkläre warum und zeige Ihnen die Unterschiede aus unserer Sicht, die Ihnen bei einer Toolentscheidung hier helfen können. Einen ausführlicheren Bericht zu einem dieser Partner hat bereits mein Kollege Robert für Sie verfasst.

 

Einführung

Gute Prozesse sind die Basis, um die Wertschöpfung in Unternehmen sowie die innerbetrieblichen Abläufe zu optimieren. Auch die Modellierung der Prozessabläufe ist gelebte Praxis. Eine Spezifikationssprache wie BPMN (Business Process Model and Notation) erlaubt die Visualisierung (bzw. Dokumentation) von Prozessen.

 

Nun ist es natürlich eine Sache, Prozesse zu dokumentieren, basierend auf dem Verständnis bzw. Meinungen relevanter Personen die den Prozess gut kennen - bzw. manchmal eher von Beteiligten, die beschreiben, wie sie hoffen dass der Prozess aussehen könnte weil es dem ähnelt wie sie denken dass er aussehen sollte – oder aber, basierend auf den tatsächlich im System vorhandenen Daten.

Letzteres ist auch das ausschlaggebende Argument der Process Mining Anbieter und Fans: Das Zeichnen des Ist-Zustandes aus Prozesssicht, mit der Möglichkeit Prozessabläufe zu erkennen, und Schwachstellen zu identifizieren und zu verbessern. Verbesserungen können etwa durch geänderte operative Abläufe erfolgen, durch bessere Unterstützung einzelner Teilprozesse oder IT-seitig durch Automatisierungen im Sinne von RPA Robotic Process Automation. Die Relevanz des letzten Punktes zeigt sich im zum Teil engen Zusammenwirken von RPA Lösungen und Process Mining Anbietern, etwa von MINIT oder PAF.

Zentrales Element der Process Mining Lösungen ist der Prozessgraph. Diese Visualisierung des Prozesses sieht dann zum Beispiel so aus:

Die Graphen sind auch in der Regel interaktiv, d.h. die Durchläufe der Events können animiert betrachtet werden, man kann Zusatzinformationen ein- oder ausblenden, Filter auf ausgewählte Schritte oder Prozessbereiche setzen oder die Komplexität des Graphen durch die Anzahl der maximal angezeigten Varianten erhöhen oder verringern.

Neben der grundsätzlichen Funktionsweise der Tools wurden in diesem Kapitel auch bereits die beiden Process Mining Anbieter eingeführt, mit denen wir enger zusammenarbeiten: Process Analytics Factory (kurz PAF) sowie Minit Mehr Details zu beiden Unternehmen finden Sie weiter unten im Kapitel „Welches Tool soll es denn sein“.

 

Zum technischen Verständnis – die Datenbasis

Das gewünschte Ergebnis beim Einsatz einer Process Mining Lösung ist also unter anderem der Process Mining Graph. Nun ist es in der Regel nicht so, dass man die Software installiert, und sofort diese Grafiken erzeugt werden. Process Mining Tools arbeiten mit sog. Event Logs. Dies ist eine, basierend auf den Rohdaten im Unternehmen, aufbereitete Datenschicht die bestimmte Attribute aufweist, ohne die ein Prozessgraph nicht aufgebaut werden kann. Konkret sind das unter anderem Case ID, Eventbezeichnung und Timestamp.

Mit diesen Daten ist die Software (bzw. der Algorithmus dahinter) in der Lage, die Graphen entsprechend aufzubauen. Zu welchem Zeitpunkt (Timestamp, bestenfalls so granular wie möglich) hat ein gewisses Objekt (Case, z.B. Bestellposition) welche Stationen (Events, z.B. Anlage, Genehmigung, Lieferung) durchlaufen – oder auch nicht.

Zusätzlich zu diesen drei obligatorischen Elementen kann man i.d.R. noch zusätzliche Attribute definieren (Geldbeträge, Geschäftspartner IDs und Namen, etc.), um das Ergebnis für den Endanwender etwas leichter interpretierbar zu machen.

Diese derart aufbereiteten Eventlogs basieren also auf den Rohdaten im Unternehmen, die häufig in Tabellen einer Datenbank gespeichert sind. Sie können aus einem integrierten System stammen (z.B. SAP), aber man kann auch Daten verschiedener Systeme zu einem Event Log kombinieren (wenn etwa der Einkaufsprozess in einem Vorsystem X stattfindet, und die Finanzbuchhaltung, die die Bezahlung der Rechnung vornimmt in System Y). Das setzt natürlich den Fall voraus, dass sich die Events, Cases und Timestamps entsprechend systemübergreifend definieren lassen. Das Erstellen eines Event Logs setzt also bereits Wissen über Prozesse und wie sie systemseitig abgebildet sind voraus, ebenso wie die Fähigkeit, diese technisch zu einem Event Log zu kombinieren. Nur so kann die Datenbasis aus den Rohdaten richtig kombiniert werden. Am Beispiel von SAP Systemen hilft es zu wissen, dass Bestellanforderungen in der Tabelle EBAN, Bestellbelege in EKKO und EKPO und die Bestellhistorie zum Beispiel in Tabelle EKBE gespeichert sind. Zusätzlich zum Tabellenwissen braucht man noch die Information, welche Felder daraus sich als Timestamp eignen, wie die einzelnen Events (Neuanlage, Freigabe, Wareneingang, Rechnungseingang etc.) zu kennzeichnen sind und welches Attribut sich für die Identifikation eines Cases am besten eignet.

Hier nochmal die Datenbasis im Überblick: