Process Mining mit bupaR

Process Mining schafft Transparenz darüber, was wirklich in Unternehmen geschieht.
Im Prozessmanagement werden die Idealvorstellungen eines Prozesses meist langwierig definiert. In der Praxis ist die Qualität dieser Beschreibungen jedoch oft nicht eindeutig bestimmbar. Es ist zudem häufig unklar, inwieweit der beschriebene Prozess wirklich ausgeführt wird.

Auf Basis von existierenden Daten in IT-Systemen wird mit Process Mining der reale Prozess automatisiert identifiziert und visualisiert. So können mit diesem neu generierten Prozesswissen Schwachstellen und ungenutzte Potenziale von Geschäftsprozessen aufgedeckt werden.

Wir stellen Process Mining im Folgenden anhand eines einfachen Beispiels vor. Wir untersuchen den Ablauf von Arbeitsschritten, der zu Zahlungseingängen von Projekten führt. Dabei ist sowohl die Auftragsabwicklung als auch die Rechnungsstellung relevant. Allein mit dem Prozessplan können wir Indizien für Optimierungspotenziale wie beispielsweise einen ineffizienten Abrechnungsprozess aufdecken.

In diesem Blogpost möchten wir einen schnellen Einstieg in Process Mining mit der Open Source Software bupaR ermöglichen. Dazu geben wir zunächst einen Überblick über den Anwendungsfall und führen sowohl in Process Mining als auch in bupaR ein. Anschließend folgt eine Beschreibung der Vorgehensweise mit bupaR und unsere daraus resultierenden Erkenntnisse.

Was ist der Anwendungsfall?

Mit Process Mining identifizieren wir, welche Arbeitsschritte in welcher Reihenfolge wirklich erfolgen, bis ein Projektauftrag zu einer eingehenden Zahlung führt. Dazu nutzen wir Daten aus einer Unternehmenssoftware, die Arbeitsschritte zur Angebots- und Rechnungsabwicklung speichert. Die Arbeitsschritte werden in der Vertriebs- und Finanzabteilung durch das Bedienen der Software erzeugt. Jeder Arbeitsschritt ist eine sogenannte Aktivität. Wir beobachten insgesamt folgende fünf Aktivitäten:

1. Angebot erstellt
2. Auftrag erstellt
3. Rechnung erstellt
4. Fälligkeit erreicht
5. Zahlung erhalten

Die Ausführung der Aktivitäten zu bestimmten Zeitpunkten führt zu Ereignissen (z. B. Rechnung erstellt am 01.02.2020 um 12:01:20). Diese Ereignisse lassen sich einem eindeutigen Merkmal des Projekts zuordnen (z. B. Rechnung erstellt am 01.02.2020 um 12:01:20 für das Projekt „Process Mining“). Die daraus entstehenden Ereignisdaten sind demnach ein Tupel

• einer Identifikationsnummer(ID),
• einer Aktivität und
• einer Zeitangabe.

Zusätzlich besteht die Möglichkeit, Metadaten wie beispielsweise Standort, Kunde oder Umsatz hinzuzunehmen, um die Analysemöglichkeiten zu erweitern.

Wir haben unstrukturierte Ereignisdaten aus der Unternehmenssoftware exportiert und mithilfe eines ETL-Tools aufbereitet. Eine Vorverarbeitung der Daten ist meist sinnvoll, um Inkonsistenzen zu beseitigen. So würde frühzeitig auffallen, dass z. B. Verknüpfungen in den Daten fehlen oder Widersprüche vorliegen. Zudem können die Daten dabei in das passende Format transformiert und zu einem Datensatz aggregiert werden. Ziel ist es, einen automatisierten Vorgang zu implementieren, um manuellen Aufwand zu minimieren und dynamische Daten nutzen zu können.

Was ist Process Mining?

Process Mining rekonstruiert auf Basis von in IT-Systemen gespeicherten Ereignisdaten den Geschäftsprozess. Diese Technik verbindet die klassische Prozessanalyse und Data Mining. Unter Data Mining kann eine systematische Anwendung von Methoden und Algorithmen zur automatisierten Extraktion von Zusammenhängen in Datenmengen verstanden werden.

Für die Umsetzung von Process Mining existieren eine Vielzahl von Algorithmen, die zur Ermittlung der Prozesse entwickelt wurden. Jeder davon hat das Ziel, den Prozess bestmöglich zu identifizieren und darzustellen. Der erste und wohl bekannteste Algorithmus ist der Alpha Miner. Viele Algorithmen greifen Ideen des ersten Miners auf und entwickeln diese weiter. Der Alpha Miner scannt die Prozessdaten nach bestimmten Mustern und stellt so Verbindungen her. Anhand eines kleinen Beispiels soll diese Vorgehensweise verdeutlicht werden.

Beispiel: Ein Prozess wird mit der Symbolik <> von einem anderen Prozess abgegrenzt. Die innerhalb eines Prozesses aufeinanderfolgenden Schritte (hier: a, b und c) sind durch Kommata getrennt. Wenn b auf a folgt, a aber nie auf b, dann wird angenommen, dass eine kausale Abhängigkeit zwischen b und a besteht. Die erkannten Muster werden üblicherweise mit einem Pfeil dargestellt.

Darauf aufbauend werden mit Process Mining, ähnlich wie im klassischen Prozessmanagement, die Prozesse oft in einem Prozessplan dargestellt. Dieser visualisiert die Reihenfolge der Arbeitsschritte in einem Flussdiagramm.

Darüber hinaus bietet Process Mining viele weitere Möglichkeiten, den Prozess zu analysieren und abzubilden. So können beispielsweise Durchlaufzeiten oder Doppelarbeiten detailliert untersucht werden, um Optimierungspotenziale aufzudecken.

Was ist bupaR?

bupaR (Business Process Analysis R) ist eine integrierte Suite der Programmiersprache R. Die Open Source Software entstand bei einer ehrenamtlichen Forschung an der Universität Hasselt (BEL), betreut von Gert Janssenswillen (bupaRs Page ).

Die Suite besteht aktuell aus acht Paketen. Das zentrale und gleichnamige Paket bupaR beinhaltet die Basisfunktionen und ermöglicht Process Mining auf verschiedenen Stufen der Prozessanalyse durchzuführen. Weitere Pakete konzentrieren sich u. a. auf die deskriptive Beschreibung des Prozesses oder auf die Prozessvisualisierung.

In bupaR werden die Ereignisdaten in Ereignisprotokollen gespeichert. Auf dieser Grundlage entwickelt der Algorithmus in bupaR iterativ die Reihenfolge der Aktivitäten. Es wird zudem sowohl der Apha Miner als auch der Inductive und Heuristic Miner in bupaR unterstützt.

Process Mining mit bupaR bietet neben der automatischen Erzeugung des Prozessplans weitaus mehr Möglichkeiten, um tiefer in die Prozessanalyse einzusteigen. So können u. a. einzelne Abfolgen von Aktivitäten oder Durchlaufzeiten intensiver untersucht werden.

Wie wird bupaR verwendet?

Die Anwendung von bupaR erfolgt in der Entwicklungsumgebung RStudio. Bevor das Ereignisprotokoll mit den Ereignisdaten erstellt wird und die Prozessanalyse starten kann, müssen die notwendigen Pakete installiert und geladen werden.

In unserem Anwendungsfall verwenden wir die Pakete bupaR und processmapR der bupaR Suite und readr zum Einlesen der Daten. Mit dem Laden des Pakets bupaR werden automatisch die verwandten Pakete mitgeladen (hier: processmapR).

#Installieren der notwendigen Pakete

install.packages(“readr”)        #Einlesen der Daten
install.packages (“bupaR”)       #Basisfunktionen Process Mining
install.packages (“processmapR”) #Visualisierung des Prozesses

#Laden der notwendigen Pakete

library(readr)
library(bupaR)

Im Rahmen der Vorverarbeitung haben wir die Daten bereits aufbereitet und in eine einheitliche Struktur zusammengeführt. Als Resultat haben wir den in Abbildung 1 dargestellten Datensatz mit den Spalten ID, Aktivität und Zeitangabe erhalten. Wichtig ist, dass die Zeitangabe als Datum formatiert ist.

Die aufbereiteten Daten werden mit der entsprechenden Funktion in RStudio eingelesen (hier: read_csv zum Einlesen der CSV-Datei).

#Einlesen der Daten

data <- read_csv("Documents/Offer2Cash.csv")

Danach überführen wir die Ereignisdaten mit der Funktion simple_eventlog in ein einfaches Ereignisprotokoll, welches Process Mining mit nur drei Parametern ermöglicht. Wir weisen dem Ereignisprotokoll die Spalten ID (case_id), Aktivität (activity_id) und Zeitangabe (timestamp) zu.

#Erstellen eines einfachen Ereignisprotokolls

eventlog_data <- simple_eventlog(data,
                    case_id ="CaseID",
                      activity_id = "Activity",
                       timestamp = "Timestamp")

Der in Abbildung 2 wiedergegebene Output gibt uns Einblicke in das erzeugte Ereignisprotokoll. Anhand der 2.578 eingelesenen Zeilen hat bupaR 128 unterschiedliche Prozessvarianten und insgesamt 662 Fälle identifiziert. Durch die Zuordnung der Spalten erkennt bupaR die fünf Aktivitäten (Activity) des Datensatzes automatisch. In unserem Anwendungsfall haben wir uns auf den Zeitraum vom 06.06.2019 bis 16.04.2020 beschränkt. Darüber hinaus besteht das Ereignisprotokoll aus vier Spalten mehr als der eingelesene Datensatz. Die Aktivitätsinstanzkennung (activity_instance_id) ermöglicht zusammengehörende Aktivitäten zu verbinden. Dies ist insbesondere dann relevant, wenn verschiedene Stati je Aktivität angegeben werden. So würden beispielsweise die Aktivitäten „Rechnung erstellt – Start“ und „Rechnung erstellt – Beendet“, die sich auf die gleiche Rechnung beziehen, eine identische Kennung erhalten. In unserem Anwendungsfall berücksichtigen wir keine Stati, so dass jede Aktivität eine eigene Kennung erhält. Die Ressourcenkennung (resource-id) bleibt bei der Verwendung eines einfachen Ereignisprotokoll undefiniert, da keine Zuordnung von Ressourcen in der Funktion erfolgt. Eine Ressource könnte beispielsweise ein Mitarbeiter, ein Standort o. ä. sein. Die Lebenszykluskennung (lifecycle_id) bezieht sich ebenfalls auf verschiedene Stati der Aktivitäten und bleibt somit in unserem Beispiel undefiniert. Anhand der Zeitangaben wird die Reihenfolge (order) von Aktivitäten in bupaR automatisch ermittelt.

Anschließend starten wir mit der Entdeckung des Prozesses. In unserem Anwendungsfall beschränken wir uns auf die Erstellung des Prozessplans. Mit der Funktion process_map wird die Reihenfolge der Aktivitäten automatisiert in einem Prozessplan visualisiert. In der Standardeinstellung werden alle Prozessvarianten dargestellt, sowie die Aktivitäten und Pfeile mit absoluten Häufigkeiten annotiert. Um sich weitere Versionen des Prozessplans ausgeben zu lassen, kann das sogenannte Frequenzprofil (frequency) und Performanceprofil (performance) angepasst werden.

Zunächst lassen wir uns den am häufigsten vorkommenden Prozess angeben. Dazu nutzen wir die Filterfunktion des Frequenzprofils (filter_trace_frequency). In diesem Fall lassen wir uns die häufigsten vorkommenden Prozessvariationen anzeigen bis 1 % aller Prozessvarianten erreicht ist.

#Erstellen des am häufigsten vorkommenden Prozesses

eventlog_data %>%
 filter_trace_frequency(perc = 0.01) %>%
  process_map()

In Abbildung 3 können wir anhand des Prozessplans erkennen, dass der häufigste vorkommende Prozess aus drei Aktivitäten besteht. In 105 Fällen beginnt der Prozess mit der Rechnungsstellung. Bevor die Zahlung eingeht, wird die Zahlungsfrist überschritten.

Mit der Änderung des Frequenzprofils erhalten wir weitere Informationen über den Prozess und erstellen einen erweiterten Prozessplan. Wir lassen uns mit der Filterfunktion bis zu 70 % der Prozessvarianten anzeigen. Zusätzlich ändern wir die Kommentierung der ausgehenden Verbindungspfeile je Aktivität (type_edges) zu relativen Häufigkeiten.

#Erstellen des erweiterten Prozessplans

eventlog_data %>%
 filter_trace_frequency(perc = 0.7) %>%
  process_map(type_edges = frequency("relative"))

Der erweiterter Prozessplan in Abbildung 4 liefert uns Informationen darüber, dass (nur) in 40 % der Fälle die Rechnungserstellung die erste Aktivität ist. Alternativ startet der Prozess mit der Erstellung des Auftrags oder Angebots. In der Regel startet ein Projekt mit einem Angebot und anschließendem Auftrag bevor erstmalig eine Rechnung erstellt wird. Die Angebots- und/oder Auftragserstellung liegt in den Fällen, die nicht mit dieser Reihenfolge starten, vermutlich vor dem gewählten Zeitraum. So ist eine Rückwärtssuche für diese Fälle sinnvoll, d. h. die Daten für die betreffenden Projekte werden um die Aktivitäten Angebotserstellung und ggf. Auftragserstellung mit den jeweiligen Zeitangaben ergänzt. Außerdem beobachten wir, dass in 41 % der Aufträge noch keine Rechnung erstellt ist und von den erstellten Rechnungen in 50 % die Zahlungsfrist überschritten wird. Darüber hinaus stellen wir fest, dass sogar Fälle vorkommen, in denen die Zahlung vor Fakturierung der Leistung eingeht.

Zusätzlich zum Frequenzprofil kann das Performanceprofil eingestellt werden. Wir erstellen einen Prozessplan mit Durchlaufzeiten und lassen uns die durchschnittliche Zeit je aufeinanderfolgende Aktivität in Tagen ausgeben. Diesmal geben wir die relativen Häufigkeiten je Aktivität (type_nodes) in Bezug auf die Gesamtzahl der Fälle an.

#Erstellen des Prozessplans mit Durchlaufzeiten

eventlog_data %>%
 filter_trace_frequency(perc = 0.7) %>%
  process_map(type_nodes = frequency("relative"),
   type_edges = performance(mean, "days"))

Mit der Hinzunahme des Performanceprofils entnehmen wir dem Prozessplan in Abbildung 5, dass die Dauer zwischen der Auftrags- und Angebotserstellung im Durchschnitt 19 Tage beträgt. Zudem fällt auf, dass sofern die Zahlungsfrist der Rechnung überschritten wird, die Zahlungen durchschnittlich weitere 11 Tage später verbucht werden. Gehen die Einnahme vor der Rechnungsstellung ein, beträgt die Bearbeitungszeit im Durchschnitt 26 Tage.

Was sind unsere Erkenntnisse?

Process Mining mit bupaR ermöglicht, mit einfachen Ereignisdaten und einem Bruchteil der Analysemöglichkeiten bisher unbekannte Erkenntnisse über den Prozess zu erhalten. So kann die Qualität bestehender Prozessbeschreibungen überprüft oder sogar die langwierige Definition von Prozessen ersetzt werden. Wir haben mithilfe des Frequenzen- und Performanceprofils drei verschiedenen Prozesspläne erstellt. Anhand dieser haben wir die tatsächliche Reihenfolge der Aktivitäten von Projektangebot bis Zahlungseingang ausfindig gemacht.

Wir haben festgestellt, dass bei einer Vielzahl der Rechnungen die Zahlungsfrist überschritten wird. Diese Information kann uns Aufschluss über die Zahlungsbereitschaft der Kunden geben und auf mögliche Liquiditätsengpässe hindeuten.

Zudem haben wir erkannt, dass zu bestehenden Aufträge noch keine Rechnung erstellt wurde. Dies kann zur Folge haben, dass zustehende Einnahmen nicht beansprucht werden.

Darüber hinaus beobachten wir, dass zum Teil Zahlungen vor der Rechnungsstellung eingehen. Dies kann ein Indiz dafür sein, dass der Abrechnungsprozess nicht effizient ist.

Insgesamt lässt sich sagen, dass Process Mining mit bupaR bereits mit wenig Aufwand realisierbar ist. Die Open Source Software bupaR bietet umfangreiche Möglichkeiten, um Process Mining kostengünstig zu verproben.

Wir haben Ihre Neugierde an den Möglichkeiten von Process Mining geweckt? Kontaktieren Sie uns für ein unverbindliches Erstgespräch direkt.