PROCESS MINING FÜR RFID GESTÜTZTE LOGISTISCHE LIEFERKETTEN

Transkript

1 Fakultät Informatik, Institut für Systemarchitektur, Professur für Rechnernetze Diplomarbeit PROCESS MINING FÜR RFID GESTÜTZTE LOGISTISCHE LIEFERKETTEN Alexander Claus Mat.-Nr.: Verantwortlicher Hochschullehrer: Prof. Dr. rer. nat. habil. Dr. h. c. Alexander Schill Betreuer (TU Dresden): Dr.-Ing. Eberhard Grummt Betreuer (SAP Research): Dipl.-Betriebsw. Kerstin Gerke Eingereicht am 17. Dezember 2009

2

3 Fakultät Informatik, Institut für Systemarchitektur, Professur für Rechnernetze Aufgabenstellung für die Diplomarbeit Name des Studenten: Alexander Claus Studiengang: Informatik Matrikelnummer: Thema: Process Mining für RFID-gestützte logistische Lieferketten. Zielstellung: Techniken aus dem Gebiet Process Mining dienen dazu, Prozesswissen aus Daten automatisch zu extrahieren. So kann zum Beispiel aus Ereignislogs, die von einem Geschäftsprozess generiert werden, das Prozessmodell rekonstruiert werden. In logistischen Lieferketten werden Auto-ID-Technologien wie RFID benutzt, um Waren zu identifizieren und zu beobachten. Dabei werden elektronische Produktcodes (EPCs) verwendet, die von entsprechenden RFID-Lesegeräten gelesen werden. Jede Beobachtung eines solchen EPC wird in einem Ereignis festgehalten, wobei Daten wie Zeitpunkt, Ort und Geschäftskontext erfasst werden. Diese Ereignisse können als Ansatzpunkt für Process Mining verwendet werden. Allerdings ist es dazu notwendig, dass Ereignisse in Fällen organisiert werden, wobei ein Fall eine Sequenz von Aktivitäten beschreibt, die einem Prozess entstammen. In logistischen Prozessen wie Produktionsprozessen ist eine solche Zuordnung zu Fällen jedoch schwierig unter anderem aufgrund verschiedener Aggregationsschritte in solchen Prozessen. Ziel dieser Arbeit soll sein, zu untersuchen wie Process-Mining-Techniken genutzt werden können, um Lieferketten-Prozesse zu rekonstruieren und zu analysieren. Es sind Anforderungen an Process-Mining abzuleiten, die die Besonderheiten von Lieferketten-Prozessen berücksichtigen, sowie eine Lösung zu entwerfen und prototypisch zu implementieren, die die Anforderungen erfüllt. Schwerpunkte: Anforderungen an Process Mining bezüglich Lieferketten identifizieren Evaluierung existierender Ansätze zum Process Mining bezüglich ihrer Eignung für Lieferketten Entwurf und Prototypische Implementierung einer Process Mining-Lösung Bewertung der Lösung Betreuer (SAP): Dipl.-Betriebsw. Kerstin Gerke Betreuer (TU Dresden): Dipl.-Medieninf. Eberhard Grummt Verantwortlicher Hochschullehrer: Prof. Dr. rer. nat. habil. Dr. h. c. Alexander Schill Institut: Institut für Systemarchitektur Lehrstuhl: Rechnernetze Beginn der Bearbeitung: Einzureichen bis: Unterschrift des verantwortlichen Hochschullehrers 1

4

5 ERKLÄRUNG Ich erkläre, dass ich die vorliegende Arbeit selbständig, unter Angabe aller Zitate und nur unter Verwendung der angegebenen Literatur und Hilfsmittel angefertigt habe. Dresden, 17. Dezember 2009

6

7 DANKSAGUNG Eine Arbeit wie die vorliegende entsteht nicht von allein. Das Gelingen hängt auch von beruflicher wie privater Unterstützung ab, für die ich mich an dieser Stelle bedanken möchte. Ich danke Prof. Dr. rer. nat. habil. Dr. h. c. Alexander Schill, Dr.-Ing. Eberhard Grummt sowie Dipl.-Betriebsw. Kerstin Gerke für die Betreuung meiner Arbeit. Kerstins Beitrag dabei in einen kurzen Satz zu fassen, ist nahezu unmöglich. Sie hat mich fachlich unterstützt und unermüdlich dazu gebracht, diese Arbeit zu vervollkommnen; gleichzeitig konnte sie mich stets motivieren. Ich danke ihr dafür. Mein Dank gilt weiterhin Konstantin Tarmyshov, welcher mir benötigte Ressourcen zur Verfügung stellte. Ich danke meinem Kollegen und Freund Christian Bernardt für die anregenden Diskussionen. Zum Schluss möchte ich betonen, dass ich tief in der Schuld meiner Frau Susann und meiner Kinder Antonia, Joseph und Marie stehe, die einige Opfer bringen mussten, mir dafür aber permanent Ablenkung und Rückhalt gegeben haben.

8 6

9 INHALTSVERZEICHNIS 1 Einleitung Motivation Zielstellung Aufbau der Arbeit Hintergrund und verwandte Arbeiten Anwendungsdomäne Lieferketten Produktflüsse Produktidentifikation Standardisierung Process Mining Anwendung auf Aufgabenstellung Protokollformat Process Mining Implementierungen Prozessmodellierung Prozessketteninstrumentarium Business Process Modeling Notation

10 2.3.3 Ereignisgesteuerte Prozessketten Petri Netze Verwandte Ansätze Anforderungen Anforderungen an die Datenaufbereitung Anforderungen an die Prozessmodellierung Anforderungen an den Process Mining Algorithmus Lösungsentwurf Softwareauswahl Konvertierung der Ereignisse Ereignisattribute Zuordnung zu Prozessinstanzen MXML Generierung Diskussion Prozessmodellierung Darstellung der Elemente der Lieferkette Darstellung der Produktflüsse Darstellung der Unternehmenshierarchie Einbindung der Ereignisse Process Mining Algorithmus Erste Phase Zweite Phase Diskussion

11 5 Implementierung Konvertierung der Ereignisse Prozessmodellierung Process Mining Algorithmus Bewertung Validierung durch Simulationsmodell Konvertierung Bewertung der Konvertierungsergebnisse Process Mining Bewertung der Process Mining Ergebnisse Validierung durch Reales Modell Konvertierung des Datensatzes Bewertung der Konvertierungsergebnisse Process Mining Bewertung der Process Mining Ergebnisse Fazit Erfüllung der Anforderungen Konvertierung Prozessmodellierung Process Mining Algorithmus Zusammenfassung und Ausblick Zusammenfassung Ausblick A Hinweise zum beiliegenden Prototyp 127 B Detaillierte Beschreibung des Simulationsmodells 131 C Grafiken des rekonstruierten Simulationsmodells 137 9

12 10

13 ABBILDUNGSVERZEICHNIS 1.1 Struktur der Arbeit Schema einer Lieferkette EPCIS Ereignisklassen MXML Struktur Process Mining Schema Beispiel Lieferkette Abbildung der Ereignis Attribute Beispielereignis im MXML Format Fokusverschiebung am Beispiel Modellierungsbeispiele Detailgrade bei Produktverfolgung Ausschnitt aus der Beispiel Unternehmenshierarchie Schematische Darstellung eines hierarchischen Petri Netzes Rekonstruierte Erweiterungstransition Einbettung der Transporttransitionen Benutzeroberfläche des ProM Import Werkzeuges

14 5.2 Visualisierung hierarchischer Petri Netze in ProM Visualisierung gefärbter Petri Netze in CPN Tools Einstellungsmöglichkeiten des Plug Ins EPCIS Miner Beispiellieferkette im Supply Chain Editor Laufzeit der EPCIS2MXML Implementierung Ergebnisse HeuristicsMiner Simulationsdaten Laufzeit der EPCIS Miner Implementierung Rekonstruierte Unternehmensebene Rekonstruierte Erweiterungsebene, Produktion des Türenherstellers Rekonstruierte Ereignisebene, Montageeinheit weiße Türen Rekonstruierte Unternehmensebene mit selektiver Produktverfolgung BRIDGE Soll Modell Ergebnisse HeuristicsMiner BRIDGE Daten Ergebnisse EPCIS Miner BRIDGE Daten B.1 Unternehmenshierarchie des Simulationsmodells C.1 Rekonstruierte Standortebene C.2 Rekonstruierte Erweiterungsebene C.3 Rekonstruierte Standortebene mit selektiver Produktverfolgung C.4 Rekonstruierte Erweiterungsebene mit selektiver Produktverfolgung

15 TABELLENVERZEICHNIS 3.1 Anforderungskatalog Knotentypen des Supply Chain Editor Erfüllung der Anforderungen B.1 SCOR-Prozessschritte im Simulationsmodell B.2 Produkttransformationen des Simulationsmodells

16 14

17 VERZEICHNIS DER BEISPIELE 1 Modellhafte Lieferkette Granularität Ereignistyp Abbildung Fokusverschiebung Lieferkettenknoten Transportweg Transport Ereignisse Modellierung einzelner Produkte Ereignismuster Ereignis Informationen Produktklassen Typen Rekonstruktion Erweiterungstransition Rekonstruktion Transporttransition

18 16

19 ABKÜRZUNGSVERZEICHNIS Auto ID BPEL BPMN BRIDGE..... CPN CPN ML..... eepk EPC EPCIS EPK EU GHz IT LTL MB MXML OCR PNML RFID Automatische Identifikation Business Process Execution Language Business Process Modeling Notation Building Radio frequency IDentification for the Global Environment Coloured Petri Net Coloured Petri Net Markup Language Erweiterte Ereignisgesteuerte Prozesskette Electronic Product Code EPC Information Services Ereignisgesteuerte Prozesskette Europäische Union Giga Hertz Informationstechnologie Linear time Temporal Logic Mega Byte Mining XML Optical Character Recognition Petri Net Markup Language Radio Frequency Identification S/ T Netz..... Stellen Transitions Netz SCM Supply Chain Management 17

20 SCOR SGLN SGTIN SSCC URI XML XPDL Supply-Chain Operations Reference-model Serialized Global Location Number Serialized Global Trade Item Number Serial Shipping Container Code Unique Resource Identifier Extensible Markup Language XML Process Definition Language 18

21 1 EINLEITUNG 1.1 MOTIVATION Zunehmende Globalisierung, wirtschaftlicher Druck und steigende Kundenanforderungen erfordern Zusammenarbeit zwischen Unternehmen. Es bilden sich dynamische Beziehungsnetzwerke von Unternehmen, welche durch Güter-, Finanz- und Informationsflüsse verbunden sind [Lin08]. Diese Lieferketten wachsen und verändern sich mit der Zeit und nicht immer ist jedem beteiligten Unternehmen der Gesamtüberblick klar [MWWv02]. Moderne Identifikationstechnologien wie RFID (Radio Frequency Identification) eröffnen neue Möglichkeiten, Lieferketten zu optimieren. Hauptsächlich werden dabei operative Aspekte betrachtet. Durch verbesserte Handhabung wie kontaktloses Auslesen oder Pulkerfassung ergeben sich direkte Vorteile wie Kostenreduktion durch Durchsatzerhöhung oder permanente Inventur. Die lückenlose Verfolgung individueller Produkte durch die Lieferkette ermöglicht u. a. verbesserte Ablaufkontrollen, Echtheitsprüfungen von Produkten oder Minimierung von Rückrufaktionen. Neben diesen operativen Aspekten ergeben sich weiterhin Potentiale durch die Analyse der protokollierten Produktbewegungen [GKK08, NMMK07]. Produkte unterliegen bei ihrem Weg durch die Lieferkette Transformationsprozessen. Sie werden erzeugt, umgewandelt, aggregiert, transportiert oder auch zerstört. Die protokollierten Produktbewegungen können u. a. Aufschluss über diese Transformationsprozesse geben. Oftmals ist das Wissen um die Unternehmensbeziehungen oder auch das Wissen um die Flüsse der Produkte in der Lieferkette nur implizit vorhanden. Es ist in textuellen Dokumenten, grafischen Diagrammen oder Datenbanktabellen verteilt, so dass zwar verschiedene Sichten auf das Gesamtbild existieren, das Gesamtbild jedoch nirgends explizit erfasst ist. Das explizite Herausarbeiten und Formalisieren dieses Prozesswissens in Modelle bringt mehrere Vorteile: 19

22 Verständnis: Die Konstruktion und Analyse von Modellen führt in der Regel zu einem tieferen Verständis der Prozesse als zum Beispiel das Lesen von Entwurfsdokumenten [JK09]. Komplexe Prozesse können durch Modelle vereinfacht dargestellt werden, wodurch leichter Probleme identifiziert und die Prozesse dadurch verbessert werden können. Dokumentation: Modelle können zur Dokumentation von Abläufen eingesetzt werden und vereinfachen damit u. a. die Kommunikation zwischen Partnerunternehmen. Optimierungsgrundlage: Modelle können einfach und kostengünstig verändert werden. Dadurch können mögliche Optimierungen zuerst am Modell umgesetzt und durch Simulation getestet werden, bevor sie in das laufende System übernommen werden. Durch Process Mining kann implizit vorhandenes Prozesswissen automatisiert herausgearbeitet werden. Als Grundlage dienen Ereignisprotokolle, welche bei der Ausführung von Prozessen erzeugt werden. Durch verschiedene Techniken werden explizite Prozessmodelle aus den Protokollen extrahiert und das Prozesswissen in formalisierter Form dargestellt. Prozessmodelle, welche auf diese Weise erstellt wurden, bieten neben den oben genannten Aspekten eine Reihe weiterer Vorteile und Verwendungsmöglichkeiten: Aktualität: Die Rekonstruktion durch Process Mining basiert auf Protokolldaten realer Prozesse. Im Gegensatz zu manuell erarbeiteten Modellen ermöglicht ein automatisch rekonstruiertes Modell damit Einsichten in die tatsächlich stattfindenden Prozesse. Qualitätsprüfung: Durch manuellen oder automatisierten Vergleich des rekonstruierten Modells (Ist Modell) mit dem geplanten Ablauf (Soll Modell) können Unterschiede festgestellt werden. Dadurch können zum Einen Abweichungen erkannt werden, welche sich negativ auswirken. Zum Anderen lassen sich Veränderungen feststellen, welche positive Auswirkungen haben, so dass das Soll Modell entsprechend angepasst werden kann. 1 Referenzkonformität: Werden die rekonstruierten Modelle mit Referenzmodellen der entsprechenden Domäne verglichen, können die tatsächlich stattfindenden Prozesse auf Konformität mit Referenzvorgaben geprüft werden. Dadurch kann eine verbesserte Zusammenarbeit zwischen Unternehmen erreicht werden. Process Mining wurde bisher hauptsächlich zur Rekonstruktion von Arbeitsabläufen in Geschäftsprozessen eingesetzt [vrw + 07, vm07, vv05a]. Darüber hinaus können Process Mining Techniken auf andere Arten von Prozesswissen (z. B. technische Prozesse) angewendet werden, wie jüngere Arbeiten zeigen [RZV + 08, RdGv07, MSL + 08]. Die Ereignisse, welche die z. B. durch RFID erfassten Produktbewegungen in einer Lieferkette protokollieren, enthalten implizites Wissen über die darin ablaufenden Prozesse und können daher als Ausgangspunkt für Process Mining verwendet werden. Das 1 Dies ist vergleichbar mit der Entdeckung von Trampelpfaden, welche eine Abkürzung darstellen. 20 Kapitel 1 Einleitung

23 Rekonstruieren der Transformationsprozesse von Produkten zur Analyse von Unternehmensbeziehungen und Produktflüssen in Lieferketten aus diesen Daten ist ein neues Anwendungsgebiet für Process Mining. Diese Arbeit versucht diese Lücke zu schließen. Durch Analyse von Lieferkettenmodellen, welche durch Process Mining gewonnen werden, können unterschiedliche Fragestellungen beantwortet werden: Welche Abhängigkeiten existieren zwischen verschiedenen Unternehmen einer Lieferkette? Welche Teile der Lieferkette sind betroffen, wenn Lieferschwierigkeiten in einem Bereich auftreten? Welche Knoten der Lieferkette müssen durch Redundanz in ihrer strategischen Position gestärkt werden? Welche Engpässe bestehen auf Transportwegen? Durchlaufen die Produkte alle nötigen Stationen einer Lieferkette (z. B. Qualitätskontrolle)? Werden alle Produkte zum richtigen Ort geliefert? Was ist die Durchlaufzeit bestimmter Produkte durch die Lieferkette? Welche Produkte bzw. die Produkte von welchem Hersteller werden überdurchschnittlich oft zurückgeliefert? Über welche Transportwege werden die Produkte geliefert, die an einem bestimmten Knoten der Lieferkette verarbeitet werden? An welchen Knoten der Lieferkette werden Produkte transformiert, aggregiert oder zerstört? Welche Rohprodukte wurden in ein bestimmtes Endprodukt verbaut? Diese Auflistung ist keinesfalls abschließend. Neben der Verwendung der Modelle für die Analyse können diese zusätzlich eingesetzt werden, um eine Echtzeitüberwachung einer Lieferkette durch logistische Assistenzsysteme zu erreichen [KHH08]. Durch die automatische Rekonstruktion der Modelle aus aktuellen Daten kann die Einführung solcher Systeme beschleunigt werden. 1.2 ZIELSTELLUNG Diese Arbeit soll untersuchen, inwiefern Techniken des Process Mining sinnvoll im Bereich von Lieferketten angewendet werden können. Grundsätzlich sind verschiedene Fragestellungen zu berücksichtigen, wenn Process Mining auf eine neue Domäne angewendet werden soll: 1.2 Zielstellung 21

24 Welche Aspekte des Prozesswissens sollen rekonstruiert werden? Welche Ereignisdaten stehen zur Verfügung? Wie können die zur Verfügung stehenden Daten für Process Mining zugänglich gemacht werden? Diese Fragestellungen können nicht losgelöst voneinander betrachtet werden. Die zur Verfügung stehenden Ereignisdaten bestimmen, welche Informationen rekonstruiert werden können. Die Wahl der zu rekonstruierenden Informationen beeinflusst, in welcher Weise die Daten für Process Mining aufbereitet werden müssen. Ziel dieser Arbeit ist es, die Anwendung von Process Mining Techniken zur Rekonstruktion von Transformationsprozessen von Produkten zu ermöglichen, um Unternehmensbeziehungen und Produktflüsse in der Lieferkette zu analysieren. Als Grundlage für das Process Mining sollen RFID Ereignisse dienen, welche die Produktbewegungen in einer Lieferkette protokollieren. Diese Ereignisse können weitere Informationen liefern, welche durch Process Mining rekonstruiert werden können. Es können die folgenden Teilaufgaben identifiziert werden: 1. Entwickeln einer Datenaufbereitung, d. h. Konvertierung der Ereignisse in ein für Process Mining Algorithmen verständliches Format. 2. Entwickeln eines Modellierungsansatzes, welcher die relevanten Informationen darstellen kann. 3. Identifizieren von Process Mining Ansätzen, bzw. Entwickeln eines Ansatzes, welcher die relevanten Informationen rekonstruieren kann. Dazu sind zuerst Anforderungen herauszuarbeiten, welche an jede Teilaufgabe gestellt werden. Die Anwendbarkeit des Gesamtansatzes soll mit einer prototypischen Implementierung gezeigt und anschließend bewertet werden. Die Arbeit hat nicht zum Ziel, eine allumfassende Lösung zu entwickeln, sondern will durch Umsetzung einer beispielhaften Lösung Möglichkeiten aufzeigen und damit zur Diskussion anregen. 1.3 AUFBAU DER ARBEIT Kapitel 2 gibt Hintergrundinformationen über die zu bearbeitende Aufgabe und verweist auf verwandte Arbeiten. Weiterhin werden Grundlagen zum Verständnis der weiteren Arbeit dargelegt. In Kapitel 3 werden Anforderungen an Process Mining in Bezug auf Lieferkettenprozesse herausgearbeitet, wobei die Teilaufgaben gesondert betrachtet werden. 22 Kapitel 1 Einleitung

25 Kapitel 4 stellt die entwickelte Lösung in Einzelheiten vor und schildert die Überlegungen, die zu dieser Lösung führten. In Kapitel 5 wird beschrieben, wie diese Lösung prototypisch implementiert wurde. Der entwickelte Ansatz und dessen Implementierung werden in Kapitel 6 einer Bewertung unterzogen, die sowohl die aufgestellten Anforderungen als auch die Anwendbarkeit auf reale Daten prüft. Kapitel 7 schließlich fasst die wichtigsten Ideen dieser Arbeit noch einmal zusammen und schließt diese mit einem Ausblick auf weitere Arbeiten ab. Abbildung 1.1 stellt die Struktur der Arbeit dar. Die Pfeile veranschaulichen den logischen Fluss durch die Arbeit. Kapitel 1: Einleitung Motivation Zielstellung Kapitel 2: Hintergrund und verwandte Arbeiten Lieferketten RFID Prozessmodellierung Process Mining Ereignisse Verwandte Arbeiten Kapitel 3: Anforderungen Datenaufbereitung Prozessmodellierung Process Mining Algorithmus Kapitel 4: Lösungsentwurf Konvertierung Prozessmodellierung Process Mining Algorithmus Kapitel 5: Implementierung Konvertierung Prozessmodellierung Process Mining Algorithmus Kapitel 6: Bewertung Simulationsmodell Reales Modell Anforderungen Kapitel 7: Zusammenfassung und Ausblick Zusammenfassung Weiterführende Ideen Abbildung 1.1: Struktur der Arbeit 1.3 Aufbau der Arbeit 23

26 24 Kapitel 1 Einleitung

27 2 HINTERGRUND UND VERWANDTE ARBEITEN Dieses Kapitel gibt Hintergrundinformationen über die zu bearbeitende Aufgabe und klärt die für das Verständnis der weiteren Arbeit nötigen Grundlagen und Begriffe. Weiterhin wird der Bezug zu verwandten Forschungsarbeiten hergestellt. 2.1 ANWENDUNGSDOMÄNE Lieferketten Der Begriff der Lieferkette (engl. supply chain) existiert seit über 30 Jahren und ist Gegenstand des Lieferkettenmanagements (engl. Supply Chain Management, SCM) [OW92]. Die Betrachtung von Lieferketten unterliegt einer ständigen Entwicklung [BW01], so dass zahlreiche voneinander abweichende Definitionen des Begriffs existieren. Im Allgemeinen wird eine Lieferkette (auch Liefernetzwerk) als ein Netzwerk aus verschiedenen Unternehmen betrachtet, welche durch Güter-, Finanz- und Informationsflüsse verbunden sind [Lin08]. Diese Arbeit legt den Fokus auf die logistische Struktur der Lieferkette, d. h. auf die Güterflüsse, welche sowohl zwischen verschiedenen Unternehmen als auch innerhalb der Unternehmen stattfinden. Die betrachteten Güter werden auch Produkte genannt und zu Produktklassen, d. h. Mengen gleichartiger Produkte, zusammengefasst. Abbildung 2.1 zeigt schematisch eine Lieferkette. Die Unternehmen nehmen in der Lieferkette verschiedene Rollen ein. Eine typische Lieferkette umfasst Zulieferer, Hersteller, Logistikdienstleister, (Zwischen- / Groß- / Einzel-) Händler und Verbraucher. Die Unternehmen der Lieferkette weisen sowohl logische Organisationsstrukturen auf (z. B. Abteilungen) als auch räumliche (z. B. Standorte). Die Produkte werden durch verschiedene Standorte bzw. Abteilungen der Unternehmen geleitet. Ein Unternehmen, auf welches besonderes Augenmerk gelegt wird, nennt man das fokale Unternehmen einer Lieferkette. 25

28 Unternehmen Standort Produktfluss Zulieferer Hersteller Logistikdienstleister Logistikdienstleister Großhändler Einzelhändler Verbraucher Abbildung 2.1: Schema einer Lieferkette Eine Lieferkette kann als Graphstruktur aufgefasst werden. Im Verlauf der weiteren Arbeit werden daher Unternehmen sowie Standorte auch als Knoten der Lieferkette bezeichnet Produktflüsse Produkte unterliegen bei ihrem Weg durch die Lieferkette einem Transformationsprozess. Sie werden erzeugt sowie durch Fertigungsverfahren in neue Produkte umgewandelt. Produkte können miteinander zu neuen Produkten vereinigt oder in mehrere Produkte aufgetrennt werden. Ebenso können Produkte zerstört werden. Diese eher elementaren Transformationen treten in verschiedenen Ausprägungen im Lebenszyklus der Produkte auf. Die Umwandlung von Produkten kann zum Beispiel das Veredeln von Rohprodukten sein. Beispiele für die Vereinigung von Produkten sind die Montage von Einzelteilen oder das Verpacken von Produkten in möglicherweise mehreren Stufen. Diese Transformationen treten an verschiedenen Knoten der Lieferkette auf, so dass der gesamte Produktfluss durch die Lieferkette als Prozess betrachtet werden kann. Der Begriff des Prozesses ist nicht einheitlich definiert und es existieren eine Vielzahl von Begriffen, welche teilweise synonym verwendet werden [WfM99, Sta06, JBS97, Rum99]. In Anlehnung an [Rum99] wird im Rahmen dieser Arbeit ein Prozess als eine abstrakte Beschreibung von Arbeitsabläufen verstanden. Ein Prozess umfasst einzelne Aktivitäten, zwischen denen Abhängigkeiten bestehen. Aktivitäten können Ressourcen benutzen, sie werden von Organisationseinheiten ausgeführt und können Datenobjekte verarbeiten. Ein Prozessmodell ist eine formalisierte Sicht auf einen Prozess. Jede konkrete Ausführung eines Prozesses wird als Prozessinstanz oder Fall bezeichnet. Wird ein Prozess durch ein IT System unterstützt, kann jede Ausführung einer Aktivität durch Ereignisse protokolliert werden. Ein Workflow ist ein teilweise oder vollständig automatisierter Prozess, bei welchem der Fokus auf dem Fluss von Informationen, Geschäftsdokumenten und Aufgaben liegt. Im Gegensatz dazu fokussiert diese Arbeit den Fluss und die Transformation physischer Objekte (Produkte). 26 Kapitel 2 Hintergrund und verwandte Arbeiten

29 Die im Rahmen dieser Arbeit betrachteten Prozesse können von mehreren Perspektiven betrachtet werden, welche unterschiedliche Aspekte des Prozesswissens beschreiben [JBS97, vw04]. Die Kontrollflussperspektive beschreibt u. a. die Ablaufreihenfolge von Aktivitäten, welche sich in den Produktflüssen manifestiert. Die Organisationsperspektive kann beschreiben, wie die Produktflüsse die Organisationsstrukturen der Unternehmen auf verschiedenen Ebenen kreuzen. Die Produkte können als (Daten-) Objekte aufgefasst werden, so dass die Beschreibung verschiedener Produkttransformationen aus der Datenperspektive erfolgen kann. Ebenso können die Prozesse aus einer Leistungsperspektive betrachtet werden, etwa zur Analyse von Durchlaufzeiten Produktidentifikation Um Objekte automatisch zu identifizieren, werden sogenannte Auto ID Verfahren (Automatische Identifikation) eingesetzt. Unter Anderem werden diese Verfahren verwendet, um Produkte auf ihrem Weg durch die Lieferkette zu verfolgen. Es existieren verschiedene Identifikationstechnologien, typischerweise werden in Lieferketten Systeme wie Barcode, OCR (Optical Character Recognition), 2D Systeme oder RFID verwendet [Str05, GKK08]. Allen gemeinsam ist, dass Identifikationsmerkmale durch Datenträger an die Produkte angebracht werden, von entsprechenden Geräten ausgelesen und durch Informationstechnologie (IT) Systeme verarbeitet werden. Unterschiede bestehen u. a. in der technischen Konzeption sowie der Anwendung der Technologien. Die RFID Technologie birgt mehrere Vorteile gegenüber anderen Auto ID Technologien. Nachfolgend sind die wichtigsten davon genannt. Kontaktloses Auslesen: Die Informationen der Datenträger werden durch Radiowellen übertragen und können daher berührungslos und ohne Sichtkontakt ausgelesen werden. Pulkerfassung: Die Möglichkeit zur gleichzeitigen Erfassung mehrerer Objekte vereinfacht Abläufe und erhöht den Durchsatz. Hohe Speicherkapazität: Die höhere Speicherkapazität der Datenträger einiger RFID- Systeme ermöglicht zum Einen die Identifikation individueller Produkte im Gegensatz zur Identifikation auf Produktklassenebene. Zum Anderen können dadurch zusätzliche Informationen über die Produkte gespeichert werden. Zu einem RFID System gehören verschiedene Komponenten. Transponder stellen die Datenträger dar, welche an den zu identifizierenden Objekten angebracht werden. Die auf den Transpondern gespeicherten Informationen werden durch Lesegeräte über elektromagnetische Wellen ausgelesen und zur weiteren Verarbeitung an die RFID Middleware weitergeleitet. Eine detailliertere Darstellung liefert u. a. [Fin06]. 2.1 Anwendungsdomäne 27

30 2.1.4 Standardisierung Um den Informationsaustausch zwischen Unternehmen zu gewährleisten, ist der Einsatz von Standards unerlässlich. Die Organisation EPCglobal TM definiert globale Standards für Produktidentifikationstechnologien, im Speziellen für die Nutzung der RFID Technologie [epc09]. Der EPC Tag Datenstandard [epc08] beschreibt den elektronischen Produktcode (Electronic Product Code TM, EPC TM ), welcher eine Familie aus Identifikationsschemata darstellt. Die verschiedenen EPC Typen in dieser Familie sind für die Identifikation verschiedener Objekte vorgesehen. Der EPC Typ SGTIN zum Beispiel wird für die Identifikation von Handelsgütern verwendet, der EPC Typ SSCC für die Identifikation von Versandeinheiten und der EPC Typ SGLN für die Identifikation von Unternehmen und Unternehmenseinheiten [ids09]. Es gibt verschiedene Darstellungsformen für EPCs. Für diese Arbeit ist die Repräsentation als URI (Unique Resource Identifier) wichtig. Für die genannten EPC Typen folgt die URI Repräsentation den folgenden Schemata: SGTIN SSCC SGLN urn:epc:id:sgtin:companyprefix.itemreference.serialnumber urn:epc:id:sscc:companyprefix.serialreference urn:epc:id:sgln:companyprefix.locationreference.extensioncomponent Im ersten Teil wird jeweils der verwendete EPC Typ angegeben. Das Feld CompanyPrefix gibt für alle EPC Typen eine Identfikationsnummer für Unternehmen an. Für den EPC- Typ SGTIN bezeichnet das Feld ItemReference eine Produktklasse des entsprechenden Unternehmens und das Feld SerialNumber ein konkretes Produkt dieser Produktklasse. Durch Abspalten des letzten Feldes erhält man die URI Repräsentation für die Produktklasse (EPC Class). Das Feld SerialReference bei dem EPC Typ SSCC referenziert eine konkrete Versandeinheit des entsprechenden Unternehmens. Für den EPC Typ SGLN bezeichnet das Feld LocationReference einen Unternehmensteil des angegebenen Unternehmens und das Feld ExtensionComponent eine individuelle eindeutige Lokation. Der ebenfalls von EPCglobal herausgegebene Standard für EPC Informationsdienste (EPCIS) [epc07] regelt die Erfassung und Abfrage von EPC Informationen über Produkte. Der Standard definiert Struktur und Inhalt der erfassten Daten, welche als Ereignisse protokolliert werden. Abbildung 2.2 stellt die EPCIS Ereignisklassen dar. 1 Der Standard beschreibt eine abstrakte Ereignisklasse EPCISEvent, sowie vier spezifische Ereignisklassen für unterschiedliche Anwendungsfälle, welche von dieser abgeleitet sind: Objektereignisse (ObjectEvents) dienen zur Protokollierung von Beobachtungen einzelner oder mehrerer EPCs. Aggregationsereignisse (AggregationEvents) werden verwendet, wenn Produkte physisch zu einer Einheit aggregiert sind. Transaktionsereignisse (Transaction- Events) stellen Verbindungen zwischen EPCs und Geschäftstransaktionen her. Quantitätsereignisse (QuantityEvents) dienen der Erfassung von Mengenangaben für eine Produktklasse. Jede Ereignisklasse trägt eine Menge von Attributen, welche in vier Dimensionen unterteilt werden. Damit beschreiben die Ereignisse, welche Objekte zu welchem Zeitpunkt an 1 Die Abbildung ist an [epc07], S. 29 angelehnt. Es wurden mehrere Informationen weggelassen. 28 Kapitel 2 Hintergrund und verwandte Arbeiten

31 EPCISEvent eventtime : Time... ObjectEvent epclist : List<EPC> action : Action bizstep : BizStepID disposition : DispositionID readpoint : ReadPointID bizlocation : BizLocationID <<extension-point>> QuantityEvent epcclass : EPCClass quantity : int... <<extension-point>> AggregationEvent parentid : URI childepcs : List<EPC> action : Action bizstep : BizStepID disposition : DispositionID readpoint : ReadPointID bizlocation : BizLocationID <<extension-point>> biztranslist biztranslist biztranslist TransactionEvent parentid : URI childepcs : List<EPC> action : Action bizstep : BizStepID disposition : DispositionID readpoint : ReadPointID bizlocation : BizLocationID <<extension-point>> 0..* 0..* biztranslist 0..* 1..* BizTransaction Abbildung 2.2: EPCIS Ereignisklassen welchem Ort und in welchem Geschäftskontext beobachtet wurden. Das Attribut action, welches von Objekt-, Aggregations- und Transaktionsereignissen verwendet wird, stellt eine Beziehung des Ereignisses zum Lebenszyklus der beobachteten Objekte her. Der Wert des Attributes (ADD, OBSERVE oder DELETE) signalisiert beispielsweise für Aggregationsereignisse, ob Objekte aggregiert wurden, das Aggregat beobachtet wurde oder Objekte dem Aggregat entnommen wurden. Der Standard spezifiziert mehrere Erweiterungsmöglichkeiten, so dass neben den vordefinierten Attributen weitere Erweiterungsattribute verwendet werden können. Weiterhin ist durch den Standard die Speicherung von Ereignissen in einem EPCIS- Datenverzeichnis (Repository) vorgesehen, auf welches über Schnittstellen zugegriffen wird. Der Standard definiert eine Erfassungsschnittstelle zur Speicherung sowie eine Abfrageschnittstelle zum Abruf von Daten. Mit der Abfrageschnittstelle sind verschiedene Filterparameter spezifiziert, welche verwendet werden können, um die Ergebnismenge auf bestimmte Ereignisklassen oder Attributwerte einzuschränken. Es gibt mehrere Implementierungen des EPCIS Standards. Kommerzielle Implementierungen existieren z. B. von ORACLE (Referenzimplementierung) [epc06], SAP [sap07] oder IBM [ibm06]. Des Weiteren existieren Open Source Lösungen, z. B. FOSSTRAK [fos09] und MIT EPC NET (MENTOR) [men08]. Über die Referenzimplementierung der Informationsdienste hinaus existieren keine Richtlinien für die Anwendung der Ereignisse. 2 2 Dadurch können identische Vorgänge von unterschiedlichen Unternehmen in der Lieferkette auch unterschiedlich durch EPCIS Ereignisse protokolliert werden. 2.1 Anwendungsdomäne 29

32 2.2 PROCESS MINING Das Forschungsgebiet Process Mining beschäftigt sich damit, Prozesswissen aus protokollierten Daten zu extrahieren. Die Aufgaben des Process Mining umfassen sowohl die Rekonstruktion formaler Prozessmodelle aus Ereignisprotokollen als auch die Analyse von Protokollen und Prozessmodellen aus verschiedenen Perspektiven [vw04, vrw + 07]. Durch die Verwendung von Ereignisprotokollen werden Einsichten in die tatsächlich ablaufenden Prozesse ermöglicht, im Gegensatz zur Verwendung manuell erstellter Modelle. Der folgende Abschnitt stellt einige Process Mining Techniken vor und zeigt, wie diese für die Analyse von EPCIS Ereignissen verwendet werden können Anwendung auf Aufgabenstellung Es sind eine Reihe von Process Mining Ansätzen verschiedener Perspektiven implementiert. Die zentrale Aufgabe dieser Arbeit ist daher die Aufbereitung der zur Verfügung stehenden Ereignisdaten in geeigneter Weise, so dass diese Ansätze verwendet werden können, um verschiedene Aspekte des Prozesswissens aus den EPCIS Ereignissen zu extrahieren. Die im Process Mining dominante Perspektive ist die Kontrollflussperspektive [vw04]. Es existieren viele verschiedene Ansätze dieser Perspektive, welche sowohl unterschiedliche Ideen zu Rekonstruktion umsetzen, als auch unterschiedliche Methoden zur Modellierung der rekonstruierten Prozesse verwenden. Diese Implementierungen können verwendet werden, um die Reihenfolge der Lieferkettenknoten in den Flüssen der verschiedenen Produkte zu rekonstruieren. Zum Beispiel erzeugt der AlphaMiner [vwm04] Petri Netze, der HeuristicsMiner [WvA06] generiert heuristische Netze (von Petri Netzen abgeleitete Notation) und der Multi Phase Miner [vv05b] stellt die rekonstruierten Prozesse als ereignisgesteuerte Prozessketten dar. Die umgesetzten Ideen zur Rekonstruktion der Prozessmodelle umfassen neben rein algorithmischen Methoden auch genetische Algorithmen [vaw05] oder Techniken des maschinellen Lernens [Goe08, HHK04]. Eine umfangreiche Gegenüberstellung verschiedener Process Mining Ansätze der Kontrollflussperspektive bietet [Lan08]. Die rekonstruierten Prozessmodelle können die topologische Struktur der Lieferkette auf einer bestimmten Granularitätsebene abbilden. Diese Ebene wird durch die Aufbereitung der Ereignisdaten festgelegt. Alle betrachteten Ansätze dieser Perspektive rekonstruieren nur die Reihenfolge bzw. kausale Abhängigkeiten zwischen den Aktivitäten. Dabei wird nicht auf die Nutzung und den Fluss von Datenobjekten eingegangen, wodurch Informationen über den Fluss und die Transformationen von Produkten verloren gehen. Es existieren ebenfalls Ansätze zur Rekonstruktion von Organisationsaspekten. Durch den Organizational Miner [org09] kann identifiziert werden, welche Aktivitäten durch welche Unternehmen bzw. Unternehmensteile durchgeführt werden, wodurch z. B. Redundanzen in der Aufgabenverteilung aufgedeckt werden können. Der Social Network Miner [vs04] dient zur Rekonstruktion von sozialen Netzwerken, welche den Grad der Zusam- 30 Kapitel 2 Hintergrund und verwandte Arbeiten

33 menarbeit zwischen Unternehmen bzw. Unternehmensteilen darstellen können. Die Granularitätsebene wird auch hier durch die Datenaufbereitung festgelegt. Datenaspekte werden im Kontext des Process Mining bisher weniger berücksichtigt [RMv06]. Bei der Entscheidungspunktanalyse z. B. dienen Datenattribute von Ereignissen als Grundlage für Verzweigungsentscheidungen in Prozessmodellen der Kontrollflussperspektive. Andere Process Mining Ansätze verwenden Datenattribute für die regelbasierte Analyse der Ereignisprotokolle. Zum Beispiel können Protokolle durch den LTL Checker auf verschiedene Eigenschaften geprüft werden, welche in der temporalen Logik LTL (Linear time Temporal Logic) formuliert sind [vdv05]. Dadurch können die Produktflüsse durch verschiedene Konsistenzregeln geprüft werden. 3 Ansätze der Leistungsperspektive können verwendet werden, um z. B. Durchlaufzeiten von Produkten durch die gesamte Lieferkette oder Transportzeiten zwischen einzelnen Knoten zu analysieren [vv02]. Alle betrachteten Ansätze fokussieren jeweils einen bestimmten Aspekt des Prozesswissens. In [RMv06] wird ein Ansatz vorgestellt, welcher verschiedene Perspektiven kombiniert. Wie die meisten Process Mining Ansätze ist auch dieser auf die Analyse von Workflows ausgerichtet, wobei der Fluss von Datenobjekten nicht berücksichtigt wird. Keiner der betrachteten Ansätze ist in der Lage, Produktflüsse zwischen den Knoten der Lieferkette bzw. Transformationen zwischen Produkten oder Produktklassen direkt zu rekonstruieren. Daher wird im Rahmen dieser Arbeit weiterhin ein Algorithmus entwickelt, welcher speziell Modelle von Lieferketten und der darin auftretenden Produktflüsse und -transformationen unter Integration verschiedener Perspektiven rekonstruieren soll Protokollformat Im Process Mining werden Ereignisprotokolle verarbeitet. Diese Protokolle liegen in einer Vielzahl von Formaten vor, da die Protokollierung von Prozessen durch Informationssysteme nicht einheitlich ist. Es existieren Standardisierungsbemühungen für ein einheitliches Protokollformat für Process Mining [pmt09]. In [vv05a] werden Anforderungen an ein solches Format identifizert: Jedes Ereignis muss zu einem (Auftritts-) Zeitpunkt zugeordnet werden können. Jedes Ereignis muss eindeutig zu einer Aktivität zugeordnet werden können. Jedes Ereignis muss eine Beschreibung aufweisen, welche die Semantik des Ereignisses erklärt. Jedes Ereignis muss einer Prozessinstanz (Fall) zugeordnet werden können. Jede Prozessinstanz muss zu einem bestimmten Prozess zugeordnet werden können. 3 In [IAM09] werden verschiedene Regeln vorgeschlagen, welche für eine Analyse von EPCIS Ereignissen sinnvoll sind. 2.2 Process Mining 31

34 WorkflowLog 1..* Process 0..* ProcessInstance 1..* 1..* 1 0..* WorkflowModelElement AuditTrailEntry Data attributes : List<NameValuePair> eventtype : String timestamp : Date originator : Person Abbildung 2.3: MXML Struktur Während die meisten dieser Anforderungen eher unkritisch sind, gestaltet sich die vierte je nach Quelle des Ereignisprotokolls schwieriger. Die Ereignisse mancher Informationssysteme sind bereits mit einem Fallidentifikator versehen. Für andere muss diese Zuordnung nachträglich durchgeführt werden. Die EPCIS Ereignisse, welche im Rahmen dieser Arbeit verwendet werden, tragen keinen Fallidentifikator. Im Rahmen dieser Arbeit muss daher geklärt werden, wie die Zuordnung der Ereignisse zu Prozessinstanzen geschehen soll. Abschnitt wird zeigen, dass die Verwendung eines EPC als Fallidentifikator nicht ausreichend ist, da Produkttransformationen die durchgängige Protokollierung einzelner Produkte verhindern. In [vv05a] wird ein Meta Modell vorgeschlagen, auf welches sich viele Protokollstrukturen abbilden lassen. Es wird gezeigt, dass das Modell die aufgestellten Anforderungen erfüllt. Ebenfalls wird eine XML Repräsentation (Extensible Markup Language) angegeben, das sogenannte MXML Format (Mining XML). In Abbildung 2.3 ist die Struktur eines MXML Dokuments dargestellt. Ein Ereignisprotokoll (WorkflowLog) beinhaltet Ereignisse eines oder mehrerer Prozesse. Ein Prozess, zu welchem eine Menge von Aktivitäten (WorkflowModelElement) gehören, ist durch eine Menge von Prozessinstanzen repräsentiert. Jeder Prozessinstanz ist eine Menge von Ereignissen (AuditTrailEntry) zugeordnet, welche die Aktivitäten des Prozesses protokollieren. Neben Attributen für den Ereignistyp, den Auftrittszeitpunkt oder den Verursacher kann ein Ereignis durch zusätzliche Daten beschrieben werden, welche als Menge von Attribut Wert Paaren vorliegen Process Mining Implementierungen Im kommerziellen Bereich existieren Werkzeugsammlungen wie Aris PPM [Ari09] oder Fujitsu Interstage [Fuj09], welche teilweise Process Mining Aufgaben erfüllen. Ebenso gibt es reine Process Mining Implementierungen wie Iontas Process Discovery Focus [ion09], Futura Reflect [fut09] oder OpenConnect Comprehend [occ09]. 32 Kapitel 2 Hintergrund und verwandte Arbeiten

35 Datenaufbereitung/ Konvertierung MXML Process-Mining Ereignisquellen Einheits- Format Prozessmodelle ProM Import ProM Abbildung 2.4: Process Mining Schema Verschiedene akademische Implementierungen wie Process Miner [Sch02], InWoLvE [HK04] oder [AGL98] setzen einzelne Process Mining Algorithmen um und stellen damit Insellösungen dar. Auch ist die Verfügbarkeit solcher Implementierungen teilweise eingeschränkt. Die Eingabeformate für diese Implementierungen sind proprietärer Natur. Im Gegensatz dazu stellt die Open Source Lösung ProM eine ganze Infrastruktur für Process Mining zur Verfügung [pro09b, vav + 05, vrw + 07]. Die Idee ist, Interoperabilität und Vergleichbarkeit zwischen verschiedenen Ansätzen zu erreichen, indem diese in einem gemeinsamen Framework umgesetzt werden. Abbildung 2.4 zeigt schematisch, wie diese Idee durch ProM realisiert wird. ProM ist als Arbeitsplattform konzipiert, die neben einer grundlegenden Infrastruktur zur Ereignisverarbeitung eine Vielzahl spezieller Plug Ins anbietet, die einzelne Process Mining Algorithmen umsetzen. Durch diese Modularität ist die Erweiterung der Plattform um neue Funktionalitäten relativ einfach möglich. Durch die Bereitstellung vieler Funktionen durch Programmbibliotheken kann die Implementierung neuer Process Mining Algorithmen mit einem Minimalaufwand begonnen werden. ProM verwendet das im vorangegangenen Abschnitt beschriebene MXML Format als Eingabeformat. Durch die ebenfalls modular aufgebaute Software ProM Import werden verschiedene Konvertieralgorithmen bereitgestellt, welche Ereignisdaten aus diversen Quellen in das MXML Format überführen [pro09a, Gv06]. 2.3 PROZESSMODELLIERUNG Ein Process Mining Algorithmus rekonstruiert Prozessmodelle. Um Prozesse zu modellieren, existieren eine Vielzahl von Ansätzen. Diese unterscheiden sich u. a. in ihrer Repräsentation (graphisch, textuell), ihrer Ausdruckskraft sowie der Existenz einer formalen Semantik. Ebenso variiert die Werkzeugunterstützung durch Software zwischen den verschiedenen Ansätzen. Einen Überblick über Methoden zur Prozessmodellierung mit graphischer Repräsentation liefert [Gad05], ein Vergleich ausgewählter Methoden bezüglich der Modellierung RFID gestützter Geschäftsprozesse ist in [Wil06] zu finden. 2.3 Prozessmodellierung 33

36 An dieser Stelle werden einige Ansätze skizziert, welche im Rahmen dieser Arbeit betrachtet wurden, um rekonstruierte Lieferkettenmodelle darzustellen. Dabei wurde untersucht, welche Informationsaspekte in dem Modellierungsansatz ausdrückbar sind, ob der Fluss von Datenobjekten (Produkten) modellierbar ist sowie ob die Modellierung von Organisationsstrukturen möglich ist. Weitere Aspekte sind die Lesbarkeit bzw. Handhabbarkeit der Modelle sowie die Existenz einer formalen Semantik. Letzteres ist wichtig für die Möglichkeit weiterer Analysen der Modelle. Es wurden nur Modellierungssprachen betrachtet, welche eine graphische Repräsentation besitzen Prozessketteninstrumentarium Das Instrumentarium der Prozessketten nach Kuhn [Kuh95, Kuh99] dient zur Modellierung logistischer Prozesse. Durch Prozessketten kann eine Vielzahl von Aspekten dargestellt werden, darunter Prozessabläufe, Ressourcen sowie betriebswirtschaftliche Kennzahlen. Materialflüsse können auf hoher Abstraktionsebene modelliert werden. Durch die zeitliche Orientierung sind Prozessabläufe und Materialflüsse nur unidirektional modellierbar, d. h. zyklische Prozessstrukturen sind nicht direkt ausdrückbar. Des Weiteren ist die Modellierung mit Prozessketten stark geprägt von Kennzahlen wie Kapazitäten, Kosten oder Termintreue, wodurch die Modelle sehr komplex und schwer lesbar sind. Das Prozessketteninstrumentarium besitzt als semiformale Sprache keine klar definierte Semantik, es existieren jedoch Formalisierungsansätze, z. B. durch Übersetzung in Petri- Netze [Kem00] oder Erweiterung des Paradigmas [BBF + 02] Business Process Modeling Notation Die Business Process Modeling Notation (BPMN) ist eine graphische Notation für Geschäftsprozesse [bpm09, All09]. 4 Es können nebenläufige Arbeitsabläufe und Ressourcen dargestellt werden, sowie durch Pools und Schwimmbahnen unterschiedliche Organisationseinheiten modelliert werden. Es existiert die Möglichkeit zur hierarchischen Strukturierung der Diagramme. Die Modellierung von Datenobjekten ist möglich, jedoch nicht geeignet, um durchgängige Flüsse zu visualisieren. Die Semantik der BPMN ist nicht klar definiert, es existieren aber unvollständige Übersetzungen in Ausführungssprachen für Geschäftsprozesse wie BPEL (Business Process Execution Language) oder XPDL (XML Process Definition Language). Die Angabe von Zeitverbrauch für Modellelemente ist in der BPMN nur eingeschränkt möglich, einen Vorschlag zur Erweiterung diesbezüglich bietet [GT09] Ereignisgesteuerte Prozessketten Im Process Mining werden vorwiegend ereignisgesteuerte Prozessketten (EPK) und Petri- Netze zur Repräsentation von Prozessmodellen verwendet [vv05b, Ari09, vrw + 07]. Durch 4 Der Betrachtung wurde die Version 1.2 des BPMN Standards zu Grunde gelegt. 34 Kapitel 2 Hintergrund und verwandte Arbeiten

37 ihre Verwendung in den Referenzmodellen der Standardsoftware SAP R/3 sind EPKs eine sehr verbreitete Modellierungsmethode [Rum99]. Durch EPKs können Arbeitsabläufe leicht verständlich durch Ereignisse und Funktionen modelliert werden. Erweiterte EPKs (eepk) können zusätzlich Organisationseinheiten sowie Informationsobjekte darstellen [Sta06]. Möglich ist auch die hierarchische Strukturierung der Modelle. Organisationsbrüche, d. h. Wechsel der Organisationseinheiten zwischen aufeinanderfolgenden Funktionen können nur durch Anpassung des Layouts erkannt werden. Ähnlich wie bei der BPMN ist die Modellierung der Informationsobjekte nicht für die Visualisierung durchgängiger Flüsse geeignet. EPKs stellen einen semiformalen Ansatz dar, in der Literatur existieren aber Formalisierungsansätze, z. B. [Rum99]. Für die Rekonstruktion von Prozessmodellen durch Process Mining sind EPKs nur bedingt geeignet. Durch die erzwungene alternierende Folge aus Ereignissen und Funktionen enthalten die rekonstruierten Modelle sehr viel Redundanz, da beim Process Mining nicht beide Elementtypen rekonstruiert werden können. Die Angabe von Zeitverbrauch für die Funktionen ist nicht möglich Petri Netze Petri Netze sind mathematische Modelle zur Modellierung nebenläufiger Prozesse. Sie besitzen eine graphische Repräsentation sowie eine formale Semantik. Dadurch haben Petri Netze eine hohe Bedeutung sowohl in der theoretischen Informatik als auch in der Modellierung von Geschäftsprozessen erlangt [PW03, van02]. Die Petri Netztheorie umfasst eine Vielzahl verschiedener Klassen von Petri Netzen sowie ein reichhaltiges Angebot an Analysemethoden. Ein vollständiger Überblick kann an dieser Stelle nicht gegeben werden. Gegenüberstellungen verschiedener Netzklassen in Bezug auf die Modellierung von Arbeitsabläufen finden sich z. B. in [Obe96] oder [JVW00]. Das Grundmodell aller Petri Netze bilden die Stellen Transitions Netze (S/ T Netze). Die Modellierungselemente sind Plätze (auch Stellen) und Transitionen, welche durch Kanten alternierend verbunden werden. Graphisch werden Plätze als Kreise, Transitionen als Rechtecke und Kanten als Pfeile dargestellt. Die Semantik der Netze wird durch Markierungen definiert. Jeder Platz kann eine Menge von Objekten enthalten, welche Marken genannt werden. Eine Transition kann aktiviert werden, wenn auf jedem Platz, von welchem eine Kante zur Transition führt (Eingabeplatz), mindestens eine Marke liegt. Ist eine Transition aktiviert, kann sie schalten, indem sie von allen Eingabeplätzen je eine Marke entfernt und jedem Ausgabeplatz je eine Marke hinzufügt. Transitionen stellen damit aktive Einheiten dar und können dadurch zum Beispiel Aktivitäten eines Prozesses repräsentieren. Einfache Petri Netze wie S/ T Netze sind aufgrund der kleinen Anzahl verschiedener Modellierungselemente leicht verständlich. Der Fluss von Datenobjekten ist durch Marken modellierbar. Da diese jedoch nicht unterscheidbar sind, können verständliche Modelle nur durch aussagekräftige Namen an Plätzen modelliert werden. In ihrer Grundform sind einfache Netze nicht strukturierbar und können Organisationsstrukturen nicht direkt abbilden. Temporale Aspekte werden bei einfachen Petri Netzen vernachlässigt. 2.3 Prozessmodellierung 35

38 Gefärbte Petri Netze Neben den einfachen Petri Netzklassen gibt es eine Reihe höherer Petri Netzklassen, welche Konzepte wie unterscheidbare Marken, temporale Aspekte oder hierarchische Gruppierung umsetzen [JR91, Wan98, Feh92]. Die Klasse der gefärbten Petri Netze (Coloured Petri Nets, CPN) umfasst alle genannten Konzepte [Jen97, JK09]. Jede Marke stellt einen Datenwert (Farbe) eines bestimmten Datentyps (Farbmenge) dar. Jeder Platz kann nur Marken eines bestimmten Datentyps aufnehmen. Durch Kantenausdrücke können Bedingungen in einer funktionalen Programmiersprache angegeben werden, welche das Schaltverhalten der Transitionen beeinflussen. Weiterhin kann Zeitverbrauch durch Kantenausdrücke und Annotationen an Transitionen modelliert werden. Zur Strukturierung der Netze können verschiedene Hierarchiekonzepte eingesetzt werden. Dadurch können u. a. Organisationsstrukturen abgebildet werden. Ein hierarchisches Netz besteht aus mehreren Seiten, wovon jede ein Petri Netz darstellt. Substitutionstransitionen sind Transitionen, welche durch eine Seite verfeinert modelliert werden. Dazu werden die umliegenden Plätze einer Substitutionstransition zu Plätzen in der zugeordneten Seite zugewiesen (Portzuweisung). Durch das Konzept der Fusionsplätze können mehrere Plätze in einer Seite oder sogar in verschiedenen Seiten des Netzes als verschiedene Repräsentationen eines einzigen Platzes dargestellt werden. Dadurch kann zum Einen Interaktion zwischen verschiedenen Modellteilen erreicht werden. Das Konzept wird zum Anderen eingesetzt, um übersichtliche Darstellungen zu erhalten. In [HJS91] werden weitere Hierarchiekonzepte für gefärbte Petri Netze vorgeschlagen. 2.4 VERWANDTE ANSÄTZE In der vorliegenden Arbeit werden EPCIS Ereignisse verwendet, um mittels Process- Mining Lieferkettenmodelle zu rekonstruieren. Dabei wird der Fokus auf die Rekonstruktion von Produktflüssen gelegt und ein Ansatz verfolgt, welcher die integrierte Modellierung verschiedener Perspektiven ermöglicht. Die rekonstruierten Modelle sollen sowohl der Visualisierung dienen, als auch für weitere (formale) Analysen verwendet werden. An dieser Stelle werden Arbeiten aufgeführt, welche ähnliche Ziele verfolgen. Zuerst werden Arbeiten betrachtet, welche sich mit der Analyse von EPCIS- bzw. RFID Daten beschäftigen. Im Anschluss werden Arbeiten aus dem Gebiet Process Mining betrachtet. Eine Arbeit, welche die Visualisierung von EPCIS Ereignissen untersucht, ist [Hof07]. Mit der Hauptzielsetzung, Produktfälschungen aufzudecken, werden verschiedene Möglichkeiten der Visualisierung von Ereignisdaten wie Sequenzdiagramme oder Graphstrukturen vorgeschlagen. Die Resultate sind keine formalen Modelle und die Eigenständigkeit der Lösung lässt wenig Vergleichbarkeit und Analysemöglichkeiten der visualisierten Daten zu. In [IAM09] wird ein regelbasierter Ansatz verfolgt, um Konsistenzprüfungen von EPCIS- Ereignissen durchzuführen. Zusätzlich werden die Ereignisse geographisch visualisiert. Der Ansatz verwendet nur EPCIS Objektereignisse, wodurch wichtige Informationen aus 36 Kapitel 2 Hintergrund und verwandte Arbeiten

39 den Daten wie Aggregationsstrukturen ignoriert werden. Ebenfalls findet keine Zuordnung zu Unternehmensstrukturen statt. Im Rahmen des EU Projektes BRIDGE (Building Radio frequency IDentification for the Global Environment) [bri09a] findet sich ein ähnlicher Forschungsansatz, welcher die Visualisierung von Lieferketten zum Ziel hat. Der Ansatz verwendet EPCIS Ereignisse, um Modelle zu rekonstruieren, welche das Zusammenspiel von Lieferkettenknoten auf der Ebene der RFID Lesepunkte darstellen. Dabei werden keine Unterscheidungen zwischen verschiedenen Produktklassen getroffen. Ebenfalls werden die Organisationsstrukturen der Unternehmen sowie temporale Aspekte vernachlässigt. In [CCLK06] wird eine Visualisierung der topologischen Struktur von Liefernetzwerken angestrebt. In einem gewichteten Graphen werden Knoten der Lieferkette dargestellt, sowie ein quantitativer Grad der Zusammenarbeit zwischen Knoten. Die Arbeit verwendet keine EPCIS Ereignisse, sondern geht von Ereignisprotokollen aus, in welchen die Ereignisse bereits zu Produkten gruppiert sind. Da nur die Topologie des Netzwerks rekonstruiert wird, findet keine Unterscheidung zwischen verschiedenen Produkten bzw. Produktklassen statt. Eine ähnliche Arbeit ist [GHL06], welche eine Rekonstruktion von Produktflüssen anhand von RFID Daten beschreibt. Der Fokus der Arbeit liegt auf der Konstruktion einer komprimierten Darstellung, so dass von vielen Informationen abstrahiert wird. Dabei gehen auch die Informationen über verschiedene Produkte und Produktklassen verloren. Auch diese Arbeit geht davon aus, dass die Daten bereits zu Pfaden einzelner Produkte gruppiert sind. In [MWWv02] werden Möglichkeiten und Herausforderungen für die Anwendung von Process Mining für Lieferkettenprozesse aufgezeigt. Dabei werden Arbeitsabläufe in Geschäftsprozessen fokussiert im Gegensatz zu dieser Arbeit, welche sich primär der Rekonstruktion physischer Flüsse widmet. In [RMv06] wird ein Process Mining Ansatz vorgestellt, welcher verschiedene Perspektiven des Prozesses in einem Modell darstellt. Dabei wird ein mehrphasiger Ansatz verwendet. Die einzelnen Perspektiven werden separat rekonstruiert. Die Informationen jeder Perspektive werden dann in einem Modell auf Basis gefärbter Petri Netze integriert. In [MNPV04] und [log05] werden gefärbte Petri Netze verwendet, um logistische Probleme durch Simulation zu analysieren. Die modellierten Probleme sind dabei abstrakt gehalten und Produktflüsse nur quantitativ erfasst. Die Aufbereitung von Ereignisdaten ohne Fallidentifikator für Process Mining wird z. B. in [IG07] und [van04] addressiert. Dabei werden verschiedene Methoden (manuell / Werkzeug gestützt) beschrieben, welche Ereignisse aus SAP Standardsoftware in ein XML- Format konvertieren. Die Fallzuordnung wird über logisch verknüpfte Dokumentenbezeichner hergestellt. Process Mining wurde bisher primär für die Rekonstruktion von Arbeitsabläufen in Geschäftsprozessen (Workflows) eingesetzt. Es existieren aber auch Arbeiten, welche Process Mining anwenden, um andere Arten von Prozessen zu rekonstruieren. In [RZV + 08] 2.4 Verwandte Ansätze 37

40 wird die Anwendbarkeit auf Multiagentensysteme untersucht. Konkret werden Teamstrategien im Roboterfussball durch Rekonstruktion der Abläufe der Teamformationen analysiert. In [RdGv07] werden Process Mining Techniken angewendet, um Abläufe von Wafertests in der Chipherstellung zu rekonstruieren. In [MSL + 08] wird die Anwendbarkeit von Process Mining in der Gesundheitsbranche demonstriert, indem Behandlungsverläufe von Schlaganfall Patienten für verschiedene Krankenhäuser rekonstruiert und verglichen werden. 38 Kapitel 2 Hintergrund und verwandte Arbeiten

41 3 ANFORDERUNGEN In diesem Kapitel werden Anforderungen herausgearbeitet, die für eine Anwendung von Process Mining auf Lieferketten Prozesse von Bedeutung sind. Wie in den vorangegangenen Kapiteln skizziert, sind die Teilaufgaben Datenaufbereitung, Prozessmodellierung und Process Mining Algorithmus zu betrachten. Die im Folgenden beschriebenen Anforderungen sind nach diesen Teilaufgaben gruppiert. Abschließend sind in Tabelle 3.1 noch einmal alle Kriterien aufgeführt, zusammen mit einer Einstufung deren Relevanz für diese Arbeit ANFORDERUNGEN AN DIE DATENAUFBEREITUNG Wie in Abschnitt dargestellt, ist es notwendig, die bestehenden Ereignisdaten für Process Mining aufzubereiten. Dafür ist ein Algorithmus zu entwickeln, welcher die Ereignisse von einem EPCIS Datenverzeichnis abruft und in ein Format konvertiert, welches von einem entsprechenden Process Mining Werkzeug verarbeitet werden kann. Folgende Anforderungen gelten in Bezug auf diesen Konvertieralgorithmus. Dat-01 Korrektheit der Konvertierung Die Konvertierung der Ereignisse soll korrekt sein. Das bedeutet, dass jede Information, welche in den konvertierten Ereignissen zu finden ist, auch in den ursprünglichen Daten existieren muss. Nur so lassen sich aus den konvertierten Daten Modelle rekonstruieren, welche die Realität widerspiegeln. 1 Die Arbeit hat nicht die Entwicklung eines Softwareproduktes zum Ziel, sondern untersucht die Anwendbarkeit von Process Mining auf eine neue Domäne. Die in diesem Kapitel aufgeführten Anforderungen weisen daher ein hohes Abstraktionsniveau auf. 39

42 Dat-02 Vollständigkeit der Konvertierung Um die Anwendbarkeit möglichst vieler verschiedener Analysemethoden auf die konvertierten Ereignisdaten zu ermöglichen, soll die Konvertierung der Ereignisse vollständig sein. Das bedeutet, dass alle Informationen erhalten bleiben müssen. Für die Verfolgung von einzelnen Produkten ist zum Beispiel nötig, dass einzelne EPCs, auf die in den EPCIS Ereignissen Bezug genommen wird, auch von den konvertierten Ereignissen referenziert werden. Dat-03 Ereignisfilterung Bei dem Abruf der Ereignisse aus dem EPCIS Datenverzeichnis ist es wünschenswert, die Menge der zu betrachtenden Ereignisse durch verschiedene Filterparameter einschränken zu können. Diese Parameter können zum Beispiel, aber nicht ausschließlich sein: Zeitfenster: Es werden nur Ereignisse betrachtet, deren Auftrittszeitpunkt im genannten Zeitfenster liegt. Produktklasse(n): Es werden nur Ereignisse betrachtet, die mit den genannten Produktklassen im Zusammenhang stehen. Unternehmen / Standort: Es werden nur Ereignisse betrachtet, die mit den genannten Unternehmen / Standorten im Zusammenhang stehen. Geschäftstransaktion: Es werden nur Ereignisse betrachtet, die mit den genannten Transaktionen im Zusammenhang stehen. Dat-04 Speicherplatz Typischerweise müssen beim Process Mining große Datenmengen verarbeitet werden. Im Hinblick auf eine effiziente Verarbeitung der Daten durch den Rechner soll auf einen moderaten Speicherplatzverbrauch der konvertierten Ereignisdaten geachtet werden. Die Verarbeitung der konvertierten Datensätze soll mit einem Standard Desktop PC möglich sein. Dat-05 Effizienz Die Laufzeit des Konvertieralgorithmus muss so gestaltet sein, dass die Verarbeitung großer Datenmengen in akzeptabler Zeitspanne erfolgen kann. Wünschenswert ist ein linearer Zeitbedarf in der Anzahl der Ereignisse. 40 Kapitel 3 Anforderungen

43 Dat-06 Fehlertoleranz Als Ausschlusskriterium gilt, dass der Konvertieralgorithmus nicht die Verarbeitung fehlerhafter Daten ermöglichen muss. Fehler in den Daten können zum Beispiel, aber nicht ausschließlich sein: Fehlerhafte EPCs Fehlende EPCs Zyklen in der Aggregationshierarchie von EPCs Fehlerhafte Zeitstempel Die Ursachen von Fehlern können schon bei der Erfassung von Produkten mittels RFID- Lesegeräten liegen, aber auch Fehler in der Verarbeitung durch die zuständige Middleware oder andere Fehlerursachen sind möglich. Darüber hinaus kann die Informationsmenge der konvertierten Ereignisse nur insoweit vollständig sein, wie die Informationen in den zu Grunde liegenden Ereignisdaten vollständig sind. 3.2 ANFORDERUNGEN AN DIE PROZESSMODELLIERUNG Durch Process Mining sollen Lieferkettenmodelle rekonstruiert werden, welche eine Reihe von Informationsaspekten darstellen. Die folgenden Anforderungen präzisieren dies. Weiterhin werden Anforderungen aufgeführt, welche die Verwendung der Modelle betreffen. Mod-01 Produktflüsse Es sollen Produktflüsse durch die Lieferkette visualisiert werden. Dabei sollen die Wege erkennbar sein, auf denen die Produkte durch die Lieferkette transportiert werden. Weiterhin soll ersichtlich sein, an welchen Lieferkettenknoten Produkte aggregiert oder transformiert werden. Die gezielte Visualisierung der Produktflüsse ausgewählter Produktklassen ist ausreichend. Mod-02 Geschäftstransaktionen Wünschenswert ist die Möglichkeit, den Verlauf von Produkten zu verfolgen, die im Zusammenhang mit bestimmten Geschäftstransaktionen stehen, was der Visualisierung eines Informationsflusses parallel zu Produktflüssen entspricht. 3.2 Anforderungen an die Prozessmodellierung 41

44 Mod-03 Gruppierung Der Modellierungsansatz muss die Gruppierung von Prozessbausteinen nach gewissen Aspekten unterstützen. Damit wird zum Einen Übersichtlichkeit erreicht, und zum Anderen gewährleistet, dass die Lieferkettenmodelle auf verschiedenen Granularitätsebenen analysiert werden können. Gruppierungsaspekte können zum Beispiel, aber nicht ausschließlich sein: Unternehmensgrenzen: Es sollen alle Prozessbausteine zusammengefasst werden, welche einem Unternehmen zugeordnet werden. Standortzugehörigkeit: Es sollen alle Prozessbausteine zusammengefasst werden, welche einem Unternehmensstandort zugeordnet werden. Produktionsschritte: Es sollen alle Prozessbausteine zusammengefasst werden, welche zu einem Produktionsschritt gehören. Die Gruppierung kann z. B. in hierarchischer Form erfolgen. Mod-04 Stereotypen Wünschenswert ist eine Möglichkeit zur Annotation von Prozessbausteinen mit Stereotypen, so dass die Bedeutung einzelner Elemente des Modells schnell erfasst werden kann. Zum Beispiel können möglicherweise durch Entdeckung von Ereignismustern verschiedene Stereotypen klassifiziert bzw. identifiziert werden, mittels derer die Bedeutung verschiedener Knotentypen in der Lieferkette beschrieben werden kann. Dies kann die Lesbarkeit eines solchen Prozessmodells beträchtlich erhöhen. Mod-05 Zeitverbrauch Um optimale Erkenntnisse aus den Modellen zu ziehen, ist es wünschenswert, wenn an geeigneten Stellen im Modell ein Zeitverbrauch angegeben werden kann, z. B. eine Transport- oder Bearbeitungsdauer. Liegt der Modellierung eine ausführbare Semantik zugrunde, sollen auch die Zeitangaben durch diese Semantik abgedeckt sein. Dadurch werden weitere Analysemethoden, wie z. B. Durchlaufzeitenberechnungen möglich. Mod-06 Interoperabilität Die Modellierung soll nicht von Grund auf eigenständig sein, sondern möglichst eine verbreitete Modellierungssprache nutzen oder zumindest eine Erweiterung einer solchen darstellen. Weiterhin ist es wünschenswert, dass das Repräsentationsformat der rekonstruierten Prozessmodelle so gewählt wird, dass bestehende Software Werkzeuge mit den Modellen arbeiten können. 42 Kapitel 3 Anforderungen

45 Mod-07 Zugang zu Analysemethoden Die rekonstruierten Modelle sollen die Anwendung bestehender oder neuer Process- Mining- und Analyse Algorithmen ermöglichen. Dazu ist es nötig, dass die Modelle die dafür notwendigen Informationen geeignet repräsentieren können. Anderenfalls soll zumindest die Möglichkeit bestehen, die rekonstruierten Modelle in ein geeigneteres Format zu konvertieren. Mod-08 Ausführbarkeit Die rekonstruierten Modelle sollen primär der Visualisierung einer Lieferkette dienen. Eine weitere mögliche Anwendung ist die Echtzeit Überwachung einer Lieferkette auf Basis der Modelle. Dafür ist es notwendig, dass den Modellen eine Ausführungssemantik zugeordnet werden kann. Wenn möglich, soll die Überwachung einzelner Produkte ermöglicht werden. Mod-09 Übersichtlichkeit Das Hauptanliegen bei der Rekonstruktion eines Lieferkettenmodells ist dessen Visualisierung. Im Vordergrund steht daher, dass die rekonstruierten Modelle übersichtlich sind. Die Modelle sollen nicht mit Informationen überladen sein. Wenn möglich, soll sich der Analyst verschiedene Aspekte des Modells selektiv anzeigen lassen können. 3.3 ANFORDERUNGEN AN DEN PROCESS MINING ALGORITHMUS Nach Aufbereitung der Ereignisdaten entsprechend den Anforderungen aus Abschnitt 3.1 können bestehende Process Mining Algorithmen angewendet werden, um einzelne Aspekte der Lieferkette zu rekonstruieren. Um optimale Erkenntnisse aus der speziellen Natur der Ereignisse zu ziehen, wurde entschieden, einen eigenen Process Mining- Algorithmus zu entwickeln. Dieser soll Modelle entsprechend den Richtlinien des vorangegangenen Abschnitts rekonstruieren. Folgende Anforderungen werden an den Algorithmus gestellt. Min-01 Korrektheit der Rekonstruktion Durch Anforderung Dat-01 wird sichergestellt, dass die Informationen der konvertierten Ereignisdaten denen der Originaldaten entsprechen. Die durch den Process Mining- Algorithmus rekonstruierten Modelle sollen in Bezug auf die (konvertierten) Ereignisse 3.3 Anforderungen an den Process Mining Algorithmus 43

46 korrekt sein. Das bedeutet, dass alle Facetten des rekonstruierten Modells durch die Daten abgedeckt sein müssen. Nur so können anhand der rekonstruieren Modelle verlässliche Aussagen getroffen werden. Min-02 Vollständigkeit der Rekonstruktion Durch Anforderung Dat-02 wird sichergestellt, dass die konvertierten Ereignisdaten die gleichen Informationen wie die Originaldaten enthalten. Um den Informationsgrad der rekonstruierten Modelle zu maximieren, ist es wünschenswert, dass diese vollständig bezüglich der Informationen der (konvertierten) Ereignisse sind. Das bedeutet, es sollen soviel Informationen wie möglich aus den Daten in die rekonstruierten Modelle umgesetzt werden. Dabei soll die Klarheit der Modelle (Anforderung Mod-09) jedoch nicht beeinträchtigt werden. Min-03 Effizienz Die Laufzeit des Algorithmus muss so gestaltet sein, dass die Verarbeitung großer Datenmengen mit einem Standard Desktop PC in akzeptabler Zeitspanne erfolgen kann. Wünschenswert ist ein linearer Zeitbedarf in der Anzahl der Ereignisse. Um die Vorteile moderner Mehrprozessorsysteme auszunutzen, ist es wünschenswert, dass der Algorithmus parallelisierbar gestaltet werden kann, d. h. in parallel zu bearbeitende Teilaufgaben geteilt werden kann. Min-04 Fehlertoleranz Die Eingabedaten für den Process Mining Algorithmus sollen in einem Format vorliegen, welches die oben genannten Anforderungen (Abschnitt 3.1) erfüllt. Als Ausschlusskriterium gilt, dass der Algorithmus nicht die Verarbeitung beliebiger Ereignisdaten ermöglichen muss. Weiterhin muss nicht die Verarbeitung fehlerhafter Eingabedaten ermöglicht werden. Fehler in den Daten können zum Beispiel, aber nicht ausschließlich sein: Übertragung von Fehlern aus dem Konvertieralgorithmus, wenn dieser auf fehlerhafte Daten angewendet wurde Fehler im Speicherformat der konvertierten Daten In Tabelle 3.1 sind zusammenfassend alle beschriebenen Anforderungen mit ihrer Wichtigkeit zusammengestellt. 44 Kapitel 3 Anforderungen

47 Tabelle 3.1: Anforderungskatalog + Musskriterium, Wunschkriterium, - Ausschlusskriterium Anforderung Kürzel Priorität Korrektheit Dat-01 + Vollständigkeit Dat-02 + Ereignisfilterung Dat-03 Speicherplatz Dat-04 Effizienz Dat-05 Fehlertoleranz Dat-06 - Produktflüsse Mod-01 + Geschäftstransaktionen Mod-02 Gruppierung Mod-03 + Stereotypen Mod-04 Zeitverbrauch Mod-05 Interoperabilität Mod-06 + Zugang zu Analysemethoden Mod-07 + Ausführbarkeit Mod-08 Übersichtlichkeit Mod-09 + Korrektheit Min-01 + Vollständigkeit Min-02 Effizienz Min-03 Fehlertoleranz Min Anforderungen an den Process Mining Algorithmus 45

48 46 Kapitel 3 Anforderungen

49 4 LÖSUNGSENTWURF In diesem Kapitel werden die entwickelten Lösungen vorgestellt. Um die Anwendung von Process Mining Techniken auf EPCIS Ereignisdaten zu ermöglichen, müssen diese in ein Format konvertiert werden, welches von entsprechenden Algorithmen verarbeitet werden kann. Diese Konvertierung wird in Kapitel 4.2 beschrieben. Darüber hinaus wird ein Process Mining Algorithmus entwickelt, welcher Modelle von Lieferketten unter Integration verschiedener Perspektiven rekonstruieren soll. Die Modellierung der Lieferkettenprozesse wird in Kapitel 4.3 entwickelt und Kapitel 4.4 beschreibt die Entwicklung des Process Mining Algorithmus. Dabei werden jeweils Lösungen vorgestellt, aber auch Überlegungen angeführt, welche diese begründen. Die Lösungsideen werden anhand von Beispielen verdeutlicht. Als Grundlage für diese dient eine Lieferkette, welche im folgenden Beispiel beschrieben wird. Der Aufbau dieser Lieferkette stützt sich auf SCOR R (Supply-Chain Operations Reference-model). SCOR ist ein Referenzmodell für Lieferketten. Es identifiziert Basisprozesse, die durch verschiedene Szenarien konfiguriert werden können [sco06]. Für das Beispiel wurde das Make to Order Szenario zugrunde gelegt. Beispiel 1 (Modellhafte Lieferkette) In Abbildung 4.1 ist ein Ausschnitt einer typischen Lieferkette aus dem Bereich der Automobilherstellung dargestellt [Str05]. Der Ausschnitt umfasst fünf Unternehmen, die in unterschiedlichen Bereichen aktiv sind. Das Unternehmen Lieferant 1 produziert Bleche. Das Unternehmen Lieferant 2 ist Hersteller von Griffen für Fahrzeugtüren. Das Unternehmen Türenhersteller verarbeitet Bleche und Griffe zu Fahrzeugtüren. Diese werden durch einen Logistikdienstleister zum Kunden Fahrzeughersteller transportiert. Das Unternehmen Türenhersteller stellt das fokale Unternehmen des betrachteten Lieferkettenausschnitts dar. Der Fertigungsprozess wird durch eingehende Kundenaufträge ausgelöst. Durch eine Reihe von Arbeitsschritten werden die Griffe und Bleche zu weißen und blauen Türen verarbeitet. Die Türen werden mittels Mehrwegverpackungen entsprechend den Kundenaufträgen verpackt und in den Versand gegeben. 47

50 Abbildung 4.1: Beispiel Lieferkette 4.1 SOFTWAREAUSWAHL Der zu entwickelnde Process Mining Ansatz soll keine einzelstehende Lösung sein. Vielmehr wird durch die Anforderungen Mod-06 (Interoperabilität) und Mod-07 (Zugang zu Analysemethoden) die Nutzung bestehender Software verlangt. Dabei fiel die Wahl auf die Software ProM, welche in Abschnitt bereits kurz beschrieben wurde. Diese Wahl beeinflusst die Art, wie die Ereignisse aufbereitet werden müssen. Der folgende Abschnitt beschreibt die Konvertierung der zur Verfügung stehenden Ereignisdaten in das von ProM verwendete MXML Format. 4.2 KONVERTIERUNG DER EREIGNISSE Bei der Konvertierung von EPCIS Ereignissen in das MXML Format sind zwei Teilaufgaben zu lösen. Zum Einen muss eine Abbildung zwischen den Ereignisattributen der beiden Formate gefunden werden. Zum Anderen müssen Ereignisse zu Prozessinstanzen gruppiert werden, welche wiederum zu Prozessen gruppiert werden. In der Folge wird auf beide Teilaufgaben einzeln eingegangen Ereignisattribute Ereignisse des MXML Formats tragen Attribute, welche spezielle Informationen aufnehmen, die für Process Mining wichtig sind (siehe Abbildung 2.3). Attribute von EPCIS- Ereignissen beschreiben den Kontext von Produktbeobachtungen (siehe Abbildung 2.2). Manche dieser Attribute lassen sich intuitiv für Process Mining verwenden, d. h. auf MXML Attribute abbilden. Für andere Attribute sind weitere Überlegungen erforderlich, welche im Folgenden beschrieben sind. Abbildung 4.2 stellt die gefundene Attributabbildung dar. Am Ende des Abschnitts wird diese nochmal anhand von Beispiel 4 verdeutlicht. 48 Kapitel 4 Lösungsentwurf

51 EPCIS - Attribute eventclass action readpoint epclist parentid childepcs bizstep disposition biztranslist bizlocation eventtime eventtype workflowmodelelement data originator timestamp MXML - Attribute Abbildung 4.2: Abbildung der Ereignis Attribute Attribut workflowmodelelement Das MXML Ereignisattribut workflowmodelelement repräsentiert die Aktivität, durch die ein Ereignis ausgelöst wurde. Die Wahl dieses Attributs hat den größten Einfluss auf die Rekonstruktion durch Process Mining Algorithmen. Die im Folgenden diskutierten Alternativen sind unter dem Gesichtspunkt zu betrachten, dass primär der Aufbau der Lieferkette und die Flüsse der Produkte zwischen den Lieferkettenknoten rekonstruiert werden sollen. 1. Das EPCIS Attribut bizstep wird verwendet. Dieses Attribut gibt den Geschäftsschritt an, in welchem das Ereignis ausgelöst wurde. Diese Wahl dient primär der Rekonstruktion von Workflows. Durch die Zuordnung von Ereignissen verschiedener Vorgänge eines Geschäftsschrittes zu einer Aktivität kann ein Informationsverlust auftreten. In der Lieferkette aus Beispiel 1 können alle Vorgänge aus der Türenfertigung durch den Geschäftsschritt Produktion modelliert werden. Wird das Process Mining nur auf Basis des Geschäftsschrittes durchgeführt, gehen die Informationen über verschiedene Produktionsstrecken verloren. 2. Das EPCIS Attribut bizlocation wird verwendet. Dieses Attribut gibt das Unternehmen bzw. den Unternehmensteil an, in welchem das Ereignis ausgelöst wurde. Diese Wahl ist nützlich, um einen groben Überblick zu bekommen, welche Ereignisse in welchen (räumlichen) Teilen der Lieferkette auftreten. Der Detailgrad des Attributes bizlocation entzieht sich jedoch dem betrachteten Einflussbereich. Daher können innerhalb einer Ortsangabe mehrere Vorgänge stattfinden, so dass analog zu 1. eine Informationsverwischung auftritt. 3. Das EPCIS Attribut readpoint wird verwendet. Dieses Attribut gibt den (RFID-) Lesepunkt an, an welchem das Ereignis ausgelöst wurde. Unter der Annahme, dass der Wert dieses Attributs den Lesepunkt eindeutig bezeichnet, bietet diese Wahl die detaillierteste Information über den Ort der Auslösung des Ereignisses. 1 1 Die getroffene Annahme basiert auf der möglichen, und vom EPCIS Standard empfohlenen Verwendung von logischen Identifikatoren für Lesepunkte statt physischen Identifikatoren. Ohne diese Annahme ist denkbar, dass das Attribut readpoint eine unpräzise Beschreibung des Lesepunktes ist ([epc07], S. 33). 4.2 Konvertierung der Ereignisse 49

52 Alle in Betracht gezogenen Attribute sind für alle EPCIS Ereignistypen optional. Daher muss der Algorithmus zum Konvertieren der Ereignisse dynamisch die Existenz dieser Attribute prüfen und nötigenfalls eine suboptimale Wahl für das Attribut workflowmodel- Element treffen. Um Informationen über Produktflüsse bei der Rekonstruktion zu berücksichtigen, ist es nötig, das Attribut workflowmodelelement um diese Informationen zu erweitern. 2 Aufgrund verschiedener Überlegungen muss dies variabel gestaltet werden. Zum Einen kann ein Modell durch zu viele Informationen unübersichtlich werden. Zum Anderen kann beim Austausch von Daten zwischen Unternehmen die Anonymisierung bestimmter Informationen gefordert werden. Für diese Arbeit wird daher eine dreistufige Granularität bezüglich der Produktklassen eingeführt, welche bei der Konvertierung ausgewählt werden kann. fein mittel grob Es werden die Informationen über die Produktklassen verwendet, welche im Kontext des EPCIS Ereignisses auftreten. Es wird die Information über die EPC Typen der Produkte verwendet, welche im Kontext des EPCIS Ereignisses auftreten. Es werden keine produktbezogenen Informationen verwendet. Anhand eines Beispiels soll diese Auswahlmöglichkeit verdeutlicht werden. Beispiel 2 (Granularität) Ein Objektereignis, welches aus der Lieferkette aus Beispiel 1 stammen kann, hat u. a. die folgenden Attribute: readpoint epclist = urn:produktion:montage = urn:epc:id:sgtin: Unterschiedliche Granularitätsstufen bei der Konvertierung resultieren in unterschiedlichen Ausprägungen des Attributes workflowmodelelement. fein mittel grob readpoint:urn:produktion:montage prodclass:sgtin: readpoint:urn:produktion:montage epctype:sgtin readpoint:urn:produktion:montage Zu beachten ist, dass durch eine gröbere Granularität bei der Konvertierung eine Informationsverwischung auftritt. Ein Process Mining Algorithmus, welcher keine weiteren Informationen hat, kann diese nicht wieder auflösen. 2 Die Möglichkeit, diese Informationen durch spezifische Erweiterungen des MXML Formats abzubilden, ist im Allgemeinen nicht ausreichend, da nicht davon ausgegangen werden kann, dass bestehende Process- Mining Algorithmen diese Erweiterungen verarbeiten. 50 Kapitel 4 Lösungsentwurf

53 Attribut eventtype Wie in Abschnitt beschrieben, spezifiziert der EPCIS Standard vier Ereignisklassen. Wegen Anforderung Mod-01 (Produktflüsse) sind die Objektereignisse unverzichtbar für das Process Mining. Die Aggregationsereignisse liefern wertvolle zusätzliche Informationen über Aggregationsstrukturen und sind daher ebenfalls für die Rekonstruktion der Produktflüsse zu verwenden. Um die Rekonstruktion von Produktflüssen mit Geschäftsaspekten zu verbinden, sind die Transaktionsereignisse wichtig. Eine untergeordnete Bedeutung für das Process Mining spielen die Quantitätsereignisse. Diese erbringen keine wertvollen Informationen bezüglich der Anforderungen, da kein Bezug zum Lebenszyklus von Produkten hergestellt werden kann. Daher werden bei der Konvertierung nur die drei erstgenannten Ereignisklassen berücksichtigt. Das Zielformat MXML spezifiziert nur eine Ereignisklasse: AuditTrailEntry. Der Ereignistyp wird durch das Ereignisattribut eventtype angegeben. Dafür können vordefinierte Aktivitätszustände verwendet werden, z. B. schedule, start oder complete [vv05a]. Alternativ erlaubt das MXML Format die Angabe benutzerdefinierter Ereignistypen. Die Verwendung von Aktivitätszuständen macht nur unter der Annahme Sinn, dass eine Aktivität durch mehrere Ereignisse protokolliert wird. Bei der Verwendung von EPCIS Ereignissen ist diese Annahme nicht gerechtfertigt. Bei der Konvertierung von EPCIS Ereignissen werden benutzerdefinierte Ereignistypen verwendet. Diese werden durch eine Kombination aus EPCIS Ereignisklasse (Object- Event, AggregationEvent, etc.) und angegebener Aktion (ADD, DELETE, OBSERVE) gebildet. Diese Kombination drückt den Großteil der Semantik eines EPCIS Ereignisses aus. Beispiel 3 (Ereignistyp) Ein Objektereignis mit dem Attribut action = ADD wird konvertiert in ein MXML Ereignis mit dem Attribut eventtype = ObjectADD. Ein Aggregationsereignis mit dem Attribut action = OBSERVE wird konvertiert in ein MXML- Ereignis mit dem Attribut eventtype = AggregationOBSERVE. Ein Transaktionsereignis mit dem Attribut action = DELETE wird konvertiert in ein MXML- Ereignis mit dem Attribut eventtype = TransactionDELETE. Optionale Attribute Die MXML Attribute originator, timestamp und data sind optional. In der vorliegenden Lösung werden alle verwendet. Das Attribut originator, welches für die Rekonstruktion von Organisationsaspekten verwendet wird, erhält durch die Abbildung den Wert des EPCIS- Attributes bizlocation, insofern dieses angegeben wurde. Dies entspricht der Intuition, dass ein Unternehmen bzw. Unternehmensteil der Auslöser des Ereignisses ist. Der Zeitpunkt des Auftretens des EPCIS Ereignisses (eventtime) wird abgebildet auf das Attribut timestamp für MXML Ereignisse. 4.2 Konvertierung der Ereignisse 51

54 Das Ereignisattribut data ist für spezifische Erweiterungen des MXML Formats vorgesehen, wobei nicht spezifiziert ist, in welcher Weise Process Mining Algorithmen dieses Attribut verarbeiten. Attribute der EPCIS Ereignisse, welche im MXML Format keine Entsprechung haben, ebenso wie EPCIS Erweiterungsattribute, werden auf das Attribut data abgebildet. Der zu entwickelnde Process Mining Algorithmus wird sich hauptsächlich auf die Informationen aus diesem Attribut stützen. Anhand des folgenden Beispiels soll die Abbildung noch einmal verdeutlicht werden. Beispiel 4 (Abbildung) Ein Aggregationsereignis, welches aus der in Beispiel 1 beschriebenen Lieferkette stammen kann, hat die folgenden Attribute: action = ADD parentid = urn:epc:id:sscc: childepcs = urn:epc:id:sgtin: urn:epc:id:sgtin: bizlocation = urn:epc:id:sgln: bizstep = urn:epcglobal:bizstep:packing readpoint = urn:verpackung:station1 eventtime = :43:34 Wird das Ereignis bei feiner Granularität in das MXML Format konvertiert, stellt sich das Resultat in XML Repräsentation wie in Abbildung 4.3 dar. <AuditTrailEntry> <Data> <Attribute name= "parentid" > urn:epc:id:sscc: </Attribute> <Attribute name= "childepcs" > urn:epc:id:sgtin: urn:epc:id:sgtin: </Attribute> <Attribute name= "bizloc" > urn:epc:id:sgln: </Attribute> <Attribute name= "bizstep" > urn:epcglobal:bizstep:packing</attribute> <Attribute name= "readpoint" > urn:verpackung:station1</attribute> </Data> <WorkflowModelElement> readpoint:urn:verpackung:station1 prodclass:sscc: </WorkflowModelElement> <EventType unknowntype= "AggregationADD" > unknown</eventtype> <Timestamp> T21:43: :00 </Timestamp> <Originator> urn:epc:id:sgln: </Originator> </AuditTrailEntry> Abbildung 4.3: Beispielereignis im MXML Format 52 Kapitel 4 Lösungsentwurf

55 4.2.2 Zuordnung zu Prozessinstanzen Nachdem eine Abbildung der Ereignisattribute vom EPCIS Format in das MXML Format gefunden wurde, ist die wesentlich schwierigere Aufgabe die Zuordnung der Ereignisse zu Prozessinstanzen. Manche Informationssysteme erweitern Ereignisse bereits bei deren Protokollierung mit einem Fallidentifikator. Die EPCIS Ereignisse besitzen einen solchen nicht. Die Gruppierung zu Prozessen und Prozessinstanzen muss daher auf andere Weise erfolgen. Es gibt verschiedene Strategien für diese Gruppierung. Deren Wahl beeinflusst die Ergebnisse der Process Mining Algorithmen entscheidend. Im Folgenden sind verschiedene Strategien und deren erwarteter Einfluss auf das Mining Ergebnis beschrieben. Strategie 1: Eine Prozessinstanz umfasst alle Ereignisse, die an einem bestimmten Lesepunkt aufgetreten sind. Alle Prozessinstanzen werden einem Prozess zugeordnet. Vorteile: Die Ereignisse werden zu den Lesepunkten zugeordnet, an dem sie aufgetreten sind. Dadurch werden die an den Lesepunkten auftretenden Teilprozesse rekonstruierbar. Nachteile: Durch Vermischung von Ereignissen, die sich auf unterschiedliche Produkte beziehen, werden die Ergebnisse verfälscht. Zum Beispiel wird eine Folge von Ereignissen rekonstruiert, auch wenn nur ein Ereignis pro Produkt und Lesepunkt auftritt. Strategie 2: Eine Prozessinstanz umfasst alle Ereignisse, die an einem bestimmten Lesepunkt aufgetreten sind und einen bestimmten EPC betreffen. Alle Prozessinstanzen werden einem Prozess zugeordnet. Vorteile: Entspricht einer Verbesserung der ersten Strategie. Es findet keine Vermischung von Ereignissen statt, die sich auf unterschiedliche Produkte beziehen. Die Teilprozesse an den einzelnen Lesepunkten sind rekonstruierbar. Nachteile: Die Menge der Prozessinstanzen teilt sich in disjunkte Gruppen von Ereignissen, die jeweils nur einem Lesepunkt zugeordnet sind. Daher sind zwischen den einzelnen Lesepunkten keine Zusammenhänge reproduzierbar. Es können also keine Produktflüsse rekonstruiert werden. Strategie 3: Wie Strategie 2, allerdings werden die Prozessinstanzen auf verschiedene Prozesse aufgeteilt. Ein Prozess umfasst alle Prozessinstanzen, die Ereignisse eines bestimmten Lesepunktes umfassen. Vorteile: Im Process Mining Werkzeug ProM ist durch einen Filter selektierbar, welche Prozesse betrachtet werden sollen. Dadurch wird es möglich, gezielt den Teilprozess an einem bestimmten Lesepunkt zu rekonstruieren. Nachteile: Wie bei Strategie Konvertierung der Ereignisse 53

56 Strategie 4: Eine Prozessinstanz umfasst alle Ereignisse, die einen bestimmten EPC betreffen. Vorteile: Durch die Zuordnung von Ereignissen zu Produkten können Teile des Lebenszyklusses der Produkte rekonstruiert werden. Teilweise können dadurch Produktflüsse zwischen unterschiedlichen Lesepunkten sichtbar gemacht werden. Nachteile: Der Lebenszyklus eines Produktes kann auch Transformationsschritte sowie Aggregationsschritte umfassen. Der EPC eines Produktes kann sich daher während des Produktlebenszyklusses ändern. Die Strategie stellt keine Verbindungen zwischen EPCs her. Strategie 5: Eine Prozessinstanz umfasst alle Ereignisse, die innerhalb des Lebenszyklusses eines Produktes mit einem bestimmten EPC auftreten. Vorteile: Baut auf Strategie 4 auf. Es werden Verbindungen zwischen EPCs hergestellt, die im Lebenszyklus eines Produktes auftreten. Dadurch kann der Lebenszyklus der Produkte rekonstruiert werden und es kann lückenlose Produktverfolgung garantiert werden. Nachteile: Manche Ereignisse werden zu mehreren Prozessinstanzen zugeordnet. Die dadurch hinzugefügte Redundanz vergrößert die Datenmenge, welche der Process Mining Algorithmus verarbeiten muss. Strategie 6: Wie Strategie 5, allerdings werden die Prozessinstanzen auf verschiedene Prozesse aufgeteilt. Ein Prozess umfasst alle Prozessinstanzen, die Ereignisse einer bestimmten Produktklasse umfassen. Vorteile: Zusätzlich zu den Vorteilen der Strategie 5 gilt, dass durch die Filter im Process Mining Werkzeug ProM gezielt der Lebenszyklus von Produkten einer bestimmten Produktklasse rekonstruiert werden kann. Nachteile: Wie bei Strategie 5. Die Strategie 1 ist durch den genannten Nachteil nicht direkt anwendbar. Die Strategie 2 bzw. 3 ist eventuell nützlich, um im Hinblick auf spätere Gruppierung im Mining Modell die Teilprozesse an den Lieferkettenknoten zu rekonstruieren. Bei Verwendung von Strategie 4 sind die erwarteten Rekonstruktionsergebnisse aufgrund des genannten Nachteiles im Hinblick auf Produktverfolgung nur von geringem Wert. Die Strategie 5 bzw. 6 bietet die besten Voraussetzungen für die Rekonstruktion von Produktflüssen durch einen Process Mining Algorithmus. Umgesetzt wurde Strategie 6. Die genaue Zuordnung der Ereignisse zu einem Produktlebenszyklus stellt keine triviale Aufgabe dar. Der Algorithmus hierfür ist im folgenden Abschnitt beschrieben. Algorithmus zur Fallkonstruktion In diesem Abschnitt wird der Algorithmus EPCTrack beschrieben, welcher von Strategie 5 bzw. 6 zur Fallzuordnung verwendet wird. Die Schwierigkeit beim Finden aller Ereignisse 54 Kapitel 4 Lösungsentwurf

57 Mehrwegverpackung Blaue Tür Blaues Blech Blech Transformation Aggregation Aggregation Disaggregation Abbildung 4.4: Fokusverschiebung am Beispiel im Lebenszyklus eines Produktes besteht in einem Problem, das im Folgenden Fokusverschiebung genannt wird. Im Allgemeinen ist davon auszugehen, dass Ereignisse nur im Kontext elektronischer Produktcodes generiert werden, welche im Fokus liegen. Dieser Fokus verändert sich durch Aggregation und Transformation der Produkte. Definition 1 (Aggregation) Unter Aggregation versteht man das Zusammenfassen mehrerer gleichartiger oder verschiedenartiger Produkte zu einem Verbund. Dieser Verbund wird Aggregat genannt. Typischerweise trägt auch das Aggregat einen elektronischen Produktcode. Die Umkehrung der Aggregation, also das Aufbrechen eines Aggregates in die enthaltenen Bestandteile wird Disaggregation genannt. Durch eine Aggregation verschiebt sich der Fokus auf den EPC des Aggregates. Erst durch eine Disaggregation wird der Fokus wieder zurück auf den EPC der enthaltenen Produkte verlagert. Definition 2 (Transformation) Unter einer Transformation versteht man das Umwandeln eines (Ausgangs-) Produktes in ein oder mehrere andere (End-) Produkte. Die Endprodukte tragen einen anderen elektronischen Produktcode als das Ausgangsprodukt. Bei einer Transformation verschiebt sich der Fokus dauerhaft vom EPC des Ausgangsproduktes zu den EPCs der Endprodukte. Beispiel 5 (Fokusverschiebung) In der Lieferkette aus Beispiel 1 werden durch den Türenhersteller mehrere Türen mittels Mehrwegverpackungen verpackt. Dies stellt eine Aggregation dar. Der Fokus verschiebt sich bis zum Entpacken auf Kundenseite zum EPC der Mehrwegverpackung. Für die einzelnen Türen werden auf dem Transportweg keine Ereignisse generiert. Im Bereich Produktion des Türenherstellers werden die angelieferten Bleche in verschiedenen Farben lackiert. Ein solcher Veredelungsschritt ist eine Transformation. Die lackierten Bleche tragen einen anderen EPC, welcher ab sofort im Fokus liegt. Abbildung 4.4 stellt die Fokusverschiebung dar. Die fette Linie deutet an, welches Produkt gerade im Fokus liegt. 4.2 Konvertierung der Ereignisse 55

58 Durch diese Fokusverschiebungen entstehen Lücken im Lebenszyklus eines Produktes, wenn nur der EPC des Produktes betrachtet wird. Der Algorithmus EPCTrack versucht diese Lücken zu schließen, indem auf Basis der Ereignisse die Fokusverschiebungen nachvollzogen werden. Der Kerngedanke ist, dass Ereignisse, welche im Kontext eines Produktes p auftreten, auch im Kontext aller Produkte geschehen, die durch Aggregation oder Transformation in das Produkt p überführt wurden. Der Algorithmus basiert auf folgenden Annahmen: Die Ereignisse liegen geordnet nach dem Zeitpunkt ihres Auftretens vor. Da die Beziehungen zwischen den EPCs auf physischen Beziehungen zwischen den Produkten basieren, gewährleistet diese Annahme, dass die Produktcodes in ihrer kausalen Abfolge auftreten. Objektereignisse mit action = ADD, die durch einen Transformationsschritt generiert wurden, enthalten ein Attribut sourceepc, welches den EPC des Ausgangsproduktes des Transformationsschrittes angibt. 3 Dies ist durch ein Erweiterungsattribut realisierbar (siehe Abschnitt 2.1.4). In Listing 4.1 ist der Algorithmus EPCTrack in Pseudocode dargestellt. Die Funktionsweise wird im Folgenden verdeutlicht. Der Algorithmus liest EPCIS Ereignisse in chronologischer Reihenfolge ein. Dabei werden die Abhängigkeiten zwischen den EPCs in einem Graphen verwaltet. Jeder in einem Ereignis auftretende EPC entspricht einem Knoten des Graphen. Entsprechend der Zuordnungsstrategie identifiziert jeder EPC, d. h. jeder Knoten eine Prozessinstanz. Von einem Knoten epc 1 wird eine Kante zu einem Knoten epc 2 genau dann aufgebaut, wenn der EPC epc 1 abhängig vom EPC epc 2 ist. Dies ist genau dann der Fall, wenn das Produkt mit dem EPC epc 1 durch Aggregation oder Transformation aus dem EPC epc 2 hervorgegangen ist. Kennzeichnet ein Ereignis eine Disaggregation, so endet auch die Abhängigkeit der betreffenden EPCs nach diesem Ereignis und die entsprechende Kante wird wieder entfernt. Jedes Ereignis, welches eine Veränderung in der Abhängigkeitsstruktur protokolliert, forciert die Aktualisierung der Struktur des Graphen. Aufgrund der physischen Natur von Aggregations- und Transformationsschritten ergibt sich, dass der Graph zu jedem Zeitpunkt die Struktur eines Waldes hat, also einer ungeordneten Menge von Bäumen. Die Aktualisierung der Graphstruktur geschieht durch die Funktionen addchildren und removechildren z. B. in den Zeilen 18 und 22. Jedes Ereignis e, welches im Zusammenhang mit einem EPC epc auftritt, wird dem Knoten epc zugeordnet. Dies geschieht durch die Funktion addevent, z. B. in Zeile 12. Gleichzeitig wird das Ereignis durch den entsprechenden Baum propagiert, so dass das Ereignis e auch allen Knoten in dem Teilbaum zugeordnet wird, der seine Wurzel im Knoten epc hat. Dieses Propagieren geschieht durch die Funktion propagatetodescendants wie z. B. in Zeile Ohne diese Annahme können Transformationsschritte nicht nachvollzogen werden. 56 Kapitel 4 Lösungsentwurf

59 Listing 4.1: Algorithmus EPCTrack 1 INPUT : events c h r o n o l o g i c a l ordered EPCIS Events 2 OUTPUT: cases map from EPCs t o s e t s o f events 3 4 FOR EACH Event e IN events 5 IF e. isobjectevent THEN 6 I F e. isaddobject with sourceepc THEN 7 FOR EACH EPC epc IN e. EPCList 8 graph. addchildren ( epc, sourceepc ) 9 END FOR 10 END IF 11 FOR EACH EPC epc IN e. EPCList 12 graph. addevent ( epc, e ) 13 graph. propagatetodescendants ( epc, e ) 14 END FOR 15 ELSE IF e. isaggregationevent THEN 16 graph. addevent ( e. ParentEPC, e ) 17 IF e. isaddaggregation THEN 18 graph. addchildren ( e. ParentEPC, e. ChildEPCs ) 19 graph. propagatetodescendants ( e. ParentEPC, e ) 20 ELSE IF e. isdeleteaggregation THEN 21 graph. propagatetodescendants ( e. ParentEPC, e ) 22 graph. removechildren ( e. ParentEPC, e. ChildEPCs ) 23 END IF 24 ELSE IF e. i s T r a n s a c t i o n E v e n t THEN 25 graph. addevent ( e. ParentEPC, e ) 26 graph. propagatetodescendants ( e. ParentEPC, e ) 27 FOR EACH EPC epc IN e. EPCList 28 graph. addevent ( epc, e ) 29 graph. propagatetodescendants ( epc, e ) 30 END FOR 31 END IF 32 END FOR 33 cases = graph. nodes MXML Generierung Nach dem Aufruf des Algorithmus EPCTrack sind alle EPCIS Ereignisse einem oder mehreren elektronischen Produktcodes zugeordnet. Entsprechend der gewählten Fallzuordnungsstrategie entspricht jeder EPC einer Prozessinstanz. Um ein Ereignisprotokoll im MXML Format zu erhalten, müssen noch zwei Schritte ausgeführt werden. 1. Umwandlung eines jeden EPCIS Ereignisses in ein MXML Ereignis durch Anwendung der in Abschnitt beschriebenen Abbildung. 2. Zuordnung der Prozessinstanzen zu Prozessen. 4.2 Konvertierung der Ereignisse 57

60 Der erste Schritt wurde in der vorliegenden Lösung mit dem Algorithmus EPCTrack verzahnt. Dazu wurden die Funktionen addevent bzw. propagatetodescendants angepasst. Für den zweiten Schritt wird zu jedem EPC die Produktklasse bestimmt. Für jede dieser Produktklassen wird ein Prozess erstellt. Jede Prozessinstanz wird entsprechend des zugeordneten EPC dem Prozess hinzugefügt, welcher die Produktklasse des EPC repräsentiert. Die Menge aller Prozesse wird zusammengefasst zu einem MXML Ereignisprotokoll. Der gesamte Algorithmus zur Umwandlung der EPCIS Ereignisse in das MXML Format wird im weiteren Verlauf der Arbeit als EPCIS2MXML bezeichnet. Der Algorithmus als notwendige Vorverarbeitung für Process Mining von EPCIS Ereignissen wurde in [GCM09] veröffentlicht Diskussion Der Algorithmus EPCIS2MXML schließt die Lücken im Lebenszyklus der Produkte und bietet damit optimale Voraussetzungen für die Rekonstruktion korrekter Prozessmodelle. Jedoch birgt der Algorithmus einen Nachteil. Durch das Propagieren von Ereignissen durch den Abhängigkeitsgraphen wird ein im Voraus nicht zu bestimmender Anteil an Redundanz zu den Daten hinzugefügt. In Abhängigkeit der Komplexität der Lieferkette, d. h. der Länge der Pfade als auch des Verzweigungsgrades durch Aggregationen, werden Ereignisse unterschiedlich oft kopiert. Weiterhin werden Ereignisse dupliziert, wenn sie im Kontext mehrerer EPCs auftreten. Dieser Aspekt wird nicht weiter berücksichtigt, da der Fokus der Arbeit auf einer prototypischen Gesamtlösung liegt. Allerdings sind hier Möglichkeiten zur Lösung des Problems skizziert, die betrachtet werden können. Variation des Algorithmus EPCTrack: Die Funktion propagatetodescendants kann verändert werden, so dass die Ereignisse nicht durch den gesamten Baum propagiert werden, sondern nur zu den direkten Nachfolgern eines Knotens. Dies entspricht den Verbindungsereignissen zwischen EPCs. Es ist zu untersuchen, inwiefern diese Modifikation das Mining Ergebnis verändert. Gruppieren in ähnliche Prozessinstanzen: Es ist davon auszugehen, dass viele Prozessinstanzen ähnliche Ereignissequenzen aufweisen. Das bedeutet, dass die Reihenfolge der Lesepunkte bei vielen Prozessinstanzen (Produkten) gleich ist. Eine Gruppierung zu Prozessinstanzen gleicher Lesepunkt Reihenfolge kann die Anzahl der Prozessinstanzen und damit den Speicherverbrauch drastisch senken. Allerdings gehen bei einer solchen Gruppierung Informationen verloren, z. B. individuelle EPCs, Zeitstempel und damit auch Zeitintervalle, welche angemessen aggregiert werden müssen. Weiterhin kann eine Gruppierung erst nach vollständiger Konvertierung des Datensatzes gestartet werden. 4 Dadurch sinkt zwar der 4 Ohne das Nachvollziehen der Fokusverschiebungen kann nicht erkannt werden, welches das letzte Ereignis einer Prozessinstanz ist. Dadurch müssen erst alle Ereignisse verarbeitet werden. 58 Kapitel 4 Lösungsentwurf

61 Speicherplatzverbrauch der resultierenden Datei, nicht aber während der Konvertierung. Verwendung eines alternativen Ereignisformates: Im MXML Format definiert sich eine Prozessinstanz nur durch die Ereignisse, die innerhalb dieser Prozessinstanz aufgeführt sind. Dadurch ist es ohne Redundanz nicht möglich, ein Ereignis verschiedenen Produkten (Prozessinstanzen) zuzuordnen. Durch Definition eines Ereignisformates mit der Möglichkeit, ein Ereignis mehreren Prozessinstanzen zuordnen zu können, kann das Problem gelöst werden. Inwiefern ein solches Format für andere Process Mining Ansätze sinnvoll ist, bleibt zu untersuchen. 4.3 PROZESSMODELLIERUNG Für die Modellierung von Prozessen stehen, wie in Abschnitt 2.3 beschrieben, verschiedene Ansätze zur Verfügung, die alle unterschiedliche Vor- und Nachteile haben. Im Hinblick auf die in Abschnitt 3.2 beschriebenen Anforderungen wurden als Modellierungssprache für rekonstruierte Lieferkettenprozesse zeitbehaftete hierarchische gefärbte Petri Netze gewählt. Aufgrund der in Abschnitt 3.2 aufgeführten Anforderungen umfasst die vorliegende Lösung zur Modellierung von Lieferkettenprozessen verschiedene Aspekte. Die folgenden Abschnitte gehen einzeln auf diese ein. Teile der Lösung sind im Hinblick auf die Rekonstruierbarkeit durch einen Process Mining Algorithmus entworfen Darstellung der Elemente der Lieferkette Um Prozesselemente auf Elemente von Petri Netzen abzubilden, gibt es im Allgemeinen die Wahl zwischen der Abbildung auf Plätze, Transitionen und Kanten. Die zu modellierenden Elemente der Lieferkette sind die einzelnen Knoten der Lieferkette sowie die Verbindungen bzw. Transportwege zwischen diesen. Sowohl für Lieferkettenknoten als auch für Transportwege wird jeweils geprüft, welche Petri Netzelemente die geeignetste Wahl darstellen. Durch Beispiele wird die gefundene Modellierung verdeutlicht. Knoten der Lieferkette Die einzelnen Knoten einer Lieferkette sind aktive Einheiten, die Produkttransformationen durchführen. Im einfachsten Falle ist eine solche Transformation nur das Durchreichen von Produkten, wobei die Beobachtung über die Produkte notiert wird. Andere Arten der Transformation sind zum Beispiel das Zusammenpacken von verschiedenen Produkten zu einem Aggregat, das Umwandeln von einem Produkt in ein anderes, das Zusammenbauen von verschiedenen Produkten zu einem neuen Produkt, das Erzeugen vieler 4.3 Prozessmodellierung 59

62 Produkte aus einem Ausgangsprodukt, etc. Führt ein Knoten genau eine Art Produkttransformation durch, existiert eine Transformationsregel, die das Verhalten des Knotens widerspiegelt. Eine Produkttransformation an einem Knoten kann Zeit verbrauchen, die als Bearbeitungsdauer bezeichnet wird. Beispiel 6 (Lieferkettenknoten) In der Lieferkette aus Beispiel 1 wird der Knoten Montage der Abteilung Produktion des Türenherstellers betrachtet. Hier werden je ein Griff und ein blaues Blech zu einer blauen Tür verarbeitet. Die Transformationsregel lautet also 1 Griff + 1 Blaues Blech 1 Blaue Tür. Die Bearbeitungsdauer am Knoten Montage beträgt zwei Minuten. Kanten in einem Petri Netz stellen als Verbindungselemente keine Entsprechung für Lieferkettenknoten dar. Die Plätze eines Petri Netzes sind in gewisser Weise die passiven Elemente. Weiterhin ist im Rahmen der gefärbten Petri Netze keine sinnvolle Modellierung durch Plätze zu erwarten, die eine Transformation zwischen verschiedenen Produktklassen ausdrücken kann. Dadurch bleibt die intuitivste Möglichkeit übrig: Ein Knoten der Lieferkette wird durch eine Transition im Petri Netz dargestellt. Der Bezeichner der Transition ist der Bezeichner des Knotens. Die Plätze im Vorbereich der Transition nehmen die Eingabeprodukte für die Transformation auf. Der Nachbereich der Transition umfasst Plätze, welche die Ausgabeprodukte für die Transformation aufnehmen. Durch Nutzung des Typkonzeptes der gefärbten Netze wird pro Produktklasse ein eigener Platz bereitgestellt. Die Kanten zwischen der Transition und den umgebenden Plätzen tragen Kantenausdrücke, die zusammen die Transformationsregel angeben. Die Transition kann mit einem Zeitverbrauch annotiert werden, der die Bearbeitungsdauer an dem durch die Transition repräsentierten Knoten angibt. Abbildung 4.5 zeigt unter anderem die Modellierung des Knotens Montage aus Beispiel 6. Die Zeitangabe für die Bearbeitungsdauer ist in Sekunden angegeben und an die Transition annotiert. Es ist erkennbar, dass die im Beispiel angegebene Transformationsregel auf die umliegenden Kanten verteilt annotiert wurde. Die weiteren Elemente der Abbildung werden auf den folgenden Seiten erläutert. Transportwege Weiterhin sind die Verbindungen bzw. Transportwege zwischen den Knoten der Lieferkette darzustellen. Eine solcher Transportweg verbindet genau zwei Knoten der Lieferkette. Auf einem Transportweg können nur bestimmte Produktklassen transportiert werden. Der Transport über einen Transportweg kann Zeit verbrauchen, die als Transportdauer bezeichnet wird. Beispiel 7 (Transportweg) In der Lieferkette aus Beispiel 1 werden in der Produktionsabteilung des Türenherstellers am Knoten Lackierung blaue Bleche produziert. Diese werden für die weitere Verarbeitung zum Knoten Montage transportiert. Die Transportdauer beträgt fünf Minuten. 60 Kapitel 4 Lösungsentwurf

63 Bleche 1`Blaues_Blech Lackierung 1`Blaues_Blech 1`Blaues_Blech Montage 1`Blaue_Tuer Blaue_Bleche 1`Griff Blaue_Tueren Griffe Abbildung 4.5: Modellierungsbeispiele Mittels Kanten ist eine intuitive und konsistente Modellierung der Transportwege nicht möglich. Durch die Bipartitheit von Petri Netzen muss zwischen je zwei Transitionen ein Platz liegen. Daher können Verbindungen zwischen den Knoten durch Kanten nur umständlich unter Zuhilfenahme zusätzlicher Elemente oder durch Streichen bestimmter Elemente modelliert werden. Um eine Wahl zwischen Plätzen und Transitionen als Modellierungselemente für Transportwege zu treffen, sind weitere Überlegungen nötig: Transportwege werden durch Plätze dargestellt Intuition: Produkte liegen passiv auf einem Platz bis zur nächsten Verarbeitung. Die als Transitionen modellierten Lieferkettenknoten können sehr kompakt hintereinandergeschaltet werden. Der Zeitverbrauch für den Transport muss am Platz modelliert werden. Dies ist ohne Erweiterung der Syntax und Semantik von gefärbten Petri Netzen nicht möglich. Durch die Aufspaltung von verschiedenen Produktklassen auf verschiedene Plätze werden grundsätzlich für verschiedene Produktklassen immer verschiedene Transportwege modelliert. Dies muss nicht der Realität entsprechen. Es ist bei dieser Wahl nicht ersichtlich, wenn Produkte verschiedener Produktklassen zusammen auf einen Transportweg gebracht werden. Die Modellierung verschiedener Transportwege für eine Produktklasse (z. B. Bahn, LKW) unter Erhaltung einer sinnvollen Semantik ist schwierig. 4.3 Prozessmodellierung 61

64 Transportwege werden durch Transitionen dargestellt Intuition: Der Transport von Produkten ist ein aktiver Vorgang, der Produkte zwischen dem Ausgabepuffer des vorhergehenden Transformationsknotens zum Eingabepuffer des nachfolgenden Transformationsknotens bewegt. Das Einfügen separater Transporttransitionen bedeutet zusätzliche Elemente im Modell. Der Zeitverbrauch für den Transport muss an der Transition modelliert werden. Dies ist im Rahmen der gefärbten Petri Netze möglich. Dadurch können Transportdauer und Bearbeitungsdauer an einem Knoten durch den gleichen Mechanismus modelliert werden. Es ist möglich, Transportwege verschiedener Produktklassen zusammenzufassen. Es ist möglich, verschiedene Transportwege für eine Produktklasse darzustellen. Im folgenden Beispiel ist ein Szenario geschildert, welches weitere Überlegungen bezüglich der Rekonstruierbarkeit durch einen Process Mining Algorithmus erfordert. Beispiel 8 (Transport Ereignisse) In der Lieferkette aus Beispiel 1 werden die Türen in der Abteilung Verpackung des Türenherstellers für den Versand vorbereitet. Anschließend werden sie durch den Logistikdienstleister zum Kunden transportiert. Bei Beladen des Transportfahrzeugs werden die Produkte vom Logistikdienstleister erfasst. Im EPCIS Datenverzeichnis wird nach dem letzten Ereignis des Türenherstellers ein Ereignis des Logistikdienstleisters aufgeführt. Es folgt ein Ereignis des Fahrzeugherstellers. Beispiel 8 zeigt, dass sowohl die Bearbeitung an (stationären) Knoten der Lieferkette als auch Transportwege selbst durch Ereignisse protokolliert werden können. Für einen Process Mining Algorithmus ist jedoch ohne weitere Informationen der Unterschied zwischen beiden nicht zu erkennen. Daher wird (mit obiger Wahl) jeder durch Ereignisse protokollierte Transport ebenfalls als Transition modelliert. Es ergeben sich unterschiedliche Konsequenzen, wenn Plätze oder Transitionen für die Modellierung von Transportwegen in Betracht gezogen werden. Rekonstruiert der Algorithmus die Transportwege zwischen den Knoten als Plätze, entsteht eine inkonsistente Modellierung. Mit dem beschriebenen Phänomen werden manche Transportwege als Transition und andere als Platz modelliert. Auf der Gegenseite ist zu nennen, dass durch die Verwendung verschiedener Netzelemente auch die unterschiedliche Wichtigkeit verschiedener Transportwege dargestellt werden kann. Rekonstruiert der Algorithmus die Transportwege zwischen den Knoten als Transitionen, bedeutet dies eine konsistente Modellierung. Bei Protokollierung von Transportwegen durch Ereignisse wie in Beispiel 8 entstehen jedoch Redundanzen, d. h. zum Beispiel ein Transport zum Transport. 62 Kapitel 4 Lösungsentwurf

65 Beide Möglichkeiten sind unter dem Gesichtspunkt zu betrachten, dass nach der Rekonstruktion eine manuelle Nachbearbeitung des Modelles möglich ist. Damit können irrelevante Transportwege eliminiert werden, als auch zusätzliche eingefügt werden. Um die Vorteile zu kombinieren, kann untersucht werden, ob z. B. durch die Nutzung des Hierarchiekonzeptes der Substitutionsplätze eine Verschmelzung beider Ansätze möglich ist. Es ist jedoch zu bedenken, dass jedes weitere Modellierungskonzept möglicherweise die Akzeptanz des Ansatzes erschwert. Im Rahmen dieser Arbeit wurde diese Art der Modellierung nicht untersucht. Unter Abwägung aller Argumente wurde entschieden, dass Transportwege durch Transitionen modelliert werden. Diese Transporttransitionen können optional einen Bezeichner tragen. Der Vorbereich einer Transporttransition umfasst die Ausgabeplätze der Transitionen, welche die Startknoten des Transportweges repräsentieren. Der Nachbereich umfasst die Eingabeplätze der Transitionen, welche die Zielknoten des Transportweges repräsentieren. Die Kanten zwischen der Transporttransition und den umliegenden Plätzen tragen Kantenausdrücke, die das Durchreichen aller Produkte ausdrücken. Die Transition kann mit einem Zeitverbrauch annotiert werden, welcher die Transportdauer angibt. Abbildung 4.5 zeigt die Modellierung des in Beispiel 7 beschriebenen Transportweges. Die Transporttransition trägt keinen Bezeichner und ist als ausgefülltes Viereck dargestellt. Wie auch bei der Modellierung der Lieferkettenknoten ist die Zeitangabe in Sekunden an die Transition annotiert Darstellung der Produktflüsse Um Anforderung Mod-01 (Produktflüsse) gerecht zu werden, muss im rekonstruierten Modell erkennbar sein, welche Produkte in welcher Reihenfolge durch welche Knoten der Lieferkette geleitet werden. Durch Nutzung des Typkonzeptes der gefärbten Petri Netze wird jede Produktklasse durch einen Typ repräsentiert. Die einzelnen Produkte einer Produktklasse werden durch Objekte der entsprechenden Typen repräsentiert. Wie im vorangegangenen Abschnitt beschrieben, wird jede Produktklasse durch eigene Plätze und damit auch Kanten geleitet. In der statischen Struktur des Netzes kann daher z. B. durch Einfärbung von Plätzen und Kanten nach Typen der Fluss der Produkte visualisiert werden. In Abbildung 4.5 wurde diese Einfärbung bereits benutzt. Über die Simulation als dynamische Analysemethode können die Produkte bei ihrem Weg durch das Liefernetzwerk verfolgt werden. Sollen bei der Simulationsanalyse individuelle Produkte verfolgt werden, müssen die Kantenausdrücke des Netzes sehr spezifisch und damit umfangreich sein. Jedes durch eine Transition zu verarbeitende Objekt ist in den Kantenausdrücken zu adressieren. Es gibt Situationen, in denen diese Art der Modellierung nicht akzeptabel ist. Das folgende Beispiel veranschaulicht das Problem. 4.3 Prozessmodellierung 63

66 Mehrwegverpackungen Blaue_Tueren Station2 1`tuer1 ++ 1`tuer2 ++ 1`tuer3 ++ 1`tuer4 ++ 1`tuer5 ++ 1`tuer6 ++ 1`tuer7 ++ 1`tuer8 ++ 1`tuer9 ++ 1`tuer `tuer11 1`ve1 (a) Adressierung einzelner Produkte Versandeinheiten Mehrwegverpackungen 1`Versandeinheit Blaue_Tueren Station2 Versandeinheiten 200`Blaue_Tuer (b) Adressierung anonymer Produkte Abbildung 4.6: Detailgrade bei Produktverfolgung Beispiel 9 (Modellierung einzelner Produkte) Angenommen, an dem Knoten Station2 der Abteilung Verpackung des Türenherstellers werden 200 Türen innerhalb von zehn Minuten zu einer Versandeinheit verpackt. Um die einzelnen Produkte bei Simulation des modellierten Netzes verfolgen zu können, müssen u. a. alle 200 Türen durch unterschiedliche Variablen angesprochen werden. Abbildung 4.6(a) zeigt einen Ausschnitt des so modellierten Netzes. Es ist offensichtlich, dass dies nicht mit der Anforderung Mod-09 (Übersichtlichkeit) zu vereinbaren ist. Es wurde daher entschieden, die Verfolgbarkeit von Produkten so zu abstrahieren, dass anonyme und identische Objekte pro Produktklasse verwendet werden. Auf diese Weise ist leichter erfassbar, welche Transformationen an den einzelnen Knoten der Lieferkette auftreten. Abbildung 4.6(b) zeigt diese Modellierung für das Szenario aus Beispiel 9. Es ist denkbar, dass die Modellierung im Sinne der ersten Variante durchgeführt wird, wenn das Modell für eine Echtzeit Überwachung einer Lieferkette eingesetzt werden soll. Zum Beispiel kann der Process Mining Algorithmus mit einem Parameter versehen werden, welcher steuert ob ein übersichtliches Modell für Analysten oder ein detailliertes Modell für maschinelle Verarbeitung erzeugt werden soll. Die Modellierung mit individuellen Produkten stellt noch eine Reihe weiterer Schwierigkeiten bereit. Zum Beispiel müssen die einzelnen EPCs sowie die aktuellen Aggregationsstrukturen innerhalb des gefärbten Petri Netzes verwaltet werden. Für diese Aspekte müssen Lösungen gefunden werden, wenn diese Funktionalität tatsächlich benötigt wird. Selektive Produktverfolgung Ein weiterer Aspekt bei der Verfolgung der Produktflüsse durch Analysten ist die Überbrückung der Fokusverschiebung (siehe Abschnitt 4.2.2). Mitunter mag es ausreichend sein, jeweils den Fluss der Produktklassen im aktuellen Fokus zu visualisieren. Werden zum Beispiel mehrere Produkte einer Produktklasse in eine Verpackungseinheit aggregiert, reicht es aus, den Weg der Verpackungseinheit zu verfolgen. Wünschenswert ist die Möglichkeit, bei Bedarf den Fluss einzelner Produktklassen durchgängig zu visualisieren. Damit kann vermieden werden, dass jeder Schritt im Lebenszyklus eines Produktes nachvollzogen werden muss, um den Fluss zu erkennen. 64 Kapitel 4 Lösungsentwurf

67 Unternehmensebene Türenhersteller Logistik Standortebene Produktion... Verpackung Transport Erweiterungsebene Lackierung... Montage Station1... Station2 Fahrzeug1 Abbildung 4.7: Ausschnitt aus der Beispiel Unternehmenshierarchie Um diese selektive Produktverfolgung umzusetzen, wird der zu entwickelnde Process- Mining Algorithmus mit einem Parameter versehen. Durch diesen werden die Produktklassen angegeben, für welche der Fluss auch ohne aktiven Fokus im rekonstruierten Modell erkennbar sein soll. Der Algorithmus wird im Petri Netz zusätzliche Elemente für die angegebenen Produktklassen erzeugen. Im Rahmen der Bewertung des vorgestellten Ansatzes ist in Abbildung 6.8 ein rekonstruiertes Modell mit selektiver Produktverfolgung dargestellt Darstellung der Unternehmenshierarchie In dieser Arbeit wird der Ansatz verfolgt, mehrere Perspektiven des Prozesswissens in einem Modell darzustellen. Während die vorangegangenen Abschnitte die Darstellung der Prozessbausteine, den Fluss der Produkte sowie temporale Aspekte adressieren, entwickelt dieser Abschnitt die Einbindung von Organisationsstrukturen. Basierend auf einem Datenmodell, welches im Rahmen des EU Projektes BRIDGE entstanden ist [CBS07], wird eine Unternehmenshierarchie wie folgt dargestellt: Es gibt eine Menge von Unternehmen. Jedes Unternehmen hat eine Menge von Standorten. Jeder Standort hat eine Menge von konkreten Orten (an denen z. B. die RFID- Lesegeräte stehen). Die Organisationsstruktur entspricht damit also einem Wald, d. h. einer ungeordneten Menge von Bäumen. Abbildung 4.7 stellt einen Ausschnitt aus der Unternehmenshierarchie der Lieferkette aus Beispiel 1 dar. Die oberste Ebene wird als Unternehmensebene bezeichnet, Knoten in dieser Ebene als Unternehmensknoten. Unternehmensstandorte werden durch Standortknoten repräsentiert und liegen in der Standortebene. Die unterste Ebene wird als Erweiterungsebene bezeichnet und enthält die konkreten Knoten der Lieferkette, d. h. die Orte an denen die RFID Lesegeräte stehen. Diese werden als Erweiterungsknoten bezeichnet. Insofern die Eindeutigkeit es zulässt, werden in der Folge statt Unternehmensknoten und Standortknoten weiterhin die Begriffe Unternehmen und Standort verwendet. 5 5 Der Begriff Standortebene suggeriert eine räumliche Trennung in Unternehmensteile. Gleichfalls kann die Hierarchie auch verwendet werden, um eine organisatorische Trennung zu modellieren. 4.3 Prozessmodellierung 65

68 Erweiterung Erweiterung Unternehmen Startseite Standort Standort Unternehmensseite Standortseite Erweiterung Abbildung 4.8: Schematische Darstellung eines hierarchischen Petri Netzes Um hierarchische Konzepte in gefärbten Petri Netzen einzusetzen, stehen verschiedene Ansätze zur Auswahl (vgl. Abschnitt 2.3.4). Erweiterungsknoten werden, wie in Abschnitt beschrieben, als Transitionen dargestellt. Um eine konsistente Modellierung der verschiedenen Hierarchieebenen zu erhalten, wurde entschieden, das Hierarchiekonzept der Substitutionstransitionen einzusetzen. Die Startseite des Petri Netzes repräsentiert die Unternehmensebene. Jeder Unternehmensknoten wird auf dieser Seite als Substitutionstransition dargestellt. Die Produktflüsse zwischen den Unternehmen werden mittels entsprechend getypter Plätze und Kanten modelliert. Die einer Unternehmenstransition zugeordnete Netzseite wird als Unternehmensseite bezeichnet. Eine Unternehmensseite stellt einen Ausschnitt der Standortebene dar. Jeder Standortknoten des Unternehmens wird auf dieser Seite als Substitutionstransition dargestellt. Die Produktflüsse zwischen den Standorten werden durch entsprechend getypte Plätze und Kanten modelliert. Die umliegenden Plätze der Unternehmenstransition in der Startseite werden auf Plätze der Unternehmensseite mittels Portzuweisung abgebildet. Existieren in der Unternehmensseite verschiedene Plätze, die eine Produktklasse aus dem Unternehmen exportieren oder in das Unternehmen importieren, werden diese Plätze durch das Hierarchiekonzept der Fusionsplätze verbunden. Dies gewährleistet Übersichtlichkeit in der übergeordneten Ebene und erlaubt das detaillierte Darstellen in der Unternehmensseite. Der gleiche Mechanismus zur Verfeinerung wird angewendet, um die Flüsse innerhalb der Standorte detaillierter darzustellen: Die einer Standorttransition zugeordnete Netzseite wird als Standortseite bezeichnet und stellt einen Ausschnitt der Erweiterungsebene dar. Durch Portzuweisung und Fusionsgruppen wird die Standortseite mit der Standorttransition verbunden. Abbildung 4.8 zeigt schematisch ein solches hierarchisches Netz. Beispiele für konkrete modellierte Netze sind in Abschnitt und Anhang C dargestellt. 66 Kapitel 4 Lösungsentwurf

69 4.3.4 Einbindung der Ereignisse Wie Anforderung Mod-04 (Stereotypen) darstellt, ist eine Klassifizierung von Lieferkettenknoten anhand ihres Verhaltens wünschenswert. Im Rahmen der gefärbten Petri- Netze existiert keine direkte Möglichkeit, Elemente durch Stereotypen auszuzeichnen. Allerdings ist es eventuell trotzdem möglich, eine solche Klassifizierung zu modellieren. Diese Möglichkeit basiert auf zwei Annahmen: Jeder Erweiterungsknoten führt genau eine Art Produkttransformation aus. Die Ereignisse, die bei einer Produkttransformation protokolliert werden, weisen für jede Art Transformation ein typisches Muster auf. Das folgende Beispiel beschreibt zwei Arten von Produkttransformationen sowie das Ereignismuster, welches jeweils generiert wird. Beispiel 10 (Ereignismuster) In der Lieferkette aus Beispiel 1 existieren auf der Erweiterungsebene mehrere Verpackungsstationen. Jede dieser Stationen verpackt eine bestimmte Anzahl Türen in eine Mehrwegverpackung. Dabei wird bei jedem Verpackungsvorgang ein Aggregationsereignis mit action = ADD generiert. Der EPC der Mehrwegverpackung wird bei diesem Aggregationsereignis als parentid verwendet, die EPCs der Türen werden im Attribut epclist gespeichert. Weiterhin gibt es mehrere Lackierstationen. Jede dieser Stationen lackiert einzeln Bleche in einer bestimmten Farbe. Für jedes lackierte Blech werden zwei Objektereignisse erzeugt: eines mit action = DELETE für das Verbrauchen des rohen Bleches und eines mit action = ADD für das Schaffen eines im Wert gesteigerten Produktes. Unter den getroffenen Annahmen kann die Klassifizierung wie folgt modelliert werden: Das für eine Art Produkttransformation typische Ereignismuster wird prototypisch durch eine Netzseite modelliert. 6 Die Lieferkettenknoten, welche diese Art Produkttransformation ausführen, werden als Substitutionstransition modelliert. Jeder dieser Transitionen wird die Netzseite mit der prototypisch modellierten Produkttransformation zugewiesen. Um die beschriebene Klassifizierung von Lieferkettenknoten vorzubereiten, wurde die im vorangegangenen Abschnitt beschriebene Hierarchie des Netzes erweitert. Unter die Erweiterungsebene wurde eine Ereignisebene gelegt. Jeder Erweiterungsknoten wird als Substitutionstransition modelliert. In der zugeordneten Netzseite sollen alle an dem Knoten aufgetretenen Ereignisse zeitlich und kausal in Beziehung gesetzt werden. Aus Zeitgründen wurde die Klassifizierung im Rahmen dieser Arbeit jedoch nicht umgesetzt. Es existieren Analysemethoden, welche das rekonstruierte Modell in Verbindung mit einem Ereignisprotokoll analysieren, z. B. Konformanzprüfungen oder Entscheidungspunktanalysen [vav + 05]. Um solche Analysen zu ermöglichen, muss die Granularität der Modelle so fein sein, dass einzelne Ereignisse identifizert werden können. Die oben beschriebene Lösung zum Einbinden der Ereignisse in das hierarchische Netz ist hierfür 6 Dieses Muster kann im Voraus bekannt sein oder durch entsprechende Algorithmen entdeckt werden. 4.3 Prozessmodellierung 67

70 nur bedingt ausreichend. Die Modelle müssen zusätzlich in nicht hierarchische Petri- Netze transformiert werden. Dies ist für jedes hierarchische Petri Netz möglich, ohne die Semantik zu verändern [Jen97]. Die erhaltenen nicht hierarchischen Netze können ebenfalls durch Konvertieralgorithmen in andere Modellformate wie ereignisgesteuerte Prozessketten oder heuristische Netze transformiert werden. 4.4 PROCESS MINING ALGORITHMUS Der im Rahmen dieser Arbeit entwickelte Process Mining Algorithmus wird im Folgenden EPCIS Miner genannt. Als Eingabe dient ein Ereignisprotokoll im MXML Format. Zu beachten ist, dass der Algorithmus nur Protokolle sinnvoll verarbeiten kann, deren Ereignisse sowohl die in Abschnitt beschriebene Attributstruktur aufweisen, als auch entsprechend der in Abschnitt beschriebenen Strategie 6 gruppiert wurden. Die Anwendung des Algorithmus EPCIS Miner auf andere Daten wird unvorhersehbare Resultate erbringen. Die Ausgabe des Algorithmus ist ein zeitbehaftetes hierarchisches gefärbtes Petri Netz, welches die Unternehmenshierarchie sowie die Produktflüsse inklusive Zeitverbrauch wie in Abschnitt 4.3 beschrieben modelliert. Der Algorithmus EPCIS Miner berücksichtigt einen Parameter. Über diesen werden die Produktklassen spezifiziert, welche für die selektive Produktverfolgung ausgewählt wurden. Der Algorithmus arbeitet in zwei Phasen. Zuerst werden die Ereignisse verarbeitet und alle entnehmbaren Informationen in ein Zwischenmodell überführt. In einer zweiten Phase folgt die Umwandlung dieses Zwischenmodells in das endgültige Repräsentationsformat (gefärbtes Petri Netz). Durch diese mehrphasige Arbeitsweise kann das Repräsentationsformat des Modells bei Bedarf ausgetauscht werden Erste Phase In der ersten Phase wird das MXML Ereignisprotokoll entsprechend seiner Struktur verarbeitet: Die einzelnen Prozesse werden separat gelesen. Alle Prozessinstanzen innerhalb eines Prozesses werden nacheinander verarbeitet. Innerhalb einer Prozessinstanz werden die Ereignisse nach ihrer Reihenfolge verarbeitet. Aus jedem Ereignis werden bestimmte Informationen gewonnen: Es wird der Erweiterungsknoten in der Lieferkette identifiziert, an welchem das Ereignis ausgelöst wurde. Gleichzeitig wird der übergeordnete Standortknoten sowie der darüber gelegene Unternehmensknoten identifiziert. Ist dies aufgrund unzureichender Informationen nicht möglich, werden entsprechende Knoten künstlich erzeugt, um eine konsistente Modellierung zu ermöglichen. 68 Kapitel 4 Lösungsentwurf

71 Es werden die Eingabeprodukte identifiziert, welche das Ereignis für den Knoten protokolliert. Es werden die Produkte identifiziert, welche das Ereignis als Ausgabe für den Knoten protokolliert. Mittels dieser Produkte wird die Transformationsregel erstellt, welche durch das Ereignis beschrieben wird. Ein Beispiel soll verdeutlichen, wie diese Informationsgewinnung geschieht. Beispiel 11 (Ereignis Informationen) In Abbildung 4.3 auf Seite 52 ist ein MXML Ereignis dargestellt, welches durch das in Abschnitt 4.2 beschriebene Konvertierverfahren entstanden ist. Aus diesem Ereignis werden folgende Informationen gezogen: Der Erweiterungsknoten, an welchem das Ereignis ausgelöst wurde, ist identifiziert durch urn:verpackung:station1 (Attribut readpoint). Dieser Erweiterungsknoten gehört zum Unternehmen, welches unter der Nummer registriert ist, genauer zu dessen Standort mit der Nummer (Auswertung des Attributes bizloc). Bei der durch das Ereignis dokumentierten Aggregation (Feld eventtype) wurden zwei Produkte verarbeitet. Der EPC beider Produkte ist vom Typ SGTIN. Die Produktklasse des ersten Produktes trägt die Identifikationsnummer , die des zweiten Produkts trägt die Identifikationsnummer (Attribut childepcs). Die Aggregation erzeugte ein Ausgabeprodukt. Dessen EPC ist vom Typ SSCC, die Produktklasse trägt die Identifikationsnummer (Attribut parentid). Die zugehörige Transformationsregel lautet: 1 sgtin sgtin sscc Durch die Anordnung der Ereignisse in einer Prozessinstanz des MXML Ereignisprotokolls können Informationen über die Verbindungen zwischen den Knoten der Lieferkette gewonnen werden: Die Prozessinstanz (und der zugehörige Prozess), deren Ereignisse aktuell verarbeitet werden, bestimmt eine Produktklasse pc. Es wird geprüft, ob ein Produkt dieser Produktklasse sowohl als Eingabeprodukt des aktuell betrachteten Ereignisses als auch als Ausgabeprodukt des zuletzt betrachteten Ereignisses dient. Ist dies der Fall, wird eine Verbindungskante rekonstruiert, auf welcher Produkte der Produktklasse pc transportiert werden. Der Startpunkt dieser Kante ist der Knoten, welcher dem zuletzt betrachteten Ereignis zugeordnet ist. Der Endpunkt ist der Knoten, welcher dem aktuell betrachteten Ereignis zugeordnet ist. 4.4 Process Mining Algorithmus 69

72 Listing 4.2: Phase 1 des Process Mining Algorithmus 1 INPUT : log MXML log 2 tracedproductclasses set of product classes 3 OUTPUT: model intermediate supply chain model 4 5 FOR EACH ProductClass pc IN log 6 FOR EACH Product p IN pc 7 VAR l a s t E : Event 8 FOR EACH Event e IN p 9 model. createnode ( e ) 10 model. createtransformationrule ( e ) 11 model. createedge ( e, laste, pc ) 12 IF tracedproductclasses. contains ( pc ) THEN 13 model. createtraceedge ( e, laste, pc ) 14 END IF 15 l a s t E = e 16 END FOR 17 END FOR 18 END FOR Die Zeit zwischen dem Auftreten des aktuell betrachteten Ereignisses und des zuletzt betrachteten Ereignisses wird notiert und fließt später in die Berechnung der Transportdauer zwischen den Knoten ein. Wurde die Produktklasse pc zur selektiven Produktverfolgung ausgewählt, werden zusätzliche Verbindungskanten rekonstruiert: Je zwei Knoten, welche zu zeitlich aufeinander folgenden Ereignissen in einer Prozessinstanz zugeordnet sind, werden verbunden. Nach Verarbeitung aller Ereignisse werden in weiteren Schritten Informationen zusammengefasst: Für jeden Erweiterungsknoten wird eine Transformationsregel erstellt, welche das Verhalten des Knotens angibt. Dazu werden die Transformationsregeln aller Ereignisse aggregiert, welche diesem Knoten zugeordnet sind. 7 Für jede Verbindungskante wird die Menge der erfassten Transportzeiten akkumuliert, um einen Wert für den Zeitverbrauch zu erhalten. Die erste Phase des Algorithmus ist in Listing 4.2 als Pseudo Code dargestellt. In den Zeilen 5 und 6 ist zu sehen, dass Prozesse des MXML Ereignisprotokolls mit Produktklassen und Prozessinstanzen mit Produkten identifiziert werden. Die Funktion createnode extrahiert aus den Feldern bizloc und readpoint des aktuell betrachteten Ereignisses 7 Dies funktioniert nur, wenn alle Transformationsregeln eines Knotens homogen sind, d. h. sich nur in den Quantitäten unterscheiden. 70 Kapitel 4 Lösungsentwurf

73 die Bezeichner für Unternehmen, Standort und Erweiterungsknoten. Existieren die entsprechenden Knoten noch nicht, werden sie durch die Funktion neu erstellt und in eine Baumstruktur eingeordnet. Die Funktion createtransformationrule extrahiert die Transformationsregel aus einem Ereignis in Abhängigkeit des Ereignistyps. Die Funktion createedge bestimmt die Zeit zwischen zwei Ereignissen und prüft, ob zwischen den zugehörigen Knoten eine Verbindungskante für die aktuell betrachtete Produktklasse existiert und ob diese im Fokus liegt. Ist dies nicht der Fall, erstellt die Funktion eine solche. Der Parameter tracedproductclasses enthält die für die durchgängige Verfolgung selektierten Produktklassen. In Zeile 13 wird durch die Funktion createtraceedge eine Kante für die selektive Produktverfolgung erzeugt Zweite Phase In der zweiten Phase des Algorithmus EPCIS Miner wird aus den in der ersten Phase gewonnenen Informationen das Petri Netz konstruiert. Dazu werden zuerst eine Menge von Typen erstellt, welche an den Plätzen und Kantenbeschriftungen verwendet werden. Für jede Produktklasse, die in der Lieferkette auftaucht, wird ein Typ erstellt. Jeder Typ enthält genau ein Element, welches als anonymes Produkt dieser Klasse verwendet wird (siehe dazu Abschnitt 4.3.2). Beispiel 12 (Produktklassen Typen) In Beispiel 11 sind drei Produktklassen aufgeführt. Die Typen, welche aus diesen erstellt werden, sind hier in Mengenschreibweise dargestellt: PCsgtin_000001_ = { sgtin_000001_ } PCsgtin_000001_ = { sgtin_000001_ } PCsscc_ = { sscc_ } Die Verwendung von Unterstrichen in den Bezeichnern ist durch die Syntax der funktionalen Programmiersprache CPN ML (Coloured Petri Net Markup Language) begründet, welche für die Spezifikation von gefärbten Petri Netzen verwendet wird [JK09]. Nun wird die Hierarchie der Seiten des Petri Netzes aufgebaut: Es wird die Startseite des Netzes erstellt. Für jeden Unternehmensknoten wird eine Substitutionstransition in der Startseite erstellt, sowie eine Unternehmensseite zugeordnet. Für jeden Standortknoten wird eine Substitutionstransition in der entsprechenden Unternehmensseite erstellt, sowie eine Standortseite zugeordnet. 4.4 Process Mining Algorithmus 71

74 1`sgtin_000001_ PCsgtin_000001_ `sgtin_000001_ urn_verpackung_station1 extension_urn_verpackung_station1 1`sscc_ PCsscc_ PCsgtin_000001_ Abbildung 4.9: Rekonstruierte Erweiterungstransition Für jeden Erweiterungsknoten wird eine Substitutionstransition in der entsprechenden Standortseite erstellt. Dieser Transition werden Eingabe- und Ausgabeplätze für die einzelnen Produktklassen auf Grundlage der Transformationsregel an diesem Knoten zugeordnet. Die Transformationsregel selbst wird verteilt als Kantenbeschriftung zwischen der Transition und den umliegenden Plätzen angebracht. Für jede Art Ereignis, welche an einem Erweiterungsknoten auftritt, wird eine Transition in der entsprechenden Erweiterungsseite erstellt. Entsprechend der Transformationsregel des Ereignisses werden der Transition Eingabe- und Ausgabeplätze für die einzelnen Produktklassen zugeordnet. Diese Plätze werden über Portzuweisung mit der Erweiterungstransition in der Standortseite verschaltet. Existieren mehrere Ausgabeportplätze für eine Produktklasse innerhalb der Erweiterungsseite, werden diese zu einer Fusionsgruppe verbunden, analog für Eingabeportplätze. Beispiel 13 (Rekonstruktion Erweiterungstransition) Das in Beispiel 11 analysierte Ereignis protokolliert eine Aggregation an einem Lieferkettenknoten. In der Startseite des Netzes wird entsprechend den extrahierten Informationen eine Substitutionstransition mit dem Bezeichner für das Unternehmen erzeugt. In der zugehörigen Unternehmensseite wird eine Substitutionstransition mit dem Bezeichner für den Standort erzeugt. Abbildung 4.9 stellt einen Ausschnitt der zugehörigen Standortseite dar. Für den Erweiterungsknoten mit dem Bezeichner urn:verpackung:station1 wird in dieser Seite eine Substitutionstransition erzeugt. Dieser wird eine Erweiterungsseite mit der Bezeichnung extension_urn_verpackung_station1 zugewiesen, auf welche das blaue Schild unter der Transition verweist. Die Transformationsregel wird in Ein- und Ausgabeplätze sowie Kantenausdrücke umgesetzt. Das Ereignis selbst wird in die zugewiesene Erweiterungsseite (nicht dargestellt) aufgenommen. Bis zu diesem Punkt ist nur die Ereignisebene mit der Erweiterungsebene verbunden. Zwischen den übrigen Ebenen besteht noch keine Verbindung. Jetzt werden die rekonstruierten Verbindungskanten als Basis genommen, das Netz zu vernetzen : Für jede Verbindung wird eine Transition (ohne Bezeichner) erstellt. An diese Transporttransition wird der akkumulierte Zeitverbrauch annotiert. 72 Kapitel 4 Lösungsentwurf

75 Unternehmensebene Seite company_ Seite company_ Seite subloc_ Seite subloc_ Abbildung 4.10: Einbettung der Transporttransitionen Es wird bestimmt, auf welcher Ebene und Seite des Petri Netzes die Transporttransition angesiedelt werden muss (zwischen Unternehmensknoten, zwischen Standortknoten eines Unternehmens oder zwischen Erweiterungsknoten innerhalb eines Unternehmensstandortes). 8 In der entsprechenden Ebene werden die vorherige und folgende Transition identifiziert. Gegebenenfalls werden für diese entsprechende Aus- und Eingabeplätze für die Produktklasse der Verbindungskante erstellt. Über diese Plätze wird die Transporttransition eingebunden. Befindet sich die Transition in der Unternehmensebene oder in einer Unternehmensseite der Standortebene, werden entsprechende Portzuweisungen vorgenommen, um die Netzseiten durchgängig bis zur Erweiterungsebene zu verbinden. Existieren mehrere Ausgabeportplätze für eine Produktklasse innerhalb einer Seite, werden diese zu einer Fusionsgruppe verbunden, analog für Eingabeportplätze. Beispiel 14 (Rekonstruktion Transporttransition) In Beispiel 13 ist die Rekonstruktion eines Erweiterungsknotens mit der Bezeichnung urn:verpackung:station1 im Petri Netz beschrieben. Weiterhin wird aus den Ereignissen eine Verbindungskante von diesem Erweiterungsknoten zu einem Erweiterungsknoten mit der Bezeichnung urn:fahrzeug1 rekonstruiert. Letzterer Knoten ist einem Standort mit der Bezeichnung zugehörig, dieser wiederum einem Unternehmen mit der Bezeichnung Auf der Verbindungskante werden Produkte der Produktklasse sscc transportiert. Die mittlere Transportzeit beträgt Sekunden. Abbildung 4.10 stellt die Rekonstruktion dieser Verbindung als Transporttransition dar. 8 Die rekonstruierten Kanten verbinden grundsätzlich zwei Erweiterungsknoten, welche jedoch möglicherweise in unterschiedlichen Teilbäumen der Unternehmenshierarchie liegen. 4.4 Process Mining Algorithmus 73

76 Da die Verbindung zwischen Erweiterungsknoten verschiedener Unternehmen existiert, wird die Transporttransition in der Unternehmensebene erstellt. Dargestellt wird die Transition als ausgefülltes Viereck. Die Transportzeit ist an der Transition annotiert. Die Transportransition ist so mit den Unternehmenstransitionen verbunden, dass der Produktfluss zwischen den Erweiterungsknoten auf der Unternehmensebene korrekt abgebildet ist. Weiterhin dargestellt sind die entsprechenden Ausschnitte der Standort- und Erweiterungsebene. Die gestrichelten Pfeile deuten an, welche Plätze über Portzuweisung miteinander verschaltet werden. Unter jedem Portplatz gibt ein blaues Schild an, ob der Platz zu einem Ein- oder Ausgabeplatz der übergeordneten Substitutionstransition zugewiesen wurde. Die zweite Phase des Algorithmus ist in Listing 4.3 als Pseudo Code dargestellt. In den Zeilen 5 bis 11 wird für jeden Knoten der Unternehmenshierarchie eine Substitutionstransition in der entsprechenden Seite des Netzes erstellt. In Zeile 12 liest die Funktion gettransformationrule die einem Erweiterungsknoten zugewiesene Transformationsregel. Diese wird in der Funktion createinputoutputplaces verwendet, um die Erweiterungstransition mit Ein- und Ausgabeplätzen zu verbinden. Durch die Funktion createextensionpage wird schließlich die Erweiterungsseite mit allen Ereignissen erstellt und diese über Portzuweisung mit der Erweiterungstransition verbunden. Nachdem in Zeile 17 der Aufbau der Hierarchie des Netzes abgeschlossen ist, werden in den Zeilen 19 bis 29 die rekonstruierten Verbindungskanten in Transporttransitionen überführt. Die Auswahl der passenden Hierarchieebene und Netzseite geschieht durch die Funktion determinetargetpage. Die Funktion determinetransition bestimmt in den Zeilen 21 und 22 die Start- und Zieltransition für die Transportkante. In Zeile 24 wird die Transportzeit an die neu erstellte Transition annotiert. Die Funktion connecttransport verbindet die Transporttransition mit der Start- und Zieltransition über Plätze entsprechend der Produktklasse der Verbindungskante. In Zeile 27 wird die eigentliche Verbindung zwischen den einzelnen Netzseiten über Portzuweisung hergestellt Diskussion Es werden neben den Ereignissen aus dem MXML Ereignisprotokoll keine weiteren Informationen zur Rekonstruktion herangezogen. Dies zieht eine Reihe von Aspekten nach sich: Im Allgemeinen ist nicht davon auszugehen, dass an einem Knoten der Lieferkette grundsätzlich ein Ereignis beim Start der Bearbeitung UND ein Ereignis beim Beenden der Bearbeitung ausgelöst wird. Damit ist eine Erkennung der Bearbeitungsdauer an Lieferkettenknoten nicht möglich. Wenn keine oder nur unzureichende Informationen angegeben sind, kann auch nur ein ungenügendes Resultat geliefert werden. Ist zum Beispiel aus der Angabe des RFID Lesepunktes und dessen Standortes nicht eindeutig herauszulesen, welchem Unternehmensstandort bzw. welchem Unternehmen dieser angehört, so kann auch keine korrekte Unternehmenshierarchie rekonstruiert werden. 74 Kapitel 4 Lösungsentwurf

77 Listing 4.3: Phase 2 des Process Mining Algorithmus 1 INPUT : model intermediate supply chain model 2 OUTPUT: cpn CPN supply chain model 3 4 FOR EACH CompanyNode company IN model. companies 5 companytrans = cpn. c r e a t e T r a n s i t i o n ( company, cpn. toppage ) 6 companypage = cpn. createsubpage ( companytrans ) 7 FOR EACH SublocNode subloc IN company. s u b l o c a t i o n s 8 subloctrans = cpn. c r e a t e T r a n s i t i o n ( subloc, companypage ) 9 sublocpage = cpn. createsubpage ( subloctrans ) 10 FOR EACH ExtensionNode ext IN subloc. extensions 11 exttrans = cpn. c r e a t e T r a n s i t i o n ( ext, sublocpage ) 12 transrule = model. gettransformationrule ( ext ) 13 createinputoutputplaces ( exttrans, transrule, cpn ) 14 createextensionpage ( exttrans, cpn ) 15 END FOR 16 END FOR 17 END FOR FOR EACH Edge edge IN model. edges 20 page = determinetargetpage ( edge, cpn ) 21 t1 = d e t e r m i n e T r a n sition ( edge. s t a r t, page ) 22 t2 = d e t e r m i n e T r ansition ( edge. end, page ) 23 t r a n s = cpn. c r e a t e T r a n s i t i o n ( page ) 24 t r a n s. time = edge. time 25 connecttransport ( trans, t1, t2, edge. productclass, cpn ) 26 IF page. l e v e l < " e x t e n s i o n _ l e v e l " THEN 27 cpn. assignports ( page, trans, edge ) 28 END IF 29 END FOR Aus den Ereignissen ist im Allgemeinen nicht zu erkennen, wieviele Produkte einer Produktklasse gemeinsam zwischen verschiedenen Knoten der Lieferkette transportiert werden. Die rekonstruierten Transportkanten für jede Produktklasse können daher keine sinnvollen quantitativen Angaben tragen. Um ein semantisch korrektes Modell zu erhalten, ist es jedoch nötig, dass für alle Transitionen durch Kantenausdrücke bestimmt wird, welche Marken verarbeitet werden sollen. Dies gilt auch für Transporttransitionen. Daher werden alle umliegenden Kantenausdrücke in der Form 1 <Produkt> annotiert. Bezüglich der Ausführungssemantik stellt dies keinen Nachteil dar. Da eine Aktivität parallel mehrfach aktiviert und ausgeführt werden kann, ist auch der gleichzeitige Transport mehrerer Produkte simulierbar. Die Transportzeiten werden derzeit durch Mittelwertbildung aggregiert. Dadurch wird grundsätzlich genau ein Transportweg für eine Produktklasse zwischen zwei Lieferkettenknoten rekonstruiert. Es ist denkbar, dass durch den Einsatz von Clusterverfahren die Erkennung und Rekonstruktion verschiedener Transportwege (Bahn, LKW,... ) er- 4.4 Process Mining Algorithmus 75

78 möglicht wird. Ebenfalls kann durch solche Verfahren möglicherweise erkannt werden, welche Produktklassen gemeinsam auf einem Transportweg bewegt werden. Eine Untersuchung diesbezüglich liegt außerhalb des Fokus dieser Arbeit. Die prototypische Umsetzung der Transportzeitenberechnung resultiert pro Transporttransition in einem einzigen Wert. Dies ist für die Lesbarkeit des Modells vorteilhaft. Um das Modell durch Simulation einer Durchlaufzeitenanalyse zu unterziehen, kann die Berechnung der Zeiten sowie deren Umsetzung im Modell erweitert werden. Durch Nutzung der funktionalen Programmiersprache CPN ML können die Transportzeiten durch Wahrscheinlichkeitsverteilungen repräsentiert werden, deren Parameter aus den akkumulierten Zeiten gewonnen werden. Die Rekonstruktion der Transformationsregeln und damit der Kantenausdrücke basiert auf der Erkennung einer kausalen Struktur zwischen den Ereignissen eines Erweiterungsknotens. Dies wurde im Rahmen dieser Arbeit nicht umgesetzt. Daher kann möglicherweise nicht für alle Erweiterungsknoten die Transformationsregel rekonstruiert werden. Im Modell werden für Transitionen und Produktklassen numerische Bezeichner verwendet. Dies ist auf die im Protokoll zur Verfügung stehenden Informationen zurückzuführen. Um die Lesbarkeit des Modells zu verbessern, kann der Algorithmus EPCIS Miner um zusätzliche Parameter erweitert werden. Dadurch können die numerischen Bezeichner für Produktklassen oder Standortangaben durch textuelle Bezeichner ersetzt werden. Die Funktionsweise des Algorithmus wird durch solche Parameter nicht beeinflusst. Der Algorithmus EPCIS Miner verarbeitet derzeit nur Objekt- und Aggregationsereignisse. Um Anforderung Mod-02 (Geschäftstransaktionen) zu erfüllen, müssen weiterhin auch Transaktionsereignisse verarbeitet werden. Durch Erweiterung des Algorithmus mit einem Parameter können Transaktionsbezeichner angegeben werden. Der Algorithmus kann dahingehend modifiziert werden, dass nur Flüsse für Produkte rekonstruiert werden, welche im Zusammenhang mit den angegebenen Geschäftstransaktionen stehen. Alternativ ist auch die Rekonstruktion zusätzlicher Elemente denkbar, ähnlich wie bei der Umsetzung der selektiven Produktverfolgung. Aus Zeitgründen wurden diese Ideen nicht umgesetzt. Sinnvoll in diesem Zusammenhang ist die Untersuchung, inwiefern zusätzliche Informationen (Bestelldaten... ) in das Process Mining aufgenommen werden können, um eine vollständigere Rekonstruktion geschäftlicher Aspekte zu erreichen. 76 Kapitel 4 Lösungsentwurf

79 5 IMPLEMENTIERUNG In diesem Kapitel wird die prototypische Implementierung der vorgestellten Lösung beschrieben. Entsprechend den Teilaufgaben der Aufgabenstellung wird in der Folge einzeln auf die Algorithmen EPCIS2MXML und EPCIS Miner eingegangen, ebenso wie auf Mechanismen zum Umgang mit den spezifischen Datenstrukturen für die Prozessmodelle. Es werden die benutzten Frameworks und Werkzeuge beschrieben. Die implementierten Prototypen liegen der Arbeit bei. Weitere Informationen dazu, sowie Anleitungen zum Ausführen der Prototypen sind in Anhang A beschrieben. 5.1 KONVERTIERUNG DER EREIGNISSE In Abschnitt 4.1 wurde begründet, warum als Grundlage für die Implementierung die Process Mining Software ProM verwendet wird. Als Werkzeug für die Bereitstellung der Ereignisprotokolle im Eingabeformat MXML steht das Framework ProM Import zur Verfügung [pro09a]. Das Framework ermöglicht durch ein Plug In Konzept die effiziente Implementierung der einzelnen Konvertieralgorithmen. Jedes Plug In kapselt die Konvertierung eines bestimmten Protokollformates in das MXML Format, wobei die auch von ProM verwendete MXML Bibliothek genutzt wird, um die XML Dateien zu erstellen. Dadurch steht bei der Implementierung die Abbildung vom gegebenen Protokollformat auf das MXML Format im Vordergrund. Für diese Arbeit wurde ein Plug In für ProM Import erstellt, welches den in Abschnitt 4.2 beschriebenen Algorithmus EPCIS2MXML implementiert. Abbildung 5.1 zeigt die Benutzeroberfläche des Werkzeuges ProM Import. Im linken Bereich ist die Auswahlliste der verfügbaren Plug Ins zu sehen. Die Namen der Plug Ins beziehen sich größtenteils auf das Ereignisformat bzw. die Datenquelle, welche von dem Plug In zur Konvertierung verwendet wird. Im rechten Bereich sind für das jeweils ausgewählte Plug In zusätzliche Informationen sowie Einstellmöglichkeiten gegeben. Nach Einstellung aller Parameter wird mittels des Knopfes Start die Konvertierung ausge- 77

80 Abbildung 5.1: Benutzeroberfläche des ProM Import Werkzeuges löst. Dabei werden die Einstellmöglichkeiten ausgeblendet und eine Textkonsole angezeigt. Auf dieser werden Informationen und etwaige Fehlermeldungen über die laufende Konvertierung ausgegeben. Das im Rahmen dieser Arbeit implementierte Plug In ist in der Auswahlliste als EPCIS aufgeführt und ausgewählt. Durch den Parameter EPCIS query URL wird die EPCIS Abfrageschnittstelle angegeben, über welche die Ereignisse aus dem Datenverzeichnis gelesen werden. Da die Implementierung prototypischen Charakter haben soll, wurde nur die einfachste Art des Zugriffs implementiert. Auf etwaige Authentifizierungsmechanismen wurde verzichtet. Ebenfalls ist nur der Zugriff auf ein einzelnes Datenverzeichnis implementiert. Diese Aspekte schränken die Anwendbarkeit der Implementierung nicht ein, da die entsprechenden Mechanismen die Funktionalität des eigentlichen Plug Ins nicht beeinflussen. Für den Zugriff auf die EPCIS Abfrageschnittstelle wurde die Bibliothek Fosstrak EPCIS Query Client [fos09] verwendet. Von den in Anforderung Dat-03 (Ereignisfilterung) angegebenen Filterparametern zum Einschränken der Ereignismenge wurde exemplarisch implementiert, dass Ereignisse innerhalb eines bestimmten Zeitfensters berücksichtigt werden sollen. Dazu wurden die zwei Parameter eventtime >= und eventtime < in die Plug In Einstellungen integriert. Über den Parameter (Product Class) Granularity wird die Granularität der Konvertierung eingestellt, welche in Abschnitt beschrieben ist. Der Zielordner für die erzeugten MXML Dateien wird über den Parameter Output to angegeben. Standardmäßig wird von der verwendeten MXML Bibliothek für jeden Prozess, in diesem Fall für jede Produktklasse, eine eigene MXML Datei erstellt. Im Plug In 78 Kapitel 5 Implementierung

81 EPCIS kann jedoch über den Parameter All processes in one file eingestellt werden, ob eine Datei erstellt werden soll, welche alle Produktklassen enthält. Der Parameter Keep single process files bestimmt, ob die einzelnen, nur eine Produktklasse umfassenden Dateien behalten werden sollen. Die resultierenden MXML Dateien haben mitunter einen hohen Speicherbedarf. Daher kann ProM Import statt der Ausgabe in eine reine MXML Datei auch direkt eine komprimierte Datei erzeugen. Aus dem gleichen Grund wurde für das Zusammenfassen der einzelnen Dateien zu einer Datei ein Ansatz für die Implementierung gewählt, welcher die Dateien nicht komplett in den Arbeitsspeicher lädt. Die prototypische Implementierung enthält nicht die Möglichkeit, komprimierte MXML Dateien auf diese Weise zu verarbeiten. Daher ist es für das erfolgreiche Zusammenfassen der Dateien nötig, in den Einstellungen des Plug Ins das Ausgabeformat MXML auszuwählen (Parameter Output as ). Die Funktionalität des Plug Ins wird dadurch nicht beeinträchtigt. Zum Einen kann dieser Aspekt implementiert werden, wenn es nötig erscheint. Andererseits kann auch der Konvertierung eine Komprimierung nachgeschaltet werden, so dass nur für die Dauer der Konvertierung der volle Speicherplatz benötigt wird. Bei der Implementierung des Algorithmus EPCIS2MXML wurde die zum Zeitpunkt dieser Arbeit aktuellste Version 7.0 des Werkzeugs ProM Import zugrunde gelegt. 5.2 PROZESSMODELLIERUNG Für die Repräsentation der hierarchischen gefärbten Petri Netze wurde eine Klassenbibliothek benötigt, die sowohl die grundlegenden Datenstrukturen bereitstellt als auch den Umgang mit diesen einfach gestaltet. Dazu gehört zum Einen die Möglichkeit der Visualisierung der Datenstrukturen in ProM. Zum Anderen ist die Möglichkeit wichtig, die Modelle so zu exportieren, dass sie von Softwarewerkzeugen verarbeitet werden können, die auf den Umgang mit diesen Datenstrukturen spezialisiert sind. Durch die Anforderungen Mod-06 (Interoperabilität) und Mod-07 (Zugang zu Analysemethoden) stand die Wiederverwendbarkeit durch andere Komponenten des Frameworks und damit auch die Möglichkeit für weitere Analysen der Modelle in ProM im Vordergrund. Im Rahmen eines Export Plug Ins [RMv06] bietet das ProM Framework einige Klassen für die Modellierung der zeitbehafteten hierarchischen gefärbten Petri Netze an. Die Datenstrukturen sind kompatibel mit den vom ProM Framework verwendeten Datenstrukturen für nicht hierarchische nicht gefärbte Petri Netze. Somit können Teile der Modelle zumindest als Stellen Transitions Netze für weitere Analysen innerhalb von ProM verwendet werden. Das erwähnte Export Plug In setzt spezielle Annahmen über die Struktur der Netze voraus, welche bei der Nutzung für Lieferkettenmodelle nicht erfüllt sind. Die Exportfunktion konnte somit nicht direkt eingesetzt werden. Unter Verwendung von Teilen dieser Implementierung wurde für diese Arbeit eine neue Exportfunktion implementiert, die das rekonstruierte zeitbehaftete hierarchische gefärbte Petri Netz in das CPN Format überführt. Dieses kann vom Softwarewerkzeug CPN Tools, welches auf den Umgang mit 5.2 Prozessmodellierung 79

82 (a) Unternehmensebene (b) Standortebene Abbildung 5.2: Visualisierung hierarchischer Petri Netze in ProM solchen Netzen spezialisiert ist, verarbeitet werden. Im folgenden Abschnitt wird die Visualisierung der rekonstruierten Netze in CPN Tools näher beschrieben. Visualisierung Das ProM Framework bietet keine vordefinierte Visualisierung für die spezifischen Erweiterungen der Datenstrukturen für gefärbte Petri Netze. Daher wurde für diese Arbeit eine Visualisierung implementiert, welche zumindest die hierarchischen Aspekte des Netzes darstellt. Dies ermöglicht einen ersten Überblick über das rekonstruierte Modell im ProM Werkzeug. In Abbildung 5.2 ist diese Visualisierung dargestellt. Die Teilabbildungen zeigen verschiedene Ansichten eines hierarchischen Netzes, welches in Übereinstimmung mit den in Abschnitt beschriebenen Richtlinien die in Beispiel 1 beschriebene Lieferkette modelliert. In der Baumansicht am linken Rand wird die hierarchische Struktur der Seiten des Netzes dargestellt. Ist in der Baumansicht eine Seite ausgewählt, wird diese im Zeichenbereich rechts als Stellen Transitions Netz dargestellt. Hierfür wurde auf die von ProM bereitgestellte Visualisierung von Petri Netzen zurückgegriffen. In Abbildung 5.2(a) ist die als top page bezeichnete Startseite des Netzes ausgewählt, in Abbildung 5.2(b) die Unternehmensseite des Türenherstellers. In dieser Visualisierung werden jedoch einige wichtige Aspekte nicht dargestellt, so gerade die Typinformationen der Plätze und Kanten sowie temporale Annotationen. Das 80 Kapitel 5 Implementierung

83 Abbildung 5.3: Visualisierung gefärbter Petri Netze in CPN Tools Werkzeug CPN Tools füllt diese Lücke. Das in das CPN Format exportierte rekonstruierte Netz kann in CPN Tools eingeladen werden. Somit ist es möglich, das Prozessmodell in allen Aspekten zu betrachten und es zu bearbeiten. Weiterhin kann es durch Simulation analysiert werden. Abbildung 5.3 zeigt ein Bildschirmfoto des Werkzeuges CPN Tools. Geladen ist das gleiche Netz, welches auch in Abbildung 5.2 dargestellt ist. Im linken Bereich des Programmes finden sich verschiedene Werkzeuge, die Deklarationen der angezeigten Modelle sowie eine Übersicht deren hierarchischer Struktur. Auf der Zeichenfläche können in mehreren Unterfenstern und Reitern verschiedene Sichten der Modelle platziert werden. In Abbildung 5.3 wird ein Ausschnitt aus der Erweiterungsebene des Modells angezeigt, konkret die Standortseite, welche der Substitutionstransition Produktion zugewiesen ist, die in Abbildung 5.2(b) dargestellt ist. Innerhalb der Zeichenfläche kann über Kontextmenüs durch das Modell navigiert werden. Über das Schild unter jeder Substitutionstransition kann die zugewiesene Netzseite angezeigt werden. Über das Schild unter jedem Port Platz kann der entsprechende Socket Platz in der Überseite angesteuert werden. In Abbildung 5.3 sind nur Substitutionstransitionen dargestellt, daher befindet sich unter jeder ein solches Schild. Bei den beiden Eingabeplätzen der Produktklasse Griff für die Transitionen Montage1 und Montage2 zum Beispiel handelt es sich um (Eingabe-) Port Plätze. Unter beiden befindet sich ein Schild In, welches dies anzeigt. Ebenfalls befindet sich unter diesen beiden Plätzen ein Schild, welches darauf hindeutet, dass die beiden Plätze der Fusionsgruppe in_griff angehören (vgl. Abschnitt 4.3.3). Die Abbildung zeigt weiterhin, dass das Modell gerade durch Simulation analysiert wird. An jedem Platz ist in grün annotiert, welche Marken sich jeweils auf ihm befinden. Durch sukkzessives Schalten der Transitionen können die Abläufe in der Lieferkette besser verstanden werden. Es ist ersichtlich, dass sich alle Plätze innerhalb einer Fusionsgruppe exakt die selben Marken teilen. 5.2 Prozessmodellierung 81

84 Abbildung 5.4: Einstellungsmöglichkeiten des Plug Ins EPCIS Miner 5.3 PROCESS MINING ALGORITHMUS Der in Kapitel 4.4 beschriebene Algorithmus EPCIS Miner wurde als Plug In für das Werkzeug ProM implementiert. Der Implementierung wurde die zum Zeitpunkt dieser Arbeit aktuellste Version 5.2 von ProM zugrunde gelegt. Die Plug Ins gruppieren sich in verschiedene Kategorien und werden kontextspezifisch aktiviert. Das bedeutet, dass jeweils nur die Plug Ins angezeigt und aufgerufen werden können, welche die aktuell geladene Datei verarbeiten können. Das im Rahmen dieser Arbeit implementierte Plug In ist in der Kategorie Mining als EPCIS Miner erreichbar und kann auf geladene MXML- Dateien angewendet werden. Bevor der Algorithmus gestartet wird, können mehrere Einstellungen vorgenommen werden, welche in Abbildung 5.4 dargestellt sind. Die Lesbarkeit des Modells kann erhöht werden, indem die Produktklassennummern durch spezifische Produktnamen ersetzt werden. Dazu wird die Protokolldatei vorverarbeitet, um die darin enthaltenen Produktklassen zu extrahieren. Über eine Tabelle kann dann zu jeder dieser Produktklassen ein spezifischer Name vergeben werden, welcher später im Modell verwendet wird. Ebenfalls für die Erhöhung der Lesbarkeit können die verschiedenen Produktklassen durch verschiedene Farben im Modell visualisiert werden. In der erwähnten Tabelle findet sich daher für jede in der Protokolldatei enthaltene Produktklasse auch eine Auswahlmöglichkeit für eine Farbe. Die farbliche Visualisierung ist nicht in ProM selbst enthalten, kann aber durch einen Export in das CPN-Format von CPN Tools genutzt werden. Zu beachten ist weiterhin, dass die Auswahl von Farben in diesem Einstellungsdialog in der Tat nur Visualisierungsaspekte umsetzt. Dies ist nicht zu verwechseln mit dem Objekttyp 82 Kapitel 5 Implementierung