Die Grundidee des Process Mining besteht in der Erkennung von Prozessen, d.h. der Konstruktion von Prozessmodellen aus einer Ereignis-Logdatei. Das Process Mining unterscheidet dabei zwischen verschiedenen Perspektiven, die jeweils unterschiedliche Sichten auf ein Prozessmodell gestatten. Neben der Kontrollflussperspektive, welche die Abfolge von Aktivitäten in einem Prozess darstellt, lassen sich drei weitere Perspektiven unterscheiden.
Die organisatorische Perspektive dient der Analyse sozialer Netzwerke sowie der allgemeinen Organisationsstruktur im Unternehmen. Die Fallperspektive analysiert die Entscheidungsfindung von Prozessen und dient dem Unternehmen zum besseren Verständnis von Entscheidungsprozessen. Die Zeitperspektive dient der Identifizierung von Engpässen und Performanceproblemen innerhalb eines Prozesses. Darüber hinaus können die verschiedenen Perspektiven in einem einzigen Modell zusammengeführt werden um eine integrierte Sicht zu erhalten. In dieser Seminararbeit werden die weiteren Perspektiven zusammenfassend beschrieben und anhand von Beispielen aufgearbeitet.
Inhalt
1 Einleitung
2 Ereignislog weiterer Perspektiven
3 Organizational Mining
3.1 Soziales Netzwerk
3.2 Organisatorisches Modell
4 Decision Mining
4.1 Voraussetzungen
4.2 Identifizierung von Entscheidungspunkten
4.3 Ableiten von Entscheidungsregeln
5 Zeiten und Wahrscheinlichkeiten
6 Zusammenfassung
Literaturverzeichnis
Abstract: Die Grundidee des Process Mining besteht in der Erkennung von Prozessen, d.h. der Konstruktion von Prozessmodellen aus einer Ereignis-Logdatei. Das Process Mining unterscheidet dabei zwischen verschiedenen Perspektiven, die jeweils unterschiedliche Sichten auf ein Prozessmodell gestatten. Neben der Kontrollflussperspektive, welche die Abfolge von Aktivitäten in einem Prozess darstellt, lassen sich drei weitere Perspektiven unterscheiden. Die organisatorische Perspektive dient der Analyse sozialer Netzwerke sowie der allgemeinen Organisationsstruktur im Unternehmen. Die Fallperspektive analysiert die Entscheidungsfindung von Prozessen und dient dem Unternehmen zum besseren Verständnis von Entscheidungsprozessen. Die Zeitperspektive dient der Identifizierung von Engpässen und Performanceproblemen innerhalb eines Prozesses. Darüber hinaus können die verschiedenen Perspektiven in einem einzigen Modell zusammengeführt werden um eine integrierte Sicht zu erhalten. In dieser Seminararbeit werden die weiteren Perspektiven zusammenfassend beschrieben und anhand von Beispielen aufgearbeitet.
1 Einleitung
Das grundlegende Ziel des Process Mining besteht darin, Informationen betrieblicher Prozesse aus einer Ereignis-Logdatei zu extrahieren, welche zuvor in einem Informationssystem aufbereitet worden sind [AE11]. Die gesammelten Informationen werden schließlich zu einem Prozessmodell aufbereitet, welches den gesamten Prozess in einer bestimmten Perspektive und Notationsform, wie z.B. Petri-Netze, abbildet. Insgesamt lassen sich drei Arten des Process Mining unterscheiden. Die erste und bekannteste Art ist das Process Discovery. Beim Process Discovery wird anhand einer Ereignis-Logdatei ein Prozessmodell erzeugt ohne dafür weitere Informationen zu benötigen. Die zweite Art ist das Conformance Checking. Bei dieser Art wird ein bereits bestehendes Prozessmodell mit einer Ereignis-Logdatei auf Übereinstimmungen verglichen. Das Ergebnis umfasst bei dieser Art diagnostische Informationen welche die Konformität beider Eingabeparameter wiederspiegelt. Die letzte und dritte Art ist das Enhancement bzw. die Erweiterung. Auch bei dieser Art dienen Prozessmodell und Ereignis-Logdatei als Eingabeparameter. Im Unterschied zum Conformance Checking wird bei dieser Art nicht nur die Konformität überprüft, sondern auch Anpassungen und Erweiterungen am Modell vorgenommen, sodass im Idealfall ein besseres Modell entsteht [AE11].
Standardmäßig geben Prozessmodelle nur die Abfolge von Aktivitäten wieder und machen keinerlei Aussagen über organisatorische Strukturen, Fallentscheidungen oder den zeitlichen Ablauf von Prozessen. Somit lassen sich nur schwer Aussagen über einen Prozess vornehmen. Für andere Sichten auf ein Prozessmodell werden im Process Mining verschiedene Perspektiven unterschieden. Folglich kann jedem Prozessmodell eine bestimmte Perspektive zugeordnet werden. Standardmäßig liegt hier der Schwerpunkt auf der Kontrollflussperspektive. Diese Perspektive betrachtet die Abfolge von Aktivitäten in einem Prozess mit dem Ziel, eine visuelle Beschreibung jeglicher Ausführungspfade zu finden [AE11]. Für diese Perspektive genügen sogenannte einfache Ereignis-Logdateien mit nur wenigen Attributen, die keine erweiterten Informationen über einen Prozess enthalten. Jedoch ist das Process Mining nicht auf die Kontrollflussperspektive begrenzt. Ereignis-Logdateien können eine Menge mehr an Informationen enthalten die für eine umfassende Analyse und Visualisierung der Modelle genutzt werden können [Aa11]. Deshalb richtet sich die Aufmerksamkeit in dieser Seminararbeit auf die weiteren Perspektiven.
Im folgenden zweiten Abschnitt wird ein Überblick über die Attribute gegeben, die für die weiteren Perspektiven erforderlich sind. Anhand eines Ausschnitts einer Ereignis-Logdatei werden die einzelnen Perspektiven in den jeweiligen Abschnitten aufgearbeitet. Neben der Organisatorischen Perspektive in Abschnitt drei, werden auch die Fallperspektive in Abschnitt vier sowie die Zeitperspektive in Abschnitt fünf behandelt. Abschließend wird eine Zusammenfassung in Abschnitt sechs vorgenommen.
2 Ereignislog weiterer Perspektiven
Bevor die einzelnen Perspektiven des Process Mining näher betrachtet werden, soll in diesem Abschnitt gezeigt werden, welche Arten von Informationen in einer typischen Ereignis-Logdatei vorhanden sein können. Tabelle 1 zeigt einen kleinen Ausschnitt einer größeren Ereignis-Logdatei. Die Logdatei ist in Cases und Events unterteilt, wobei ein Case aus mehreren Events bestehen kann und ein Event zu genau einem Case gehört. Des Weiteren werden zu jedem Event Eigenschaften gespeichert. Diese bestehen in der Tabelle 1 aus einem Zeitstempel, einer Aktivität, einem Transaktionstypen sowie einer Ressource.
Im Vergleich zu einfach gehalten Ereignis-Logdateien enthält dieser Log unter anderem Transaktionstypen. Anhand der Transaktionstypen wird in diesem Beispiel festgehalten ob ein Event gestartet oder beendet wurde. Natürlich kann es noch mehr Transaktionstypen geben, jedoch werden in dieser Arbeit nur die genannten Typen verwendet. Wenn wir zum Beispiel die ersten beiden Events in Tabelle 1 betrachten erkennen wir, dass sich das erste Event auf den Beginn einer Aktivität bezieht, während sich das zweite Event auf die Vollendung dieser Aktivität bezieht. Indem man nun die Differenz zwischen den Zeitstempeln beider Events berechnet, kann daraus abgeleitet werden, dass die Ressource „Ralf“ 18 Minuten für Aktivität A (Kreditanfrage aufnehmen) benötigt.
Abbildung in dieser Leseprobe nicht enthalten
Tabelle 1 - Ausschnitt einer Ereignis-Logdatei
Des Weiteren gibt es zum Ereignislog aus Tabelle 1 noch weitere Fallattribute, die zu jedem Case separat gespeichert werden. Eine Auflistung dieser Fallattribute wird im entsprechenden Abschnitt vier (Decision Mining) vorgenommen. Darüber hinaus ist in dieser Ereignis-Logdatei jeder Aktivität eine Ressource zugeordnet. Die Angabe von Ressourcen dient im dritten Abschnitt (Organizational Mining) für die Analyse von organisatorischen Strukturen im jeweiligen Prozess.
Die folgende Abbildung 1 zeigt das entsprechende Prozessmodell, welches aus der Ereignis-Logdatei (Tabelle 1) in der Kontrollflussperspektive generiert worden ist. Dieses Modell enthält noch keinerlei Informationen bezüglich weiterer Perspektiven und soll dabei helfen einen Überblick über den Prozess zu bekommen.
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 1 - Prozessmodell Kreditanfrage
3 Organizational Mining
Das Organizational Mining konzentriert sich auf die organisatorische Perspektive. Ausgangspunkt für das Organizational Mining ist typischerweise das Ressourcen-Attribut in der Ereignis-Logdatei [Aa11]. Eine Ressource kann unter anderem ein Mitarbeiter sein der eine bestimmte Aktivität ausführt. Allerding können Ressourcen auch Gruppierungen von Mitarbeitern sein, welche in bestimmten Rollen zusammengefasst werden wie z.B. die Rolle Manager oder Sachbearbeiter. Mit Hilfe dieser Informationen lassen sich nun Analysen durchführen, mit dem ein Überblick über die organisatorische Struktur der Prozesse gegeben wird. Innerhalb des Process Discovery, welches das Ziel hat aus einer gegebenen Ereignis-Logdatei ein Prozessmodell zu erstellen, sind im Organizational Mining zwei Arten von Modellen relevant. Das ist zum einen das Organisatorische Modell welches die aktuelle Organisationsstruktur des Unternehmens darstellt und zum anderen das soziale Netzwerk welches die Kommunikationsstruktur des Unternehmens wiederspiegelt [SA08]. Beide Modelle werden in diesem Abschnitt kurz erläutert.
Bevor die beiden Modelle näher betrachtet werden, soll im Folgenden eine kurze Analyse der Ereignis-Logdatei aus Tabelle 1 vorgenommen werden um einen Einblick in den organisatorischen Strukturen zu bekommen. Durch die Analyse und Aufbereitung von organisatorischen Strukturen aus der Ereignis-Logdatei (Tabelle 1) ist es möglich die Beziehungen zwischen den Ressourcen und Aktivitäten zu analysieren. Tabelle 2 zeigt ein Beispiel einer kompakten Darstellung einer Ereignis-Logdatei indem die Ressourcen jeder Aktivität hervorgehoben worden sind.
Abbildung in dieser Leseprobe nicht enthalten
Tabelle 2 - Ausschnitt einer Ereignis-Logdatei (Hervorhebung von Ressourcen)
Anhand dieser Tabelle lässt sich jetzt eine Ressourcen-Aktivitäten-Matrix erstellen, die in Tabelle 3 dargestellt wird. Eine Ressourcen-Aktivitäten-Matrix ist eine Tabelle, die die Ausführung einer Aktivität je Ressource pro Fall anzeigt. Dabei ist zu beachten, dass es sich bei den Werten in der Tabelle 3 um Durchschnittswerte handelt.
Abbildung in dieser Leseprobe nicht enthalten
Tabelle 3 - Ressourcen-Aktivitäts-Matrix
An dieser Matrix lässt sich jetzt erkennen, dass die Aktivitäten A, B und E genau einmal pro Fall ausgeführt werden. Die Aktivitäten C und D werden im Durchschnitt nur 0,5-mal ausgeführt. Der Grund hierfür liegt in der Aufsplittung des Prozesses nach Aktivität B. Des Weiteren wird Aktivität B nur von Hermann ausgeführt. Ralf, Klaus und Peter teilen sich die Ausführung von Aktivität A. In 25% der Fälle wird Aktivität A von Ralf ausgeführt, 50% von Klaus und weitere 25% der Fälle werden von Peter ausgeführt. Je nach Komplexität des Prozessmodells kann eine Aktivität auch öfters als einmal ausgeführt werden indem z.B. Rücksprunge zu früheren Aktivitäten stattfinden.
3.1 Soziales Netzwerk
Ein soziales Netzwerk ist ein Netzwerk bestehend aus Knoten, Kanten und Gewichten. Die Knoten entsprechen dabei organisatorische Einheiten. Dieses können z.B. einzelne Personen aber auch Gruppierungen von Mitarbeitern sein, die in einer bestimmten Rolle zusammengefasst worden sind. Die Kanten in einem sozialen Netzwerk entsprechen Beziehungen zwischen den organisatorischen Einheiten. Des Weiteren können Kanten und Knoten Gewichte haben, die ihre Bedeutung wiederspiegeln. Die Grundlage zur Erstellung sozialer Netzwerke sind Ereignis-Logdateien. Die erstellten Netzwerke zeigen dem Unternehmen auf, wie Mitarbeiter oder Gruppen von Mitarbeitern untereinander arbeiten. Mit sogenannten Social-Network-Analysis-Techniken, die hier aus Gründen des Umfangs nicht weiter betrachtet werden, lassen sich diese Netzwerke schließlich analysieren [Aa11].
Um ein soziales Netzwerk aus einer Ereignis-Logdatei zu erstellen gibt es verschiedene Verfahren. Ein typisches Beispiel für ein solches Verfahren ist die Handover-of-Work Metrik. Falls in einem Fall zwei aufeinanderfolgende Aktivitäten auftreten und die erste Aktivität von Teilnehmer i und die zweite Aktivität von Teilnehmer j ausgeführt worden ist, kann davon ausgegangen werden das eine Übergabe von Arbeit (Handover-of-Work) von Teilnehmer i zu Teilnehmer j erfolgt ist [Aa11]. Durch diese Information lässt sich jetzt eine Verbindung von Knoten i zu Knoten j zum Netzwerk hinzufügen. Je häufiger diese Übergabe stattfindet, desto größer ist das Gewicht zwischen diesen Knoten. Ein Bespiel für eine vereinfachte Handover-of-Work-Matrix auf Grundlage von der Ereignis-Logdatei aus Tabelle 2 zeigt Tabelle 4 auf. Eine Handover-of-Work-Matrix stellt eine Tabelle dar, die für jede Ressource anzeigt, wie oft eine Übergabe von Arbeit pro Fall zu einer anderen Ressource stattgefunden hat. Auch bei dieser Tabelle ist zu beachten, dass es sich hierbei um Durchschnittswerte handelt.
Abbildung in dieser Leseprobe nicht enthalten
Tabelle 4 - Handover of Work
Jeder Wert in Tabelle 4 der größer Null ist stellt also eine Übergabe von Arbeit zwischen zwei Ressourcen dar. So lässt sich z.B. erkennen, dass Ralf, Klaus und Peter an Hermann Arbeit übergeben. Hermann wiederum übergibt 0,5 mal pro Fall an Monika und Maria Arbeit.
Da ein soziales Netzwerk bei vielen Mitarbeitern sehr unübersichtlich aussehen würde, werden die Ressourcen in den drei Rollen Assistent, Manager und Sachbearbeiter zusammengefasst. Dabei nehmen Ralf, Klaus und Peter die Rolle des Assistenten, Monika und Maria die Rolle des Sachbearbeiters und Hermann die Rolle des Managers ein. Tabelle 5 zeigt die rollenbasierte Ansicht der Handover-of-Work-Matrix.
Abbildung in dieser Leseprobe nicht enthalten
Tabelle 5 - Handover of Work (Rollenbasiert)
Auf Basis dieser Matrix lässt sich jetzt ein übersichtliches soziales Netzwerk erstellen welches in Abbildung 3 dargestellt wird. Das Gewicht des Assistent-Knoten beträgt zwei, da die Ressource Assistent insgesamt zweimal pro Fall eine Aktivität ausführt. Die Gewichte der Kanten ergeben sich aus der Handover-of-Work-Matrix und geben an, wie oft eine Übergabe von Arbeit pro Fall von einer Ressource zur Anderen erfolgt ist.
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 2 - Soziales Netzwerk
Anhand eines sozialen Netzwerks und der Handover-of-Work-Matrix lassen sich schließlich Analysen durchführen. Zum Beispiel lässt sich an einem sozialen Netzwerk schnell erkennen wie stark Ressourcen miteinander zusammenarbeiten oder welche Ressource die meisten Aktivitäten pro Fall ausführt.
3.2 Organisatorisches Modell
Das organisatorische Modell repräsentiert die organisatorische Struktur eines Unternehmens. Es besteht gewöhnlich aus organisatorisches Einheiten, Rollen, Teilnehmer und Beziehungen [Aa11]. Abbildung 3 zeigt ein organisatorisches Modell basierend auf dem Prozessmodell aus Abbildung 1. An dem Modell lässt sich erkennen, welche Rollen bestimmten Aktivitäten zugeordnet sind und welche Mitarbeiter zu einer bestimmten Rolle gehören. An dem Modell lassen sich die organisatorischen Strukturen von Prozessen ablesen.
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 3 - Organisatorisches Modell
Für das Mining solcher Modelle aus einer Ereignis-Logdatei werden zwei Arten organisatorischer Einheiten benötigt. Aufgabenbezogene und fallbezogene Gruppen. Eine aufgabenbezogene Gruppe enthält Teilnehmer welche dazu autorisiert sind gleiche Aufgaben durchzuführen. Eine fallbasierte Gruppe enthält Mitarbeiter welche im selben Fall involviert sind [SA08]. Um diese Informationen aus einer Ereignis-Logdatei zu extrahieren kommen verschiedene Mining-Techniken zum Einsatz, die aus Gründen des Umfangs in dieser Seminararbeit nicht weiter betrachtet werden. Eine beispielhafte Darstellung dieser extrahierten Daten stellt z.B. Tabelle 3 mit der Ressourcen-Aktivitäts-Matrix dar. Anhand dieser Matrix lässt sich unter anderem erkennen welche Ressourcen die gleichen Aktivitäten durchführen und welche Ressourcen zusammen an einem Fall arbeiten. Aus diesen Daten lässt sich schließlich das Organisatorische Modell ableiten. Die Darstellung von aufgabenbezogenen Gruppen kann z.B. dabei helfen funktionale Abteilungen zu bilden in denen Mitarbeiter die gleichen Fähigkeiten besitzen. Beispiel hierfür sind Abteilungen wie z.B. Finanz- oder Produktionsabteilung. Die fallbezogenen Gruppen ähneln Projektteams in denen die Mitarbeiter unterschiedliche Fähigkeiten besitzen und zusammen an einem Fall arbeiten. Die Identifizierung fallbasierter Gruppen dient unter anderem zum Verständnis organisatorischer Strukturen [SA08].
4 Decision Mining
Beim Decision Mining handelt es sich um ein Verfahren welches sich auf die Fallperspektive konzentriert. Dabei wird jeder Fall durch seine Fallattribute, den zeitlichen Ablauf und den gewählten Pfad durch den Prozess charakterisiert [Aa11]. Das Ziel des Decision Mining besteht darin, die Daten eines bestehenden Prozessmodells zu betrachten und daraus zu schlussfolgern, welche dieser Daten den Prozess beeinflussen. Durch diese Informationen lassen sich schließlich Entscheidungsregeln ableiten, welche die Entscheidungsfindung in Prozessen unterstützen. Das Decision Mining stellt also ein Verfahren dar, welches eine Erweiterung eines bestehenden Prozessmodells anstrebt, indem es die Falldaten einer Ereignis-Logdatei analysiert und Entscheidungsregeln als Ergebnis liefert [RA06]. An dem Prozessmodell aus Abbildung 1 soll das Ziel des Decision Mining im Folgenden kurz erläutert werden:
Das Prozessmodell aus Abbildung 1 beschreibt den vereinfachten Ablauf einer Kreditanfrage. Bei einer Bank haben die Kunden die Möglichkeit eine Kreditanfrage zu stellen. Diese Kreditanfrage wird von einem Assistenten aufgenommen und schließlich an dem Manager weitergeleitet. Der Manager überprüft schließlich die Eigenschaften der Kreditanfrage wie z.B. den gewünschten Betrag und um welche Kundenart (Premiumkunde, Normalkunde) es sich handelt. Je nach Kundenart und Höhe des gewünschten Betrags entscheidet sich der Manager schließlich ob der Kredit genehmigt oder abgelehnt wird. Der Ausgang dieser Überprüfung hat somit einen unmittelbaren Einfluss auf die Fortsetzung des Prozesses. Durch die Analyse vergangener Prozesse kann schließlich ermittelt werden, welche Fallattribute dazu beigetragen haben, dass eine Kreditanfrage genehmigt oder abgelehnt worden ist. Die Erkennung und Darstellung dieser Einflussgrößen gehört zum Zielgebiet des Decision Mining und soll im Folgenden kurz erläutert werden.
4.1 Voraussetzungen
Um das Decision Mining durchführen zu können sind einige Voraussetzungen zu erfüllen. Wie bereits erwähnt strebt das Decision Mining eine Erweiterung eines bestehenden Prozessmodells an. Voraussetzung ist somit ein bestehendes Prozessmodell, welches im Rahmen des Process Discovery erzeugt worden ist. Als Beispiel soll hier das Prozessmodell aus Abbildung 1 (Kreditanfrage) dienen. Darüber hinaus sind zu jedem Fall Informationen erforderlich, welche zur Entscheidungsfindung beitragen. Die Voraussetzung an der Ereignis-Logdatei ist somit die Protokollierung aller Daten die zur Entscheidungsfindung beitragen. Die Tabelle 6 (Fallattribute) zeigt einen kurzen Ausschnitt solcher Fallattribute und soll in diesem Abschnitt als Beispiel dienen. Die Einträge dieser Tabelle stellen eine Verknüpfung zur Ereignis-Logdatei aus Tabelle 1 dar. Beispiel: Case 1 ist eine Anfrage die durch den Kunden Müller mit der Kundennummer 4456 ausgelöst worden ist. Kunde Müller ist ein Premiumkunde. Der Betrag seiner Kreditanfrage beträgt 2500 €. Der Status dieser Kreditanfrage ist genehmigt. Dieser Eintrag (Case 1) ist mit dem entsprechenden Eintrag (Case 1) in der Tabelle 1 verknüpft und erweitert somit die Ereignis-Logdatei aus Tabelle 1.
Abbildung in dieser Leseprobe nicht enthalten
Tabelle 6 - Fallattribute
Falls die Voraussetzungen erfüllt worden sind, kann mit dem Verfahren begonnen werden. Das Decision Mining erfolgt dabei in zwei Schritten. Zuerst müssen die Entscheidungspunkte in einem Prozessmodell identifiziert werden, die den Prozess in unterschiedliche Pfade aufteilen. Anschließend werden für jeden Entscheidungspunkt Regeln abgeleitet die festhalten, welche Daten dazu führen, dass ein bestimmter Prozesspfad eingeschlagen wird.
4.2 Identifizierung von Entscheidungspunkten
Wird ein Prozessmodell in Form eines Petri-Netzes dargestellt, ist ein Entscheidungspunkt eine Stelle in diesem Petri-Netz, von der mehrere Pfeile zu Transitionen ausgehen [RA06]. Abbildung 4 verdeutlicht diesen Zusammenhang. In diesem Beispiel gehen von der Stelle „p2“ zwei Pfeile in Richtung einer Transition aus. Ein Pfeil geht Richtung Transition C und der andere Pfeil geht in Richtung Transition D.
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 4 – Entscheidungspunkt im Prozessmodell
Zur Identifizierung solcher Entscheidungspunkte muss die Ereignis-Logdatei bezüglich der gewählten Pfade im Prozess analysiert werden. Wird festgestellt, dass einer Stelle mehr als einer Transition folgt, kann daraus geschlossen werden, dass sich an dieser Stelle ein Entscheidungspunkt befindet.
4.3 Ableiten von Entscheidungsregeln
Nachdem die Entscheidungspunkte im Prozessmodell identifiziert worden sind, soll jetzt ermittelt werden, welche Daten in der Ereignis-Logdatei die Entscheidungen beeinflussen. Aus diesen Daten werden schließlich Entscheidungsregeln abgeleitet. Die Ermittlung und Ableitung dieser Daten wird im Folgenden kurz erläutert.
Zuerst wird jede Entscheidungsalternative in ein Klassifikationsproblem konvertiert. Die Klassen stellen dabei die Entscheidungen dar die getroffen werden können. Anschließend wird für jede Prozessinstanz der gewählt Pfad durch das Prozessmodell ermittelt. Die erste Aktivität die nach dem Entscheidungspunkt durchlaufen wird, zeigt die Entscheidung an, die getroffen worden ist. Alle Daten die bis zu diesem Zeitpunkt aufgezeichnet worden sind, werden der jeweiligen Klasse zugeordnet. Jeder Klasse werden somit die Datenausprägungen zugeordnet, die für die jeweilige Entscheidung aufgezeichnet worden sind.
Anschließend werden auf den klassierten Daten Verfahren angewendet, die schließlich eine Entscheidungsregel als Ergebnis liefern [RA06]. Ein mögliches Verfahren wäre der Einsatz von Algorithmen zu Erstellung von Entscheidungsbäumen. Abbildung 5 zeigt einen solchen Entscheidungsbaum für den Entscheidungspunkt p2 aus Abbildung 4.
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 5 – Entscheidungsbaum
Der Entscheidungsbaum wurde auf Basis der Ereignis-Logdatei aus Tabelle 6 erstellt. An diesem Baum lassen sich jetzt die Entscheidungsregeln ablesen. Falls es sich beim Prozess der Kreditanfrage um einen Premiumkunden handelt wird mit Aktivität C (Kredit auszahlen) fortgesetzt. Handelt es sich um einen Normalkunden wird zusätzlich der gewünschte Betrag untersucht. Bei einem Betrag kleiner gleich 500 Euro wird der Kredit für einen Normalkunden genehmigt und mit Aktivität C fortgesetzt. Falls es sich um einen Normalkunden handelt mit einem Betrag größer 500 Euro wird mit Aktivität D fortgesetzt (Absage erteilen).
5 Zeiten und Wahrscheinlichkeiten
Der Abschnitt Zeiten und Wahrscheinlichkeiten beschäftigt sich mit der zeitlichen Perspektive und den zeitlichen Wahrscheinlichkeiten bestimmter Aktivitäten. In den meisten Ereignis-Logdateien sind Ereignisse mit Zeitstempel versehen. Die Granularität dieser Zeitstempel können allerdings stark variieren. In manchen Ereignis-Logdateien sind nur Datumsinformationen gegeben und in anderen wiederrum Zeitstempel mit Millisekunden-Präzision. Durch Zeitstempel in Ereignis-Logdateien wird es ermöglicht Engpässe in einem Prozess zu entdecken, die Ressourcennutzung zu überwachen und Vorhersagen der verbleibenden Arbeitszeit in laufenden Prozessen durchzuführen [Aa11]. Das folgende Beispiel soll kurz den Ansatz der Zeitperspektive erläutern.
Tabelle 7 zeigt einen Ausschnitt einer Ereignis-Logdatei in der die Zeitstempel hervorgehoben sind. Um die Darstellung zu vereinfachen werden in dieser Tabelle fiktive zweistellige Zeitstempel verwendet. Darüber hinaus wird davon ausgegangen das jedes Ereignis einen Start- und Endzeitpunkt besitzt. Ein Beispiel: Im Case 1 dauert die Aktivität A von Zeiteinheit 9 bis Zeiteinheit 14. Somit hat die Aktivität A insgesamt 5 Zeiteinheiten in Anspruch genommen. Die zweite Aktivität B startet bei Zeiteinheit 16. Somit liegen 2 Zeiteinheiten zwischen dem Ende von Aktivität A und dem Start von Aktivität B. Anhand dieser Ereignis-Logdatei kann jetzt abgelesen werden wie lange die einzeln Aktivitäten dauern und wie viel Zeiteinheiten zwischen den Aktivitäten liegen.
Abbildung in dieser Leseprobe nicht enthalten
Tabelle 7-Ausschnitt einer Ereignis-Logdatei (Hervorhebung von Zeiten)
Abbildung 6 zeigt das entsprechende Prozessmodell inklusiv der Zeiten der einzelnen Aktivitäten sowie den Wartezeiten der einzelnen Stellen nach Durchlauf der drei Traces aus Tabelle 7. Aktivität A besitzt z.B. drei Aktivitätsinstanzen, eine für jeden Fall. Die dritte Instanz von Aktivität A geht von Zeiteinheit 25 bis Zeiteinheit 40 und hat somit eine Dauer von 15 Zeiteinheiten. Das S in der Abbildung bedeutet Start und das E bedeutet Ende. Die Zahl auf den Pfeil beschreibt die Dauer der Aktivität. Auch die Stellen im Petri-Netz werden durch Wartezeiten beschrieben. Zum Beispiel gab es drei Zeiträume in denen die Stelle p1 besetzt war. Im Case 1 und 2 war Stelle p1 für 2 Zeiteinheiten besetzt und im Case 3 für 5 Zeiteinheiten. Die Verweildauern in den Stellen ergeben sich jeweils aus den Zeiträumen zwischen dem Ende einer Aktivität und dem Start der nächsten Aktivität. Für jede Transition und Stelle im Petri-Netz kann schließlich ein Set von Daten mit den jeweiligen Verweildauern abgeleitet werden.
Abbildung in dieser Leseprobe nicht enthalten
Abbildung 6 - Zeiten im Prozessmodell
Für größere Ereignis-Logdateien bestehen diese Datensets aus tausenden Elementen. Daher ist es möglich auf diesen Datensets Statistikmethoden anzuwenden und so Informationen wie z.B. Minimum, Maximum, Mittelwert oder Standardabweichung der jeweiligen Daten zu erhalten. Aus diesen Informationen lassen sich z.B. Wartezeiten für einzelne Aktivitäten ablesen. Des Weiteren ist es möglich Konfidenzintervalle zu berechnen und so Aussagen über bestimmte Aktivitäten zu machen. Ein Beispiel: „Das 90% Konfidenzintervall für die mittlere Wartezeit für Aktivität X beträgt zwischen 40 und 50 Minuten [Aa11].“ Darüber hinaus lassen sich mittlere Durchlaufzeiten für einen Prozess berechnen. Daraus lässt sich unter anderem erkennen ob eine Prozessinstanz von einer zeitlichen Norm abweicht. Des Weiteren können Datensets dazu benutzt werden Routing-Wahrscheinlichkeiten im Prozessmodell aufzuzeigen. Zum Beispiel gibt es nach Aktivität B die Auswahl für Aktivität C oder D. Durch die Analyse von Frequenzen kann gezeigt werden, dass z.B. in 80% der Fälle Aktivität C und in 20% der Fälle Aktivität D eintritt. Die grafische Visualisierung der Zeitperspektive innerhalb eines Prozessmodells dient dazu Performanceinformationen übersichtlich zur Verfügung zu stellen [Aa11]. So lassen sich z.B. Stellen hervorheben an denen eine überdurchschnittlich Wartezeit besteht oder Aktivitäten bei denen eine hohe Variation an Servicezeiten auftaucht.
6 Zusammenfassung
In dieser Seminararbeit wurden verschiedene Perspektiven des Process Mining betrachtet. Es wurde gezeigt, dass ein Prozessmodell um verschiedene Perspektiven erweitert werden kann, umso eine integrierte Sicht zu erhalten. Durch diese Sicht werden alle wesentlichen Aspekte hervorgehoben, die benötigt werden, um einen Prozess in seinem vollen Umfang nachvollziehen zu können.
Zum einen wurde die organisatorische Perspektive betrachtet und die Aspekte des organisatorischen Modells sowie des sozialen Netzwerks hervorgehoben. Diese Perspektive dient der Darstellung organisatorischer Strukturen im Unternehmen sowie der Interaktionen von Ressourcen untereinander. Des Weiteren wurde die Fallperspektive betrachtet, mit dem Ziel, herauszufinden welche Daten einer Ereignis-Logdatei einen Prozess beeinflussen. Neben den Voraussetzungen des Decision Mining wurden hier die Identifizierung von Entscheidungspunkten sowie das Ableiten von Entscheidungsregeln dargestellt. Abschließend wurde die Zeitperspektive betrachtet die dabei hilft Engpässe in Prozessen zu ermitteln sowie die Dauer von Prozessaktivitäten oder Wartezeiten vorherzusagen. Durch die Zusammenfassung aller Perspektiven in einem Modell ergibt sich schließlich eine integrierte Ansicht auf den Prozess.
Die behandelten Perspektiven geben einen großen Einblick in den Ablauf und der Struktur von Prozessen. Das Process Mining ist allerdings nicht auf diese Perspektiven begrenzt. So lassen sich weitere Perspektiven wie z.B. Risiken oder Kosten unterscheiden, die in dieser Seminararbeit nicht behandelt worden sind.
Literaturverzeichnis
[Aa11] W. M. P. van der Aalst. Process Mining: Discovery, Conformance and Enhancement of Business Processes. Springer, Berlin, 2011.
[AE11] W. van der Aalst et al., “Process Mining Manifesto,” Business Process Management Workshops, LNBIP 99, F. Daniel, K. Barkaoui and S. Dustdar, eds., Springer-Verlag, 2011.
[RA06] A. Rozinat and W.M.P. van der Aalst. Decision Mining in Business Processes. BPM Center Report BPM-06-10, BPMcenter.org, 2006.
[SA08] M. Song and W.M.P. van der Aalst. Towards Comprehensive Support for Organizational
Mining. Decision Support Systems, 46(1):300–317, 2008.
- Quote paper
- Bernhard Bruns (Author), 2013, Weitere Process Mining Perspektiven, Munich, GRIN Verlag, https://www.grin.com/document/421628
-
-
-
-
Upload your own papers! Earn money and win an iPhone X. -
-
Upload your own papers! Earn money and win an iPhone X. -
-
Upload your own papers! Earn money and win an iPhone X. -
-
Upload your own papers! Earn money and win an iPhone X. -
-
Upload your own papers! Earn money and win an iPhone X. -
-
Upload your own papers! Earn money and win an iPhone X. -
-
Upload your own papers! Earn money and win an iPhone X. -
-
Upload your own papers! Earn money and win an iPhone X. -
-
Upload your own papers! Earn money and win an iPhone X. -
-
Upload your own papers! Earn money and win an iPhone X. -
-
Upload your own papers! Earn money and win an iPhone X. -
-
Upload your own papers! Earn money and win an iPhone X. -
-
Upload your own papers! Earn money and win an iPhone X. -
-
Upload your own papers! Earn money and win an iPhone X.