Process Mining Teil 2 - Das Eventlog
Process Mining ist in der Datenanalysewelt seit einigen Jahren ein Thema, mit dem sich Analysten mehr und mehr beschäftigen. Auch wir haben dieser Methodik bereits einen Blogartikel gewidmet und erste Erfahrungen in Projekten verschiedener Größenordnung und mit unterschiedlichen Tools gesammelt. Ich möchte mit dieser Artikelreihe Einblick in unsere gesammelten Erfahrungen geben.
Einleitung
Blogpost 1 dieser kleinen Artikelreihe hat Ihnen hoffentlich einen ersten Eindruck von Process Mining verschafft und hat dabei einige grundlegende Begrifflichkeiten des Process Mining erläutert. Einer dieser Begriffe war das Eventlog – die zentrale Datenbasis eines jeden Process Mining Projektes. Mit diesem zweiten Teil der Artikelserie möchte ich die Erstellung dieses Eventlogs auf Basis von Einkaufsdaten eines SAP-ERP Systems erläutern und herausarbeiten, welche Schwierigkeiten auftreten und welche Besonderheiten man beachten muss.
Der Aufbau des Eventlogs
Wie bereits im Blogpost #1 kurz angeschnitten, benötigt ein Eventlog bestimmte Muß-Felder und kann mit weiteren nicht zwingend erforderlichen Feldern angereichert werden. Je mehr zusätzliche Information man in das Eventlog aufnimmt, umso bessere Möglichkeiten zu Filtern und Analysieren hat man beim späteren Arbeiten mit den Daten. Dabei ist aber unbedingt zu beachten, dass man sich wirklich ausschließlich auf benötigte Felder konzentriert und das Eventlog so schmal wie möglich hält, um eine performante Datenverarbeitung durch das Process Mining Tool nicht zu gefährden.
Die zwingend erforderlichen Felder des Eventlogs sind:
- Die Case – ID oder Fall-ID: Der Case ist ein zusammenhängender Prozessdurchlauf – später werde ich noch detaillierter darauf eingehen. Die Case ID ist dabei das eindeutig Merkmal– in der Regel ein Wert den man direkt aus den Daten des SAP ERP ableiten kann (z.B. Kombination aus Einkaufsbelegnummer und Position).
- Die Eventbezeichnung: Jeder Event-Typ braucht eine eindeutige Beschreibung z.B. „Anlage Bestellung“ oder „Freigabe Bestellung“.
- Den Timestamp: Der Zeitstempel, wann dieses Event im System protokolliert wurde.
Wichtig ist dabei, dass jedes einzelne Ereignis, das später mittels eines Knotens dargestellt werden soll, als eigener Datensatz in diesem Eventlog vorliegt. Wenn wir also von dem Fall ausgehen, dass wir es mit 100 Prozessen zu tun haben (also z.B. 100 Bestellungen) und jeder Prozess dabei aus 4 Ereignissen besteht (Anlage, Freigabe, Rechnungseingang, Wareneingang), dann wird das Eventlog genau 400 Datensätze beinhalten. Dass die Realität nicht so linear und einfach ist, brauche ich hier sicher nicht extra erwähnen.
Um innerhalb des vom Process Mining Tool generierten Prozessbildes weiter filtern zu können, bietet es sich häufig an, weitere Merkmale mit in das Eventlog aufzunehmen. Die Entscheidung, welche Merkmale hier geeignet sind, ist auch in gewisser Weise von der Festlegung der Case-ID abhängig. Erstellt man ein Eventlog auf Basis von Bestell-Köpfen (näheres dazu später), macht die Aufnahme einer Materialnummer oder Warengruppe, die auf Positionsebene gepflegt wird, keinen Sinn.
Basierend auf SAP-ERP Daten bieten sich im Einkaufsprozess folgende Attribute als zusätzliches Merkmal an:
- Benutzer der das Ereignis ausgelöst hat
- Lieferant der Bestellung
- Einkaufsorganisation, Buchungskreis, Werk
- Materialnummer , Warengruppe
Beim Import des Eventlogs in das Tool „Disco“ kann man dabei unterscheiden, ob man diese Felder als „Ressource“ oder als „anderes Datenfeld“ einspielen will. Ressourcen werden– im Gegensatz zu den „anderen Datenfeldern“ in den Statistiken von DISCO sowohl einzeln, als auch kombiniert dargestellt. Was das genau bedeutet erfahren Sie in einem der nächsten Artikel, wenn wir die Funktionalitäten von Disco durchleuchten.
Die technische Seite der Erstellung
An dieser Stelle sei erwähnt, dass keines der mir bekannten Process Mining Tools das Erstellen dieses Eventlogs automatisiert vornimmt, sondern die Arbeit des eigentlichen Process Minings auf diesem – wie auch immer erstellten – Datenbestand aufbaut und diesen quasi als Prämisse voraussetzen. Nichtsdestotrotz bieten die meisten Anbieter natürlich die Erstellung des Eventlogs auch mit an – dies geschieht dann in der Regel aber immer mit „herkömmlicher“ Technologie wie z.B. SQL-Routinen. In meinem Fall der SAP®-ERP Daten, die wir wieder mit DISCO bearbeiten werden, habe ich die Erstellung des Eventlogs mittels der Datenanalysesoftware ACL™ vorgenommen – eine Vorgehensweise, die sich für uns absolut bewährt hat.
Eine weitere große Hürde bei Process Mining Projekten stellt oftmals die eigentliche Extraktion der Daten aus den Quellsystemen dar. Diese Quellsystemlandschaft kann natürlich sehr schnell sehr heterogen sein, wenn man sich bestimmte Prozesse betrachtet. Unseren Erfahrungen nach tritt bei Kunden, die SAP® einsetzen, dieses Problem nicht ganz so oft auf: Die Prozesse werden dort von Anfang bis Ende sehr häufig homogen in den SAP®-Systemen protokolliert und stehen damit als Rohdaten bereits zur Extraktion zur Verfügung.
Auch das Problem der Extraktion an sich existiert bei uns nicht, da wir dieses seit Jahren mit unserem Produkt dab:Exporter gelöst haben und auch enorme Datenmengen aus den SAP® Systemen ressourcenschonend extrahieren. Mit unserer Version 3.0, die mittlerweile seit einem Jahr erfolgreich am Markt ist, haben wir uns auch Thematiken wie der Deltaextraktionen angenommen, die für einen kontinuierlichen Analyseansatz, der auch bei Process Mining Anwendung finden sollte, essentiell sind.
Das komplette Thema der Datenextraktion ist allerdings einen eigenen Artikel wert. Da dieser Bereich nicht zwangsläufig an Process Mining gekoppelt ist, sondern auch für „normale“ Datenanalyse-Projekte relevant ist, werde ich einen solchen Artikel losgelöst von dieser Artikelreihe demnächst veröffentlichen.
Was ist ein Case / Festlegung der Case-ID
Bevor man beginnt ein Eventlog zu erstellen, sollte man sich im Klaren darüber sein, was einen Case definiert. Wir brauchen sozusagen ein führendes Prozesselement, mit dem wir die Ereignisse verknüpfen bzw. dem wir die Ereignisse zuordnen können.
Ich stelle im Fall von SAP® ERP Einkaufsdaten hier jetzt konkrete Überlegungen an, warum manche Elemente besser und andere schlechter geeignet sind, als Case zu agieren:
- Bestellanforderung (BANF)
Die BANF wäre in der Prozesskette das erste denkbare Element, das den Case definieren könnte. Allerdings ist dabei zu beachten, dass nicht jede BANF zu einer Bestellung wird und auch nicht jede Bestellung auf einer BANF basiert. In der Praxis ist die Bestellanforderung also eher weniger geeignet. - Bestellung
Auf den ersten Blick scheint die Bestellung selbst am besten geeignet zu sein, als Case zu dienen, repräsentiert sie doch einen Einkaufvorgang den wir bei einem Lieferanten tätigen. Mit der im SAP® System eindeutigen Bestell-Belegnummer haben wir auch den perfekten eindeutigen Schlüssel für die Case-ID. Oder etwa doch nicht? Näher betrachtet ist es so, dass mit der Freigabe zwar ein wichtiges Element tatsächlich auf Ebene der Kopf-Daten stattfindet – also wirklich pro Bestellung. Jedoch sind sehr viele andere mögliche Events möglich, die ebenfalls sehr spannend sein können, wie z.B. Preisänderungen, Rechnungseingang und Wareneingang – diese sind aber allesamt positionsbezogen. Erschwerend kommt hinzu, dass wir nach der Anlage der Bestellung selbst auch Tage oder Wochen später noch Einzelpositionen an diese anfügen können – was eine Herausforderung beim Erstellen eines aussagekräftigen Eventlogs darstellt. - Bestellposition
Um es vorwegzunehmen: die Bestellposition ist meiner Meinung nach das am besten geeignete Element, um einen Fall zu identifizieren. Warum? Zum einen ist ein vorgelagerter Schritt wie die BANF immer positionsbezogen und auch die weiteren Ereignisse wie Änderungen, Rechnungseingang, etc. beziehen sich immer auf eine Bestellposition. Auch bzgl. Neuanlage ist es prinzipiell einfach, indem ich alle initial in einer Bestellung vorhandenen Positionen mit dem Anlagedatum der Bestellung selbst versehe und nachträglich hinzugefügte über die Änderungsprotokolle von SAP identifiziere. Als Case-ID dient uns in diesem Fall also eine Kombination aus Bestellbelegnummer und Positionsnummer.
Wir entscheiden uns also prinzipiell dafür, die Bestellposition als Case zu verwenden. Nichtsdestotrotz sind wir neugierig und wollen zumindest mal die Unterschiede in den Prozessgraphen zwischen Case „Bestellung“ und Case „Bestellposition“ betrachten.
Abbildung 1 - Prozessbild bei Case "Bestellkopf" (100% Events / 15 % Pfade)
Abbildung 2- Prozessbild bei Case "Bestellposition" (100% Events / 15 % Pfade)
Betrachten wir die Unterschiede zwischen den Prozessbildern, ohne dabei zu genau ins Detail zu gehen, so fällt zumindest eines markant ins Auge. Bei der Verwendung der Bestellnummer als Case-ID, also der Betrachtung auf Kopf-Ebene, haben wir sehr viele repetitive Ereignisse, d.h. z.B. Rechnungseingänge folgen auf sich selbst – hier erkennbar durch die dicken Rundpfeile, die in die Ausgangsbox zurückführen. Dies ist ein absolut nachvollziehbares Verhalten, wenn wir uns vor Augen führen, dass alleine die Anlage einer Bestellung mit 5 Positionen schon in 5 aufeinanderfolgende Ereignisse mündet. Natürlich hätte man diese Fälle unter einer Nummer und dem gleichen Zeitstempel noch zusammenfassen können, spätestens bei den Rechnungseingängen lassen sich diese repetitiven Events aber nicht mehr so einfach eliminieren.
Zugegebenermaßen ist der Einkaufsbereich in SAP ERP jetzt noch ein relativ gut Überschaubarer. Noch verzwickter gestaltet sich das ganze tatsächlich beim Order To Cash – Prozess. Dort hat man neben diversen Vertriebsbelegtypen, die aufeinander referenzieren (z.B. Verträge resultieren in Aufträge und diese wiederum können Gutschriftsanforderungen oder Retouren zur Folge haben), auch noch Lieferbelege und Fakturabelege. Hier den passenden Case zu definieren kann unter Umständen sogar vom Geschäftsmodell der zu untersuchenden Einheit abhängig sein.
Die Events
Die zweite essentiell wichtige Entscheidung, die man bei der Datenaufbereitung treffen muss, ist das Definieren der Events selbst. Nur wenn man alle relevanten aber auch jeweils nur die wirklich sinnvollen Events sauber definiert, kann man einen sauberen Prozessgraphen erzeugen.
Das Definieren dieser Events ist in gewisser Weise natürlich auch von der Struktur der vorliegenden Daten abhängig. Wenn ein ERP-System z.B. kein Freigabeverfahren für Bestellungen beinhaltet, dann macht auch das Definieren solcher Events keinen Sinn. Die sinnvolle Zuordnung eines Zeitstempels ist dabei noch eine völlig eigenständige Frage, die geklärt werden muss und auf diese gehe ich etwas weiter unten noch gesondert ein.
Bleiben wir in der SAP® ERP Welt, dann bieten sich auf Basis der vorhandenen SAP® Tabellen im Standard schon mal untenstehende Events an.
- Erstellen der Bestellanforderung
- Freigabe der Bestellanforderung
- Erstellen der Bestellung oder Bestellposition
- Freigabe der Bestellung
- Änderungen an Preis und/oder Menge
- Ändern des Löschkennzeichens
- Ändern von Endliefer- oder Endrechnungskennzeichen
- Wareneingang
- Rechnungseingang
Zu einigen dieser Ereignisse möchte ich ein paar weiterführende Überlegungen anstellen.
Freigabe (Bestellanforderung oder Bestellung)
Bestellanforderungen in SAP® sind per Datenmodell positionsbezogen – d.h. hier findet eine Freigabe auf Positionsebene statt, während bei Bestellungen die Freigabe für die komplette Bestellung vorgenommen wird, wir also von einem Kopf-Event sprechen. Hier duplizieren wir die Freigabe einfach pro Position. Noch wichtiger zu erwähnen ist meiner Meinung nach, die Tatsache, dass wir es beim SAP®-Freigabeprozess u.U. nicht nur mit einer Freigabe zu tun haben, sondern eventuell auch mit der Rücknahme einer Freigabe oder einer Ablehnung. Für unser Eventlog bedeutet dies, dass wir für jeden dieser Schritte ein eigenes Ereignis definieren müssen.
Änderungen an Preis/Menge
Hier verhält es sich ähnlich. Eine Änderung kann sowohl eine Erhöhung als auch eine Verringerung von Preis oder Menge sein. Der Effekt ist der gleiche – es ändert sich der Bestellwert der Position. Man muss also die Entscheidung treffen, ob man mit einem Event (Änderung Bestellwert), zwei Events (Erhöhung bzw. Verringerung Bestellwert) oder gar mit vier Events (Erhöhung / Verringerung von jeweils Preis und Menge) arbeiten will. In unserem Beispiel hier habe ich mich für die 4-Ereignis-Variante entschieden, um die größtmögliche Transparenz zu erzielen.
Rechnungseingang
Durch den sogenannten 3-Way-Match in SAP®, bei dem – vereinfacht gesagt – Rechnungswert mit Bestellwert und Wareneingang verglichen wird, kann es passieren, dass eine Eingangsrechnung durch das Einbuchen bereits mit einer Sperre versehen wird. Dies eröffnet einem unterschiedliche Möglichkeiten hinsichtlich der Ereignisdefinition:
- Man kann es ignorieren und es einfach alles als Rechnungseingang behandeln
- Man kann eigene Ereignisse für Rechnungseingang, Sperre der Rechnung und Freigabe der Rechnung definieren.
- Man definiert ein Event für Rechnungseingang, eines für „gesperrter Rechnungseingang“ und eines für die Freigabe der Rechnung.
Der Unterschied zwischen b) und c) liegt dann darin, dass bei Variante b) Sperre und Freigabe vorher durch ein gleichartiges Event laufen (also durch eine Box), während bei c) für den Rechnungseingang zwei Boxen verwendet werden, wobei nur die gesperrte in das Event „Freigabe“ führen kann. (siehe Grafiken).
Allein diese drei näheren Erläuterungen zeigen, dass auch das Definieren der Ereignisse viel Sorgfalt benötigt und explizites Know-How der SAP®-Datenstrukturen notwendig ist. Wobei hier ein iterativer Ansatz sicher nicht falsch ist. Will heißen, man definiert die Ereignisse auf dem weißen Blatt Papier, eruiert was die Datenbasis auch tatsächlich hergibt und findet dabei unter Umständen weitere Datenspuren, die einen zum Definieren weiterer Ereignisse führen.
In unserem Beispiel haben wir uns dabei ausschließlich mit den wirklichen Bestellungen (Belegtyp „F“) beschäftigt. Ein voll umfängliches Bild ergibt sich eigentlich erst, wenn man auch Rahmenverträge (Belegtyp „K“) und Lieferpläne (Belegtyp „L“) mit einbezieht.
Das richtige Timing
Zu guter Letzt müssen wir unsere Ereignisse noch mit dem richtigen Zeitstempel versehen. Was trivial klingt, ist manchmal gar nicht so einfach. Nicht alle SAP® Tabellen liefern einen Zeitstempel zu einem entsprechenden Datum mit.
Am vermeintlich einfachsten ist es noch, wenn man das Ereignis aus den SAP® Änderungsbelegen erzeugen kann, da man dort in der Kopftabelle CDHDR neben dem Datum auch einen Zeitstempel vorfindet. Auch sollte man sich von dem Begriff „Änderungstabellen“ nicht täuschen lassen. Man findet teilweise auch die zuverlässigen Datumswerte und Uhrzeiten für Neuanlagen in den Tabellen. Dies ist jedoch abhängig vom Änderungsbelegobjekt.
Bei Datumswerten, die sich in den Transaktionstabellen befinden, muss man darauf achten dass es auch wirklich nicht veränderbare Datumswerte sind, die auch die systemseitige Protokollierung des Ereignisses wiederspiegeln. Hier sei als Beispiel das CPU-Datum (CDUDT) bei den Rechnungs- und Wareneingängen genannt. Ein Verwenden von z.B. dem Belegdatum (BLDAT) führt zu „geschönten“ Prozessgraphen. Andererseits kann aber auch manchmal ein manuell veränderbares Datum im Prozessgraphen interessant sein, um z.B. Fälle zu identifizieren bei denen das Belegdatum des Rechnungseingangs vor dem Anlagedatum dieser Bestellposition liegt. Unter Umständen muss man also hier bei der Datenaufbereitung mit einer gewissen Flexibilität ans Werk gehen und die Wahl der Datumsfelder steuerbar machen oder gleich mit mehreren unterschiedlichen Datumsspalten arbeiten und beim Import in die Process-Mining-Software entscheiden welches Datum man nimmt.
Abschließend sei gesagt, dass einem SAP® bei manchen Datumswerten eine wirklich schwere Zeit gibt. Ein eindeutig definierbares Anlagedatum einer Bestellanforderung konnte ich z.B. nicht ausfindig machen. Das Datum in der Tabelle EBAN protokolliert auch alle Änderungen und ist somit ein Datum der letzten Änderung und die Anlage einer BANF-Position wird im Gegensatz zu den Bestellpositionen NICHT in den Änderungsbelegen protokolliert. Sollte hier einer der Blogleser einen weiterführenden Hinweis haben, wäre ich dankbar.
Das Thema „Timing“ werden wir in der nächsten Folge nochmal aufnehmen, da es nicht nur beim reinen Zuordnen eines Zeitstempels zu den Ereignissen relevant ist, sondern auch im Allgemeinen besonderer Sorgfalt bedarf, unter anderem beim zeitlichen Einschränken von Datenextraktionen und Aufbereitungen, da man mit jeder Einschränkung natürlich Gefahr läuft unvollständige Prozessketten zu erzeugen. Wie wir Extraktions-seitig und auch auf Seiten von DISCO damit umgehen können, beschäftigt uns beim nächsten Mal.