Über unsMediaKontaktImpressum
Ronja Köhling & Benjamin Wolters 11. Mai 2021

Process Mining in 5 Schritten

Geschäftsprozesse zu automatisieren ist erfolgsentscheidend, die real gelebten Prozesse zu kennen unerlässlich. Beide Faktoren adressiert Process Mining in erstaunlich guter Qualität. Doch wie startet man mit Process Mining, welche Werkzeuge sind notwendig und wie werden schnell Resultate erzeugt? Diesen Fragen widmen wir uns und ermöglichen so einen unkomplizierten Einstieg in das Thema Process Mining – denn bereits mit wenigen Schritten ist es möglich, überraschende Ergebnisse zu erzielen.

Warum Process Mining?

Leistungsverläufe in der Versicherung, Warenbewegungen in der Logistik, Kundenentwicklungen allgemein oder Aufgabenverteilung in Projektteams. In all diesen Fällen verstecken sich neben den etablierten Geschäftsprozessen weitere und häufig unsichtbare Wertschöpfungsprozesse. Prozesse, die mindestens gedachten Sollprozessen folgen und ebenso in einigen Fällen abweichen. Die Gründe für Abweichungen sind vielseitig – beispielsweise Fehlbedienungen, Shortcuts, sowie intransparente oder versteckte Prozessschritte. Process Mining (PM) ermöglicht, diese Abweichungen aufzuzeigen und Ursachen zu identifizieren. Zudem liefert PM Kennzahlen über verwendete Ressourcen und durchgeführte Tätigkeiten der untersuchten Prozesse. Je genauer die tatsächlich gelebten Prozesse bekannt sind, desto eher werden Fehler identifiziert und Optimierungspotenziale gefunden. Mit der gewonnenen Transparenz über Kennzahlen ermöglicht PM die Prognose von Änderungen am Prozess. Die Datenquellen für PM sind vielseitig – Datenbanken, ERP-Systeme, Applikationslogs und Schnittstellen der verwendeten IT-Systeme können verwendet werden.

Wie hoch ist die Einstiegshürde?

In nur fünf Schritten können erste Erkenntnisse mit PM gewonnen werden und die Grundlage für weitere Iterationen und automatische Prozessanalyse geschaffen werden.

Schritt 1: Potenziale erkennen

Im ersten Schritt ist es wichtig, sich mit den Prozessen zu befassen – Fragen sind der richtige Weg. Welches Produkt, welche Tätigkeiten oder welcher bestehende Geschäftsprozess erscheint wandelbar? Für welchen Ablauf werden unterschiedliche IT-Systeme benötigt? Wo könnte fehlendes Prozesswissen oder Intransparenz zu Fehlern führen? Vielleicht existieren bereits Vermutungen für Potentiale, ohne diese konkret zu beziffern. Die Fragestellungen orientieren sich am Anwendungsfall und können vielseitig sein. Beispielsweise wie lange befindet sich Ware im Lager oder wie oft wird Ware ohne Qualitätssicherung eingelagert?

Data-Science-Analysen erfordern ein möglichst detailliertes Fachwissen über den untersuchten Geschäftsbereich. Das Vorgehensmodell CRIPS-DM [1] spricht hier von Business Understanding. Auch für PM ist dieser Schritt unverzichtbar, denn es müssen Prozesse verstanden und Anforderungen eingeschätzt werden. Das Ergebnis dieses Schrittes ist ein Überblick der Fragen, Ziele und Motivation. In der ersten Iteration können diese Fragestellungen noch nicht detailliert spezifiziert sein, doch sie bieten Anhaltspunkte für die weitere Datenaufbereitung. Spätestens nach einer ersten Visualisierung der Prozessdaten und einem Austausch mit dem Fachbereich (Schritt 4) lohnt es sich, zu diesem Schritt zurückzukehren und die Fragestellungen zu schärfen.

Schritt 2:  Involvierte Systeme verstehen

Daten, Daten, Daten? PM profitiert von einer großen Datenmenge und vielseitigen Datenquellen. Sowohl die involvierten IT-Systeme als auch dessen Daten müssen identifiziert werden. Meist ist es überraschend, welche Daten nicht nur in der Datenbank, sondern auch in Logs oder Dateiablagen zu finden sind und ein hohes Potential für PM bieten. Diese müssen nicht live aus dem Produktivsystem gelesen werden. Historische Daten aus dem Archivsystem oder ein gezielter Export genügen völlig für erste Erkenntnisse und den Aha-Effekt.

Nur Eins ist wichtig: Die Daten müssen miteinander in Beziehung stehen. Dies kann über Kundennummern, Adressen, Versicherungsnummern, JIRA-Tickets, Artikel oder Aufträge erfolgen.

Beziehungen müssen nicht durchgehend dasselbe identifizierende Merkmal aufweisen. Möglich und durchaus üblich sind wechselnde Merkmale oder auch Kombinationen. Beispielsweise beginnt eine Kundenbeziehung mit einem Angebot, daraus entsteht ein Kunde, daraus folgen im Laufe der Zeit viele verschiedene Angebote. Sind alle Verantwortlichen mit im Boot und Zugang zu den Daten gewährt, dann geht es los.

Betrachten wir unseren Anwendungsfall: In einem Logistikzentrum werden alle Varianten der Warenbewegungen von Wareneingang bis zum Versand gesucht, um die üblichen Herausforderungen wie Aufwand, Schwund, Fehlbedienungen und Verspätungen zu minimieren. Die relevanten Informationssysteme umfassen das Warenwirtschaftssystem WMS und alle am Warenfluss beteiligten Systeme. Im WMS werden die Warenbewegungen mindestens die Informationen aus Tabelle 1 enthalten.

Tabelle 1: Bewegungen im WMS

Lagereinheit IDLagerort vonLagerort nachStartzeitpunktEndzeitpunkt
7346WareneingangHochregallager2021-02-12 08:252021-02-12 08:38
7346HochregallagerPackplatz2021-03-02 13:322021-03-02 13:51
...    

Das WMS enthält zusätzlich Informationen über die Kommissionierung, zum Beispiel welche Lagereinheit welchen Auftrag bedient hat. Tabelle 2 zeigt die entsprechenden Informationen.

Tabelle 2: Kommissionier-Informationen

Lagereinheit IDPackplatzAuftragsnummerPackzeitpunktMenge
7346Packplatz 0325658692021-03-02-14:00100
7346Packplatz 0312345672021-03-02 14:05100
1234Packplatz 0225658692021-03-02 14:00100

Häufig sind die Versandinformationen in einem eigenen IT-System hinterlegt. Identifizierende Merkmale des WMS ändern sich und werden mit dem Versandsystem verknüpft. In Tabelle 3 findet sich die Auftragsnummern wieder.

Tabelle 3: Versand-Informationen

AuftragsnummerVersand IDVerladestartVerladeendeVersand Soll
256586913023492021-03-02 14:26:452021-03-02 19:132021-03-02 17:00
256523813023492021-03-02 12:13:022021-03-02 19:132021-03-02 17:00
123456732165472021-03-03 08:002021-03-03 08:452021-03-03 09:00

Erfahrungsgemäß lohnt sich eine detaillierte Betrachtung der Zeitangaben, denn Doppelbuchungen aufgrund von Fehlern, Kundenspezifika oder weiteren Gründen sind häufig.

Schritt 3: Prozesse identifizieren

Hier beginnt der eigentliche Aufwand des PM. Vor allem ist das Potenzial technischer oder fachlicher Fehlannahmen hoch. Glücklicherweise gestaltet sich diese Phase sehr iterativ – mit vielen schnellen Erkenntnissen über die sich sehr gut sprechen lässt. Fachbereich und Analyst:innen werden gut zusammenarbeiten.

Was ist eine Prozessinstanz?

Prozessinstanzen bilden einen zusammenhängenden Prozessdurchlauf ab. Jeder Prozess umfasst mehrere Prozessschritte [2]. Eine Aktivität, wie beispielsweise die Annahme der Waren im Wareneingang oder die Einlagerung im Palettenlager, stellt solch einen Prozessschritt dar. PM setzt diese Aktivitäten zueinander in Beziehung. Für jede Prozessinstanz sind die Aktivitäten anhand eines identifizierenden Merkmals erkennbar. Solch eine ID kann beispielsweise die Auftragsnummer sein. Eine Prozessinstanz ist idealerweise autark und nicht ganz oder teilweise in weiteren Prozessinstanzen involviert. In der Praxis gibt es hier Sonderfälle, bei denen einzelne Prozessinstanzen zusammengeführt oder aufgeteilt werden. Ein Beispiel aus der Lagerlogistik: Eine Kommissionierung kann nur eine Teilmenge der Artikel einer Lagereinheit entnehmen oder eine angelieferte Palette kann in mehrere Lagereinheiten aufgeteilt werden. Die Lagereinheit ist somit an mehreren Kommissionierungen beteiligt, wie in Tabelle 2 deutlich wird. Die Prozessinstanzen sind also nur autark, wenn pro Zeile aus Tabelle 2 eine Prozessinstanz erstellt wird und die Bewegungen aus Tabelle 1 pro Prozessinstanz dupliziert wird.

Wie erfolgt Process Mining?

Sobald die Daten als Export vorliegen oder die Systemzugänge zur Datenextraktion bereit sind, werden Event Logs generiert. Diese stellen den Startpunkt von PM dar und umfassen Events in Form von Aktivitäten der Prozessinstanzen [3]. Der Aufwand, um solch ein Event Log zu generieren variiert stark mit der Art des Datenmodells. Im Beispiel der Warenbewegungen sind die Tabellen bereits sehr günstig strukturiert. Dies muss nicht immer so sein, sondern ist abhängig vom vorhandenen System und der betrachteten Fragestellung. Wird ein Workflow-Management-System genutzt, ist es oft möglich, ein Event Log direkt zu exportieren. Liegen die Daten hingegen in verschiedenen Informationssystemen und Dateien, so ist der Aufwand größer – vor allem, wenn Zeitpunkte nicht eindeutig sind. Häufig setzt sich ein vermeintliches Event aus mehreren Systemen zusammen, dann empfiehlt es sich, dieses in Events der einzelnen Systeme zu unterteilen.

Die meisten Standardtools benötigen mindestens die folgende Struktur eines Event Logs:

  • Case ID – Die Prozessinstanz wird mit einer eindeutigen ID versehen. Diese wird häufig durch den Algorithmus vergeben, welcher das Event Log erstellt.
  • Activity – Die Aktivität, die in diesem Prozessschritt ausgeführt wird. Beispielweise die angesprochene Kommissionierung von Artikeln aus einer Lagereinheit in eine Auftragsposition.
  • Zeitpunkt – Der Zeitpunkt, zu dem das Event ausgeführt wurde.

Neben diesen drei Feldern empfiehlt es sich, noch weitere Kennzahlen pro Aktivität zu speichern. Hierzu zählen beispielsweise die Nutzer:innen, das Informationssystem oder die Menge. Wer nicht nur betrachten möchte, welche Zeit zwischen den einzelnen Aktivitäten vergangen ist, sondern auch wie lange ein Event dauerte, der arbeitet mit Start- und Endzeitpunkt. Welche Daten betrachtet werden, hängt von den in Schritt 1 definierten Fragestellungen ab. Dies ist die Datenbasis für weitere Analysen und wird in der Regel als Tabelle strukturierter Daten dargestellt – dies bietet Chancen für deskriptive Statistik oder den Einsatz von künstlicher Intelligenz.

Event Logs des Logistikzentrums

Kehren wir zu dem in Schritt 2 vorgestellten Anwendungsfall zurück. Wie sollte hier das Event-Log aussehen? Um die Arbeitsweise des Logistikzentrums zu analysieren, Fehler zu entdecken und Ursachen für Verspätungen zu finden, bietet sich eine versandte Auftragsposition an. Eine Auftragsposition definiert sich aus einem Artikel in der entsprechenden bestellten Menge in einem Auftrag.

Aber Obacht: 500 Stück desselben Artikels in einer Auftragsposition können aus zwei Lagereinheiten a 300 Artikel kommissioniert worden sein. Also das Gegenteil des Beispiels oben, in dem eine Lagereinheit mehrere Aufträge bedient. Auch hier werden zwei Case IDs vergeben, wenn der exakte Warenfluss betrachtet wird.

Nehmen wir an, eine Verladung, die nach dem geplanten Versandtermin liegt, ist verspätet. Entsprechend wäre das erste Packstück verspätet, während das zweite pünktlich ist. Um nun ein einheitliches Event Log zu erzeugen, müssen die verschiedenen Datensätze zusammengeführt werden und eine Case ID zugeordnet werden. Bei der Kommissionierung werden mehrere Lagereinheiten in ein Packstück kommissioniert. Das heißt, anhand der Kommissionierungsdaten wird ein Join der beiden Datensätze ermöglicht. Da der Prozessfluss des Packstücks zu betrachten ist, werden alle Bewegungen, die in das Packstück führen, mit der Case ID versehen. In dem nachfolgenden Python-Code-Ausschnitt wird beschrieben, wie aus den finalen Tourdaten die Prozessinstanzen im WMS identifiziert werden. Es wird der Sonderfall beachtet, in dem die Bewegungen aus beiden Systemen verknüpft werden und sich die IDs der Lagereinheiten durch Aufteilungen oder Zusammenführungen ändern können. Um autarke Prozessinstanzen zu erzeugen, werden die Bewegungen vom Verladeplatz aus rückwirkend Prozessen zugeordnet.

Listing 1: Logistikdaten Backtracking Algorithmus

"""
Backtracking algorithm

Identify related movements and link them with a common ID. Splits and merges of storage units that converge into a common packing unit are considered as one process instance. 
"""

import pandas as pd

def backtracking_process_information(movements_wms_data, tour_data):
    remaining_movements = movements_wms_data.copy()

    def find_prior_movements(current_movements, remaining_movements):
        
    new_candidates = pd.merge(current_movements, remaining_movements, 
left_on = [source_place,source_id], 
right_on = ['target_place',"target_id"], suffixes=['','_remaining'])
    prior_movements = new_candidates.\ 
 				loc[new_candidates.time_update_remaining <= 
new_candidates.time_creation]
    prior_movements["successor"] = prior_movements["movement_id"]
    prior_movements = prior_movements [domain_specific_columns_and_joined_identifier]

    prior_movements.columns = prior_movements.columns.replace('_remaining','')
 	prior_movements = prior_movements\
.sort_values (by=['time_update','time_creation'], ascending=False) \       .drop_duplicates(subset=['source_place','source_id','target_id','target_place','packing_id'])

     return prior_movements
	
	# The first iteration starts with the tour data to identify all dispatched packing units
    prior_movements = find_prior_movements(tour_data,remaining_movements)
    result = packing_information.append(prior_movements)
    while len(prior_movements) > 0:
        remaining_movements = remaining_movements\ 
.loc[ ~remaining_movements.movement_id\ .isin(prior_movements.movement_id) ]
        prior_movements = find_prior_movements(prior_movements,remaining_movements)
        result = result.append(prior_movements)

    return result, remaining_movements

Der Algorithmus erzeugt einen Datensatz mit zusammenhängenden Von-An-Bewegungen. Wie in Tabelle 1 wird jede Bewegung durch einen Ursprungsort und den Zielort definiert. Durch den Algorithmus wurden eine fortlaufende Prozess ID und weitere Informationen, wie die Auftragsnummer, hinzugefügt. Die Informationen der Prozessinstanz sind also zweimal enthalten: einerseits als Ursprungsort und andererseits als Zielort.

Wichtig für den Prozess ist allerdings die Aktivität an einem Lagerbereich und nicht die Bewegung Von-An. Eine Möglichkeit ist, die aktuellen Bewegungen in eine Aktivität des Von-Lagerbereichs zu transformieren und am Prozessende noch eine Aktivität "Verladen" anzufügen. Aus den Endzeitpunkten lassen sich direkt die Ankünfte im jeweiligen Lagerbereich ermitteln, so dass pro Zeile nun eine Aktivität "Wareneingang"->"Ware vereinnahmen" wird. Es entsteht folgendes Event Log:

Tabelle 4: Event Log

Case IDLagerortAktivitätZeitpunkt StartZeitpunkt EndeVerspätungAuftragsnummerVersand IDMengePlatz
2565869WareneingangWare vereinnahmen2021-02-12 08:122021-02-12 08:2512565891302349100Wareneingang 02
2565869HochregallagerWaren lagern2021-02-12 08:382021-03-02 13:3212565891302349100Lagerplatz 32
2565869KommissionierungWaren kommissionieren2021-03-02 13:512021-03-02 14:0312565891302349100Packplatz 03
...         

Schritt 4: Prozesse explorieren

Jetzt zeigen sich Ergebnisse. Die strukturierten Prozessdaten (das Event Log) können mit freien Anwendungen analysiert werden. Die Grundfunktionalität dieser Tools ist Process Discovery, also die Erkennung von Prozessabläufen in Event Logs oder Systemdaten. Die grafische Darstellung als Prozessmodell liefert die gemeinsame Basis, um auf Augenhöhe mit den Domänenexpert:innen zu kommunizieren. Diese geben Tipps für Verbesserungen, beseitigen mögliche Fehler und werden sicherlich überrascht von einigen Details – Prozessverläufe, die sie so nicht erwartet hätten – oder erläutern verstecktes Prozesswissen. In der Regel ergibt sich in dieser Phase viel Feedback für die Datenaufbereitung. Zudem bekommen die Analyst:innen Fragestellungen der Fachbereiche mitgegeben. Es ergibt sich ein Erkenntniszyklus, welcher Handlungsempfehlungen für Prozessanpassungen erzeugt.

Welche Kennzahlen sind für PM relevant?

Der durch Process Discovery erzeugte Prozess bildet die Grundlage für alle Bereiche des PM, wie beispielsweise Compliance Checking, Simulation und die Auswertung der Prozesse anhand verschiedener Statistiken.

Mögliche Statistiken umfassen:

  • Prozessdauer,
  • Wartezeitenanalyse und
  • Genutzte Ressourcen.

Im Kontext des Anwendungsfalls der Lagerlogistik sind beispielsweise die Wartezeiten an Ressourcen, die ein Bottleneck darstellen könnten, relevant. Außerdem lässt sich die Auslastung einzelner Lagerbereiche analysieren und mit dem gewonnenen Wissen die Lagerperformance optimieren.

Welches Tooling ist geeignet?

Apromore und PM4Py sind zwei freie Software-Tools für Process Mining [4,5]. Beide Tools ermöglichen es, schnelle Ergebnisse zu erzielen. Apromore bietet eine kollaborative Plattform. Durch ein einfaches und interaktives Interface ist die Einstiegshürde gering. PM4Py hingegen ist eine Python-Library für PM. Sie bietet eine gute Integrationsmöglichkeit in bereits bestehende Data-Science-Projekte.

Explorative Analyse mittels Apromore

Apromore gehört zu den Standardtools für PM und eignet sich großartig für exploratives Arbeiten im Team [6]. Es ist lediglich notwendig, das Event Log in Apromore zu importieren, um eine Prozessdarstellung zu erhalten (s. Abb. 1). Apromore bietet verschiedene Möglichkeiten, den Prozess zu analysieren. Zwei sind besonders spannend, um einen ersten Überblick zu gewinnen: Abstraktion und Filterung. Die Schieberegler in der Mitte des Tools ermöglichen eine Abstraktion des Graphens. In der Grafik sind Nodes und Arcs auf 100 gesetzt, das heißt, es werden alle Knoten und Kanten angezeigt. Das ermöglicht Prozessabweichungen, wie die Kante vom Wareneingang zum Packplatz zu erkennen. Allerdings können die Graphen bei großen Logs schnell unübersichtlich werden. Eine Reduzierung der Kanten und Knoten, so dass nur die meistgenutzten Prozesspfade angezeigt werden, ermöglicht einen allgemeineren Überblick. Mithilfe des Filters können Prozessinstanzen anhand Kriterien, wie den Aktivitäten, gefiltert werden. Auf diese Weise können nur die Prozessinstanzen angezeigt werden, die verspätet sind und erste Ursachenanalysen durchgeführt werden.

Mehr Möglichkeiten, weniger Interaktion mit PM4Py

In PM4Py ist dasselbe Ergebnis in wenigen Zeilen Code zu erreichen. PM4Py verwendet den IEEE XES Standard für Process Logs [7]. In unserem Beispiel liegt als Ergebnis der Datenaufbereitung eine CSV-Datei vor. Daher werden die Daten zunächst eingelesen und konvertiert. Um die durch PM4Py bereitgestellten Algorithmen zu nutzen, werden die Spalten in das einheitliche Format umbenannt. time:timestamp ist der Zeitpunkt der Aktivität, case:concept:name die Case ID und concept:name die Aktivität.

from pm4py.objects.conversion.log import converter as log_converter 
import pandas as pd

eventlog = pd.read_csv('D:\Projekte\Beispiel.csv', sep=';')
eventlog = eventlog.rename(columns={'Zeitpunkt Start': 'time:timestamp',  'Case Id': 'case:concept:name', 'Event': 'concept:name'})
log = log_converter.apply(eventlog)

PM4Py bietet vier Algorithmen für Process Discovery – Alpha, Alpha+, Heuristic und Inductive Miner. Im nachfolgenden Beispiel wird der Heuristic Miner angewandt. Der Heuristic Miner basiert auf dem Alpha Miner und ist vor allem für die praktische Anwendung geeignet.

from pm4py.algo.discovery.heuristics import algorithm as heuristics_miner
heu_net = pm4py.discover_heuristics_net(log)
from pm4py.visualization.heuristics_net import visualizer as hn_visualizer
gviz = hn_visualizer.apply(heu_net)
hn_visualizer.view(gviz)

 

Das Ergebnis der Process Discovery in PM4Py ist in Abb. 3 dargestellt. Wie auch im Graphen von Apromore ist eine Prozessabweichung (vom Wareneingang zum Packplatz) direkt erkennbar. Die detaillierte Analyse des Prozesses erfolgt in Python. Der Datensatz kann gefiltert werden und PM4Py bietet weitere Funktionen, beispielsweise Statistiken zur Durchlaufzeit.

Schritt 5:  Erkenntnisgewinnung automatisieren

Ein Dashboard über die wichtigsten Kennzahlen der Prozesse ist eine Möglichkeit, um die erzielten Resultate im Unternehmen zu etablieren. Process Mining geht deutlich weiter. Die Identifikation von Prozessabweichungen kann durch eine Anomalieerkennung automatisiert werden. Ein weiterer Ansatz ist der Einsatz von Machine Learning, um Prognosen zu domänenspezifischen Fragestellungen zu beantworten. Durch Einsatz von Explainable AI (XAI) können Entscheidungen des Modells analysiert und Ursachen erkannt werden. Beide Ansätze basieren auf den als Event Log aufbereiteten Daten.

Um automatisiert Erkenntnisse zu gewinnen, ist es notwendig, folgende Preprocessing-Schritte zu automatisieren. Die generierten Daten können zur Prognose und Anomalieerkennung genutzt werden.

  1. Daten bereitstellen – Die Datenextraktion aus den involvierten IT-Systemen wird automatisiert. Einiges findet sich bereits per ETL im Data Warehouse oder System der Business Intelligence. Die fehlenden Daten werden per ETL hinzugefügt. Je nach umgesetzter Handlungsempfehlung erfolgt dies stündlich bis hin zu monatlich.
  2. Daten verarbeiten – Die BI- oder KI-Plattform erzeugt auf diesen Daten die Prozessdaten mit den PIDs. Die Prozessdaten werden fortlaufend im DWH ergänzt, so dass sich eine Historie ergibt. Diese ist wichtig für spätere Audits oder Rechtfertigungen.

Wie werden Event-Logs automatisiert analysiert?

Anomalieerkennung

Ein definierter Zeitraum, das letzte Jahr, der Prozessdaten wird einer Anomalieerkennung unterzogen. Hierfür eignen sich Methoden wie ein Isolation-Forest oder Autoencoder [8]. Entdeckte Anomalien sind Prozessinstanzen, die von den häufigsten Prozessen abweichen. Diese können in ein Dashboard integriert werden. Hierdurch werden Sonderfälle oder beispielsweise Bedienfehler deutlich. Die Anomalieerkennung sollte regelmäßig neu trainiert und analysiert werden, um sicherzugehen, dass Prozessanpassungen repräsentiert sind.  

Prognosemodell

Machine Learning ermöglicht die Prognose domänenspezifischer Fragestellungen. Bezogen auf das Anwendungsbeispiel sind mögliche Fragestellungen: Wird die betrachtete Palette verspätet versandt oder wird diese Palette abhanden kommen? Je nach Fragestellung eignet sich ein Klassifikations- oder Regressionsmodell. Während das Prognosemodell allein bereits einen Mehrwert bietet, in dem es zur Verbesserung der Prozessabläufe genutzt wird, lohnt es sich einen Blick auf die gelernten Zusammenhänge zu werfen. Durch XAI-Methoden werden Entscheidungen des Prognosemodells nachvollziehbar. Hierfür bieten sich die Feature Importance, SHAPLEY Values oder Partial Dependence Plots an [9,10]. Ist beispielsweise ein spezifischer Lagerplatz ein wichtiger Prognosefaktor für Mengenabweichungen bei der Kommissionierung, so lohnt es sich, diesen zu überprüfen – vielleicht liegt ein technischer Defekt oder eine schlechte Beleuchtung vor.

Fazit

In nur 5 Schritten zu Process Mining Ergebnissen – das haben wir in diesem Beitrag gezeigt. Selbstverständlich sollten gemeinsam mit den Fachbereichen Fragestellungen angepasst und das Prozessverständnis diskutiert werden. Hierdurch entstehen weitere Iterationen der Schritte. Wie bei allen Data-Mining-Projekten ist die Aufbereitung der Daten der aufwändigste Schritt, denn Datenquellen müssen zusammengeführt werden, eine gemeinsame Einheit gefunden und ein Event Log erzeugt werden. Zusammenfassend wird bereits nach einer Iteration ein Mehrwert gewonnen – die Häufigkeit des Standardprozesses ist bekannt, Abweichungen sind sichtbar und der zugrundeliegende Prozess visualisiert. Proaktiv können die Prozessdaten zur operativen Steuerung und Planung von Kapazitäten genutzt werden. Zudem lassen sich Prognosen erstellen, die Sie auf zukünftige Entwicklungen aufmerksam machen. Steuer und Planungspotenzial eröffnen neue Chancen.

Quellen
  1. CRISP-DM
  2. W. van der Aalst et al., 2012: Process Mining Manifesto. In: Daniel F., Barkaoui K., Dustdar S. (eds) Business Process Management Workshops. BPM 2011. Lecture Notes in Business Information Processing, vol 99. Springer, Berlin, Heidelberg.
  3. W. van Der Aalst, 2016: Process mining
  4. Apromore
  5. PM4Py
  6. R. Köhling: Process Mining - Explorative Analyse logistischer Prozesse mittels Apromore
  7. IEEE XES Standard
  8. Dr. F. Köhne: Anomalien mit H2o.ai - Isolation Forests finden und erklären
  9. S. M. Lundberg, Su-In Lee, 2017: A unified approach to interpreting model predictions. Advances in Neural Information Processing Systems
  10. Partial Dependence Plot (PDP)

Autoren

Ronja Köhling

Ronja Köhling ist als IT-Beraterin bei der viadee Unternehmensberatung AG tätig. Ihr Fokus liegt im Bereich Data Science, Maschinelles Lernen, Operations Research und Process Mining.
>> Weiterlesen

Benjamin Wolters

Benjamin Wolters ist Agilist und Technologie-Enthusiast bei der viadee AG. In dieser Rolle koordiniert er den Kompetenzbereich Künstliche Intelligenz.
>> Weiterlesen
Das könnte Sie auch interessieren
Kommentare (0)

Neuen Kommentar schreiben