56 HMD 293

Tom Thaler, Peter Fettke, Peter Loos

Process Mining – Fallstudie leginda.de

Der Beitrag zeigt, wie der heutige Stand der Tech-nik im Bereich des Process Mining die Ableitungadäquater Geschäftsprozesse aus Logdaten er-möglicht. Dabei ist die Adaption der Vorgehens-weise und die Auswahl geeigneter Algorithmenausschlaggebend für die Qualität der Ergebnisse.Vor diesem Hintergrund beschäftigt sich der Bei-trag mit der praktischen Durchführung von Pro-cess Mining. Da die Einbindung weiterer Infor-mationsquellen bisher unbeachtet blieb, wirdinsbesondere versucht, Organisationswissen ge-winnbringend in den Prozess des Process Miningzu integrieren.

Inhaltsübersicht1 Ausgangssituation2 Vorgehensweise beim Process Mining3 Vorstellung der Fallstudie

3.1 Leginda3.2 Prozessbeschreibung3.3 Logdaten

4 Process Mining bei Leginda4.1 Erster Vorbearbeitungsschritt:

doppelte & versteckte Aktivitäten4.2 Zweiter Vorbearbeitungsschritt:

Rauschen & Ausführungsfehler4.3 Resultate der Vorbearbeitung4.4 Verarbeitung

5 Ergebnisse der Fallstudie6 Literatur

1 AusgangssituationProcess Mining ist heute in Wissenschaft undPraxis ein viel diskutiertes Thema. Es beschäf-tigt sich mit der Konstruktion und Visualisie-rung der in Unternehmen gelebten Geschäfts-prozesse auf Basis von Logdaten, die durch diebeteiligten Softwaresysteme bereitgestellt wer-

den. Verglichen mit den klassischen Ansätzender Prozesserhebung, die im Allgemeinen sehrzeit- und kostenintensiv sind, können Technikendes Process Mining in kurzer Zeit Prozessmodel-le auf einer objektiven Datenbasis generieren.

Unter dem Begriff Process Mining werdenallgemein verschiedene Anwendungsfeldersubsumiert [van der Aalst 2011]. Discovery be-schäftigt sich mit der Ableitung und Model-lierung von Geschäftsprozessen, währendConformance eine Überprüfung der Prozess-ausführung mit Blick auf bereits vorhandeneSollmodelle adressiert. Enhancement zielt aufdie Erweiterung von Prozessmodellen ab.

Es existieren bereits vielfältige Algorithmenund Techniken hinsichtlich der automatischenProzesserhebung. Dabei muss zwischen derProzessstrukturidentifikation, also der Erken-nung des Ablaufs eines bekannten Prozesses,und der Identifikation von Prozessen unter-schieden werden. Während die Prozessstruktur-identifikation von derzeitigen Algorithmen ge-zielt adressiert wird, wird die Identifikation vonProzessen auf Basis der zugrunde liegendenLogdaten wenig betrachtet – auch wird dieseProblematik in der Literatur bisher kaum expli-ziert. Vor diesem Hintergrund liegt das Ziel desvorliegenden Beitrags in der Demonstrationvon Process Discovery anhand einer Fallstudie.Am Beispiel der Online-ÜbersetzungsplattformLeginda, an der eine Vielzahl von Unternehmenaus verschiedenen Branchen beteiligt ist, wirdversucht, den Übersetzungsprozess im Sinnedes Discovery automatisiert zu identifizieren.Das zentrale Ziel liegt demzufolge in der Erlan-gung von Wissen über den tatsächlichen Pro-zessablauf – es soll geklärt werden, wie das Sys-tem von den beteiligten Institutionen genutztwird und welche Potenziale zur Weiterentwick-

Process Mining

HMD 293 57

lung bestehen. Während allerdings die klassi-schen Ansätze zum Process Mining allein aufLogdaten von Softwaresystemen arbeiten, wirdeine Adaption der Vorgehensweise durch die In-tegration von Organisationswissen vorgenom-men. Bisher wurden weitere Informationsquel-len für den Prozess des Process Mining nicht he-rangezogen.

2 Vorgehensweise beim Process Mining

Beim Process Mining werden grundlegend dreiPhasen [Romero & Ventura 2010] unterschie-den (vgl. Abb. 1). Bei der Vorbearbeitung wirddie Selektion und Harmonisierung der Logda-ten vorgenommen, sodass erst in der Verarbei-tungsphase der eigentliche Algorithmus zurAnwendung kommt und die grafische Visuali-sierung in Form eines Prozessmodells erfolgt. Ineiner Nachbearbeitungsphase können dannweitere Informationen, wie beispielsweise Pro-zesslaufzeiten, dem Modell annotiert werden.Für die Logdaten werden in der Literatur nahe-zu durchgängig die Anforderungen formuliert,dass jedes Ereignis auf (1) eine Aktivität und (2)eine Prozessinstanz verweist sowie (3) über ei-nen Initiator und (4) einen Zeitstempel verfügt[van der Aalst 2008].

Wie zu Beginn angemerkt soll Organisa-tionswissen in das Process Mining integriertund entsprechende Verfahren in der Vorbear-beitungsphase konzipiert werden. Zur Verarbei-tungsphase werden anschließend zwei unter-schiedliche Algorithmen herangezogen: der -Algorithmus [van der Aalst 2011] und der GeneticMiner [de Medeiros 2006; de Medeiros et al.

2007]. Der -Algorithmus dient einer Vielzahl wis-senschaftlicher Arbeiten zum Process Mining alsReferenz, sodass dieser Benchmark auch im vor-liegenden Kontext sinnvoll erscheint. Er verwen-det vier Ordnungsrelationen (direkter Nachfol-ger, Kausalität, Auswahl und Parallelität), die dienotwendigen Regeln zur Interpretation der Log-daten zur Verfügung stellen. Dadurch werdenalle im Log vorhandenen Verbindungen grafischabgebildet, während der Genetic Miner ver-sucht, das am besten auf die Mehrzahl der Pro-zessinstanzen passende Modell zu generieren.Genetische Algorithmen erstellen zufällig Varia-tionen von Prozessmodellen (Individuen), wor-aus eine Menge potenzieller Zielmodelle resul-tiert (Population). Die Individuen werden hin-sichtlich ihrer fitness untersucht, die aussagt,wie genau ein Prozessmodell die Logdaten re-präsentiert. Die Modelle mit den besten fitness-Werten dienen als Input für die nächste Iteration.Der Vorgang wird so lange wiederholt, bis einzuvor festgelegter fitness-Zielwert oder die An-zahl der maximalen Iterationen erreicht ist. Feh-lerhafte Prozessinstanzen, die meist durch selte-ne Prozesspfade gekennzeichnet sind, werdendadurch gezielt eliminiert.

Technisch können die genannten Phasenund die darin enthaltenen Aufgaben mit demOpen-Source-Werkzeug ProM [van Dongen etal. 2005] abgewickelt werden, das sich in denvergangenen Jahren als Standard im akademi-schen und kommerziellen Umfeld etabliert hat.Es besteht die Möglichkeit, neue Ansätze inForm von Plug-ins zu implementieren, die ge-nannten Algorithmen für die Verarbeitungs-phase sind bereits im Standardrepertoire vonProM vorhanden.

Vorbereitung Verarbeitung Nachbearbeitung

Abb. 1: Phasen des Process Mining

Process Mining

58 HMD 293

3 Vorstellung der Fallstudie

3.1 LegindaDie Leginda GmbH ist eine Kooperation desSoftwarehauses META-LEVEL Software AG mitdem Übersetzungsdienstleister Lector GmbH inSaarbrücken. Das System Leginda ist eine web-basierte und unternehmensübergreifende Über-setzungsplattform, die am 1. Januar 2008 alserste Plattform dieser Art in Deutschland star-tete und im März desselben Jahres mit dem In-novationspreis 2008 in der Kategorie Branchen-software ausgezeichnet wurde. An einem Über-setzungsfall sind darin drei zentrale Rollenbeteiligt – Kunde, Controller und Übersetzer –,wobei jede dieser Rollen durch verschiedeneUnternehmen vertreten wird.

3.2 ProzessbeschreibungEin Übersetzungsfall wird gestartet (create_translation_case), indem ein Kunde ein zu über-setzendes Dokument in das System lädt. DasSystem analysiert dieses Dokument und erstelltautomatisch ein Angebot, das dem Kunden an-gezeigt wird. Ist das Dokument nicht kalkulier-bar oder der Kunde mit dem Angebot nicht ein-verstanden, wird eine manuelle Kalkulation desControllers angefordert (request_calculation).Der Kunde kann das Angebot ablehnen, wo-durch der Geschäftsvorfall abgebrochen wird(cancel_case). Im ersten Fall erstellt der Control-ler ein neues Angebot und übermittelt diesesdem Kunden (offer_calculation). Der Kunde hatnun wieder die Möglichkeit, ein weiteres Ange-bot anzufordern oder das Angebot anzuneh-men (order_translation). Wurde die Überset-zung in Auftrag gegeben, führt der Controllereine Selektion von Übersetzern durch und bie-tet diesen den Geschäftsvorfall zu einem zuvorkalkulierten Entgelt an (offer_translation). So-lange kein Übersetzer den Auftrag angenom-men hat, kann der Controller das Angebot zu-rückziehen (withdraw_translation). Nimmt keinÜbersetzer den Auftrag an (reject_offer), wirddas Angebot überarbeitet und erneut angebo-

ten, andernfalls (accept_offer) wird der Überset-zer den Auftrag bearbeiten und ein Überset-zungsdokument ins System laden (do_translation).Der Controller prüft nun die Übersetzung undliefert diese an den Kunden (deliver_translation)bzw. verlangt Nachbesserung vom Übersetzer(reject_translation). In bestimmten Fällen kannder Controller die Lieferung zurückziehen(withdraw_translation). Automatisch wird beider Lieferung die Kundenrechnung generiertund dem Geschäftsvorfall angehängt. Der Kun-de kann die Lieferung nach eigener Prüfungakzeptieren (accept_delivery) oder zur Nachbes-serung zurück an den Controller leiten (reject_translation), der die Mängel durch den Überset-zer beheben lässt. Nach Auftragsabwicklungkann der Kunde die Abwicklung beurteilen(rate_case). Der Controller hat zu jedem Zeit-punkt die Möglichkeit, den Auftrag abzubre-chen.

3.3 LogdatenAus Gründen der Vertraulichkeit gegenüber Le-ginda sowie deren Geschäftspartnern und Kun-den werden nur anonymisierte Logdaten ausdem Leginda-System extrahiert. Diese wurdenso aufbereitet, dass statt der Namen der Initia-toren lediglich deren Stellen, also Kunde, Über-setzer oder Controller, festgehalten werden. Fürdie Fallstudie ist das unproblematisch, da imSystem jede Person genau eine Stelle besetzt.

Leginda unterliegt weiterhin einem steti-gen Entwicklungsprozess, innerhalb dessensich Software und Workflow ändern. Währenddes Betrachtungszeitraums wurden insgesamtdrei große Versionsupdates eingespielt, zu de-ren Betriebsaufnahme die Logdaten geteiltwurden. Dadurch soll geprüft werden, ob dieVersionsänderungen zu Änderungen des Über-setzungsprozesses geführt haben bzw. ob dieVersionsänderungen durch das Process Miningtransparent werden. Insgesamt wurden 1.955Prozessinstanzen, 11.019 Aktivitäten und 16 Akti-vitätstypen betrachtet.

Process Mining

HMD 293 59

4 Process Mining bei LegindaIm Folgenden wird zunächst auf die Integrationvon Organisationswissen in die Vorbearbei-tungsphase eingegangen. Es wird ein Organisa-tionsmodell vorgeschlagen, das das notwendi-ge Organisationswissen für die Durchführungder korrespondierenden Ansätze liefert. An-schließend wird die Verarbeitungsphase durch-laufen. Auf eine Nachbearbeitung wird verzich-tet, da in dieser Phase keine Änderung des ab-geleiteten Modells mehr erfolgt.

4.1 Erster Vorbearbeitungsschritt: doppelte & versteckte Aktivitäten

Doppelte und versteckte Aktivitäten sind zweizentrale Problemstellungen des Process Mi-ning. Doppelte Aktivitäten liegen vor, wenn un-terschiedliche Aktivitäten unter gleichem Na-men protokolliert werden. Von versteckten Ak-tivitäten wird gesprochen, wenn ausgeführteAktivitäten nicht in den Logdaten erfasst wer-den. Dies kann beispielsweise bei manuell aus-geführten Prozessschritten auftreten, die vomSoftwaresystem nicht berücksichtigt werden.

Zur Behandlung dieser Problemstellungenkann Organisationswissen wertvolle Beiträgeliefern. Jede Aufgabe innerhalb eines Prozessesstellt definierte Anforderungen an die ausfüh-renden Mitarbeiter, die in einem Organisations-modell als Qualifikationen festgehalten wer-den. Die Qualifikationen werden dann be-stimmten Rollen oder Mitarbeitern zugeordnet.

Betrachtet man Werkzeuge, die eine Kopplungvon Aufbau- und Ablauforganisation [Rose-mann & Zur Mühlen 1998] vornehmen, so istdavon auszugehen, dass die für die Ausführungeiner Aufgabe erforderlichen Qualifikationen ineiner Rolle gebündelt werden.

Dementsprechend wurde das Organisa-tionsmodell in Abbildung 2 entwickelt, das dienotwendigen Informationen für die Integrationvon Organisationswissen in das Process Miningliefert. Es existieren strukturierte Organisations-einheiten, denen wiederum strukturierteStellen zugeordnet sind. Stellen verfügen übereine beliebige Anzahl an Rollen und können vonbeliebig vielen Personen besetzt werden. Perso-nen können andere Personen in Rollen vertre-ten. In der Fallstudie repräsentieren Organisa-tionseinheiten die beteiligten Unternehmen,da am Leginda-System verschiedene Organisa-tionen am Übersetzungsprozess beteiligt sind.Stellen sind Kunde, Übersetzer und Controller,die jeweils über genau eine Rolle mit identi-schem Namen verfügen. Aufgrund der Anony-misierung wird als Person ebenfalls die Stelleangegeben.

Die minimale Menge an Rollen, die für dieAusführung einer Aktivität notwendig ist, kanndurch die Schnittmenge der Rollen der ausfüh-renden Mitarbeiter ermittelt werden. Ange-nommen die Aktivität accept_offer wird denLogdaten zufolge stets von den MitarbeiternJohn und Peter ausgeführt, wobei John die Rol-len Kunde und Übersetzer innehat, Peter die Rol-

Organisations-einheit Stelle

Rolle

Person

Ist unter-geordnet

Ist unter-geordnet

gehört zu

besitzt

besetzt

vertritt0,n 0,n

1,n0,n

0,n 0,n

0,n 0,n

0,n

0,n

0,n

0,n

0,n

Abb. 2: Verwendetes Organisationsmodell

Process Mining

60 HMD 293

len Übersetzer und Controller. Es kann darausgeschlossen werden, dass die Rolle Übersetzerfür die Ausführung von accept_offer obligato-risch ist. Kunde und Controller sind hingegennur bei jeweils einem der Mitarbeiter zu sehen(vgl. Abb. 3, Szenario 1). Man gewinnt Informa-tionen darüber, welche Rollen für die Ausführungeiner Aktivität notwendig sind, sodass eineKopplung von Aufbau- und Ablauforganisationim Zielmodell durch die Annotation der Rollenrealisiert wird.

Ein Szenario, in dem John ausschließlichKunde und Peter ausschließlich Controller ist(vgl. Abb. 3, Szenario 2), führt zu einer leerenRollenschnittmenge. Tritt dieser Fall häufig auf,kann davon ausgegangen werden, dass es sichbei der im Log dargestellten Aktivität cancel_case in der Realität um zwei unterschiedlicheAktivitäten handelt, da Mitarbeiter mit über-schneidungsfreien Qualifikationen faktisch nichtdieselben Aufgaben ausführen können.

4.2 Zweiter Vorbearbeitungsschritt: Rauschen & Ausführungsfehler

Zwei weitere Problemstellungen des ProcessMining sind Rauschen und Ausführungsfehler.Während der Protokollierung können Informa-tionen verloren gehen oder fehlerhaft erfasstwerden. Ebenso könnten für die Prozessausfüh-rung irrelevante Ereignisse, wie beispielsweiseprivate Telefonate, mitprotokolliert werden. Indiesen Fällen wird von Rauschdaten gespro-chen. Bei Ausführungsfehlern treten die Fehlerhingegen bei der Prozessausführung statt beider Protokollierung auf, wodurch Prozesse inef-fizient werden oder ihr Ziel verfehlen.

Durch die Verwendung von Organisations-wissen im Process Mining kann Rauschen nichtmehr nur in den Verlaufsdaten, sondern auch imOrganisationsmodell auftreten. Es könnte bei-spielsweise der Fall eintreten, dass Qualifikatio-nen oder Rollen fehlerhaft modelliert werden,was während des Process Mining zu Fehlinter-pretationen führen würde. Deshalb ist die Kor-rektheit des Organisationsmodells ausschlagge-bend für die Korrektheit des Output-Modells.

Gleichwohl kann Organisationswissen ei-nen erheblichen Beitrag zur Erkennung vonRauschdaten und Ausführungsfehlern leisten.Angenommen in den Logdaten existiert die Ak-tivität deliver_translation, die stets von Johnoder Peter ausgeführt wird. Die Schnittmengeder Rollen der beiden Mitarbeiter ist Übersetzer,sodass analog zum eben vorgestellten Szenario1 davon auszugehen ist, dass diese Rolle für dieAusführung von deliver_translation benötigtwird. Nun taucht in den Logdaten als Einzelfall(oder sehr selten) diese Aktivität mit dem Kun-den Anton als Initiator auf, dessen Rollen-schnittmenge mit {Übersetzer} die leere Mengeist (vgl. Abb. 3, Szenario 3). Da Anton nicht überdie Rolle Übersetzer verfügt, sind hier zwei Fällevorstellbar. Es kann sich um eine doppelte Akti-vität oder um Rauschen handeln. Da Antondeliver_translation nach den Verlaufsdaten nureinmal und damit sehr selten ausführt, ist Letz-teres deutlich wahrscheinlicher. Demnach ver-fügt Anton nicht über die Qualifikationen, umdeliver_translation auszuführen, was wiederumzwei mögliche Ursachen haben kann – es han-delt sich um einen Fehler in den Verlaufsdatenoder um einen Fehler im Organisationsmodell.

Rollen

Mitarbeiter

Aktivitäten

Kunde Übersetzer Controller

John Peter

accept_offer

Kunde Controller

John Peter

cancel_case

KundeÜbersetzer

John Peter Anton

deliver_translation

Szenario 1 Szenario 2 Szenario 3

Abb. 3: Beispielszenarien

Process Mining

HMD 293 61

In der Anwendung kann diese Rauschdatener-kennung über einen Parameter gesteuert wer-den. Es handelt sich dabei um einen prozentua-len Schwellenwert, der festlegt, ab wann eineminimale Rollenschnittmenge als Rauschen zuinterpretieren ist. Die Vorkommnisse dieser mi-nimalen Rollenschnittmenge werden dabei insVerhältnis zur Anzahl der Vorkommnisse derkorrespondierenden Aktivität gesetzt. Die alsRauschen interpretierten Fälle steigen damittendenziell mit dem Wert des Parameters. Sol-che Schwellenwerte wurden bereits erfolgreichbei diversen Ansätzen zum Process Mining ein-gesetzt (z.B. [Cook & Wolf 1998]).

4.3 Resultate der VorbearbeitungDie erläuterten Ansätze werden nun auf dieVerlaufsdaten der Leginda-Versionen 1, 2 und 3angewendet. Um die Funktion der Rauschda-tenerkennung sichtbar zu machen, wird dies inzwei Varianten durchgeführt – ohne Rauschda-tenparameter und mit einem Rauschdatenpa-rameter von exemplarisch 3 %. Denkbar sinddurchaus auch höhere Werte, wobei berück-sichtigt werden muss, dass dadurch korrekte,aber selten auftretende Prozessinstanzen ver-nachlässigt werden können. Der Wert des Para-meters sollte deshalb stets in Abhängigkeit derLogdaten gewählt werden.

Leginda V1Bei der Vorbearbeitung der Logdaten wurden die 7Aktivitäten create_translation_case, order_trans-lation, accept_offer, do_translation, accept_delivery,cancel_case und request_ calculation als doppelteAktivitäten identifiziert und entsprechend umbe-nannt (0 bzw. 1 als Suffix). Eine Verwendung desRauschdatenparameters mit 3 % führte hingegenzu einem signifikant anderen Ergebnis – es wur-den lediglich zwei doppelte Aktivitäten erkannt –do_translation und cancel_case. Einige Prozessin-stanzen, die die übrigen 5 Aktivitäten enthalten,wurden aufgrund von Rauschen aus den Logda-ten entfernt, wodurch diese Aktivitäten nichtmehr als doppelt interpretiert wurden.

Eine Rücksprache mit der Leginda GmbHhat ergeben, dass zu Testzwecken eine Ent-wicklerrolle im System existierte, die alle ande-ren Rollen annehmen kann. Des Weiteren stell-te sich heraus, dass es einem Controller nichtmöglich ist, die Aktivitäten create_case, order_translation, accept_offer, accept_delivery oderrequest_calculation auszuführen. Fehlerhafter-weise wurden bei Testaufträgen, die durch dieEntwicklerrolle durchlaufen wurden, alle Aktivi-täten unter der Stelle Controller protokolliert,wodurch es sich nachweislich um Rauschdatenhandelt.

Leginda V2Das Ergebnis der Vorbearbeitung auf die Logda-ten von Version 2 weist im Vergleich zu Version1 einige Änderungen auf. Es fällt auf, dass keinUnterschied zwischen den Operationen derAusführungsvarianten mit und ohne Rauschda-tenerkennung erkennbar ist. Seitens Legindakonnte dies durch den Wegfall der Entwickler-rolle in Version 2 begründet werden, worausimplizit die Behebung des identifizierten Feh-lers resultiert. Eine Übereinstimmung der aus-geführten Operationen über alle bisher durch-geführten Vorbearbeitungen kann in der Identi-fizierung doppelter Aktivitäten bei do_translation und cancel_case gefunden werden.

Leginda V3Die durchgeführten Operationen der Vorbear-beitung über die Logdaten der Version 3 entspra-chen exakt denen der Version 2. Es konnten dem-zufolge in der Vorbearbeitungsphase keine wei-teren Workflowänderungen identifiziert werden.

4.4 VerarbeitungDie Verarbeitungsphase wurde sowohl für dieOriginal-Logdaten als auch für die vorbearbei-teten Logdaten mit Rauschdatenerkennung inden Leginda-Versionen 1 und 3 durchgeführt.Version 2 wurde aufgrund der marginalen Un-terschiede zur Version 3 in der Vorbearbeitungnicht betrachtet.

Process Mining

62 HMD 293

Leginda V1Der -Algorithmus führt bei den originalen Log-daten zu einem übersichtlichen Modell, wäh-rend die Anwendung auf die vorbearbeitetenLogdaten die Modellgröße signifikant erhöht(um den Faktor 2, vgl. Tab. 1). Es fällt auf, dassdie Aktivität offer_translation separat und nichtim Modell verankert dargestellt wird, obwohlsie in einem Großteil der Prozessinstanzen vor-handen ist. Gleiches gilt für die Aktivitätenreject_offer_by_all_translators und reject_offer,allerdings treten diese verhältnismäßig seltenauf. Darüber hinaus werden Senken (=Prozess-abschlüsse) erkannt, die in der Realität nichtexistieren (bspw. do_translation und withdraw_delivery). Auch andere Aktivitäten, wie bei-spielsweise order_translation, werden als Sen-ken dargestellt und entsprechen damit wederden Erwartungen noch den Logdaten.

Betrachtet man die durch den GeneticMiner abgeleiteten Modelle, so erkennt mandurchgängig kleinere und damit übersichtliche-re Modelle. Auch hier werden Aktivitäten au-ßerhalb des Prozesses modelliert, gleichwohlsind die abgeleiteten Prozesse insgesamt präzi-ser und spiegeln eher den realen Prozess wider,als es beim -Algorithmus der Fall ist. Lediglichdie Aktivität withdraw_delivery wird separatmodelliert. Als Senke tritt nur cancel_case1 auf.

Das abgeleitete Modell aus den vorbearbei-teten Logdaten liegt nahe am realen Prozess.Die Aktivitäten treten in der korrekten Reihen-folge auf, jedoch sind einige Kanten, wie bei-spielsweise von accept_offer zu offer_translation,unklar. Dies könnte auf einen Fehler hindeuten,was im Anschluss untersucht werden muss. Er-kennbar sind die alternativen Vorgehensweisenbei do_translation und cancel_case. Aus demModell geht die zusätzliche Information hervor,dass ausschließlich cancel_case1 (Abbruchdurch den Controller) zu einem tatsächlichenAbbruch des Geschäftsvorfalls führt, wohinge-gen cancel_case0 (Ausführung durch Kunde) ei-ner Angebotsablehnung entspricht.

Leginda V3Beim -Algorithmus zeigt sich, dass dieser nurbedingt für die Anwendung auf Echtdaten ge-eignet ist. Durch die Repräsentation der gesam-ten Logdaten wird das resultierende Petrinetz(vgl. Abb. 4a,b) bereits mit einer geringen An-zahl an Aktivitäten äußerst komplex, was einevisuelle Analyse erschwert.

Aufgrund der selektiven Arbeitsweise desGenetic Miner konnte dieser intuitivere Ergeb-nisse liefern. Entsprechend der Prozessbe-schreibung liegen die Modelle sehr nahe an derRealität (vgl. Abb. 4c). Das auf den vorbearbeite-ten Logdaten basierende Modell stellt die Un-terschiede zwischen do_translation0 (Control-ler) und do_translation1 (Übersetzer) dar. DasModell zeigt außerdem Abhängigkeiten desnachfolgenden Verhaltens zu diesen Aktivitä-ten (vgl. Abb. 4c). Demnach wird in der direktenNachfolge eine Übersetzung nur dann zurück-gegeben (reject_translation), wenn sie durch ei-nen Übersetzer ins System geladen wurde(do_ translation1). Dies erscheint plausibel, dabei do_translation0 der Controller selbst dieÜbersetzung ins System lädt und damit auchvor dem Abschluss von do_translation0 daraufEinfluss nehmen kann. Es ist zu vermuten, dasstrotz der fehlenden Kante von do_translation0zu reject_translation, reject_translation als ver-steckter Task in do_translation0 ausgeführtwird.

5 Ergebnisse der FallstudieEs wurde gezeigt, dass die Vorbearbeitung ent-scheidende Beträge für die Erkennung vonRauschdaten liefert. Da dafür Organisations-wissen verwendet wird, handelt es sich bei demAnsatz um den derzeit einzigen, der in der Lageist, diese Art von Rauschen zu erkennen. Weiter-hin liefert die Vorbearbeitung Informationen,die die Fehlersuche innerhalb des Logging-Mechanismus und der Software unterstützen – ne-ben der Logdatenbereinigung werden demnachauch Hinweise zur Fehlerdiagnose generiert.

Process Mining

HMD 293 63

Durch die getrennte Analyse der Versionen 1, 2und 3 konnten aus der Vorberechnung eben-falls Informationen über den Entwicklungsver-lauf des Leginda-Systems abgeleitet werden.Der Übergang von Version 1 auf 2 zeigte konkretden Wegfall von Rauschdaten, während beimÜbergang von Version 2 zu 3 keine Änderungenam Workflow identifiziert werden konnten.

In allen Vorbearbeitungen wurden dieTasks do_translation und cancel_case als dop-pelt identifiziert, was sich nach Rücksprachemit der Leginda GmbH als korrekt herausstellte.Do_translation wurde einerseits von Überset-zern, andererseits von Controllern durchge-führt, woraus eine Umbenennung in do_translation0 (Controller) und do_translation1(Übersetzer) resultierte. Es wurde festgestellt,

dass do_translation1 den (korrekten) Fall kenn-zeichnet, in dem der Übersetzer die Überset-zung vornimmt und ins System lädt. Im Gegen-satz dazu kennzeichnet do_translation0 einSzenario, in dem der Übersetzer die Überset-zung durchführt, diese jedoch am System vor-bei an den Controller übermittelt, der die Über-setzung anschließend in das System lädt.

Cancel_case wurde in den Verlaufsdaten vonControllern und Kunden ausgeführt und demzu-folge in cancel_case0 (Kunde) und cancel_case1(Controller) umbenannt. Während cancel_case0einer Ablehnung des Übersetzungsangebotsdurch den Kunden entspricht (Abbruch des Ge-schäftsfalls), handelt es sich bei cancel_case1 umeinen Abbruch durch einen Controller, was unter-schiedliche Gründe haben kann. Beispielsweise

Abb. 4: Abgeleitete Prozessmodelle (Screenshots ProM)

Process Mining

64 HMD 293

könnte der Fall eintreten, dass kein Übersetzerfür die Bearbeitung des Auftrags verfügbar war.

Da Logdaten die Basis für die Verarbeitungbilden, hat die Vorbearbeitung signifikanteAuswirkungen auf das abgeleitete Prozessmo-dell. Da doppelte Aktivitäten a priori erkanntund behandelt wurden, können diese in geeig-neter Weise berücksichtigt und im resultieren-den Modell abgebildet werden. Durch die eben-falls vorher entfernten Rauschdaten wurdenkritische Prozessinstanzen entfernt, wodurchUnstimmigkeiten im Hinblick auf die Zuord-nung doppelter Aktivitäten bereinigt wurden.

Es wurde festgestellt, dass der -Algorithmussehr schnell, also bereits bei wenigen Aktivitä-ten, sehr große und schwer lesbare Modelleproduziert, was mitunter auf die fehlende Be-handlung von Rauschdaten zurückzuführen ist.Der Genetic Miner liefert hingegen intuitivereErgebnisse, wobei die korrekte und vollständigeAbbildung der Logdaten nicht garantiert ist.

Die Qualität der Process-Mining-Ergebnissehängt demnach in hohem Maße von der Vorge-hensweise und der Konfiguration der Algorith-men ab. Neben dem Rauschdatenparameterexistieren auch umfangreiche Parametrisie-

rungsmöglichkeiten bei den Algorithmenselbst. Der Genetic Miner (vgl. Abschnitt 2) er-laubt neben der Festlegung des fitness-Zielwertsund der maximalen Anzahl an Iterationen diver-se weitere Einstellungen, auf die hier nicht wei-ter eingegangen wird (in der Fallstudie wurdendie Standardeinstellungen gewählt). Emp-fehlungen für eine adäquate Parametrisierungunterschiedlicher Algorithmen existieren bis-lang nicht. Es muss außerdem berücksichtigtwerden, dass die verwendeten Algorithmen le-diglich die Prozessstruktur bekannter Prozesseidentifizieren. Es bleibt zu untersuchen, wie diebisherigen Algorithmen bei der Verwendungfür die Identifikation unbekannter Prozesseauf Basis von Logdaten reagieren.

Zusammenfassend kann festgehalten wer-den, dass Process-Mining-Techniken bereitsheute adäquate Ergebnisse bei der Prozesser-kennung liefern. Es konnte nachgewiesen wer-den, dass auch andere Wissensquellen, im vor-liegenden Fall Organisationswissen, gewinn-bringend in das Process Mining integriertwerden können. Gleichwohl existiert eine Reiheungenutzter Potenziale, die durch Wissenschaftund Praxis weiter bearbeitet werden sollten.

Leginda-Version * 1 3

Algorithmus -Algorithmus Genetic Miner -Algorithmus Genetic Miner

Vorbearbeitung wurde durchgeführt

nein ja nein ja nein ja nein ja

Aktivitäten ** 16 18 16 18 16 18 16 18

Aktivitätsübergange *** 28 70 22 32 80 104 26 29

Größe **** 44 88 38 50 96 122 42 47

Petrinetz * Aufgrund der marginalen Unterschiede zur Version 3 in der Vorbearbeitung wird Version 2 nicht betrachtet

Activity Graph ** Bei Petrinetz: Transitionen, bei Activity Graph: Aktivitäten

*** Bei Petrinetz: 1 Übergang = Kante-Stelle-Kante, bei Activity Graph: Kanten

**** Größe = Aktivitäten + Aktivitätsübergänge [Gruhn et al. 2006]

Tab. 1: Zusatzinformationen zu den abgeleiteten Prozessmodellen

Process Mining

HMD 293 65

6 Literatur[Cook & Wolf 1998] Cook, J. E.; Wolf, A.: Discovering

Models of Software Processes from Event-BasedData. ACM Transactions on Software Enginee-ring and Methodology 7 (1998), 3, pp. 215-249.

[de Medeiros 2006] de Medeiros, A. K. A.: GeneticProcess Mining. Dissertation, CIP-Data LibraryTechnische Universität Eindhoven, 2006.

[de Medeiros et al. 2007] de Medeiros, A. K. A.;Weijters, A. J. M. M.; van der Aalst, W. M. P.:Genetic process mining: an experimental evalu-ation. Data Mining and Knowledge Discovery 14(2007), 2, pp. 245-403.

[Gruhn et al. 2006] Gruhn, V.; Laue, R.; Meyer, F.:Berechnung von Komplexitätsmetriken für er-eignisgesteuerte Prozessketten. Geschäftspro-zessmanagement mit Ereignisgesteuerten Pro-zessketten (EPK2006), Wien, Österreich, 2006.

[Romero & Ventura 2010] Romero, C.; Ventura, S.:Educational data mining: a review of the state ofthe art. IEEE Transaction of Systems, Man, andCybernetics, Part C 40 (2010), 6, pp. 601-618.

[Rosemann & Zur Mühlen 1998] Rosemann, M.;Zur Mühlen, M.: Modellierung der Aufbauorga-nisation in Workflow-Management-Systemen:Kritische Bestandsaufnahme und Gestaltungs-vorschläge. EMISA Forum. Mitteilungen derGI-Fachgruppe Entwicklungsmethoden für Infor-mationssysteme und deren Anwendung. Bonn, In-stitut für Wirtschaftsinformatik der WestfälischenWilhelms-Universität Münster, 1998, S. 78-86.

[van der Aalst 2008] van der Aalst, W. M. P.: DecisionSupport Based on Process Mining. In: Burstein,F.; Holsapple, C. W.: Handbook on Decision Sup-port Systems 1. Basic Themes. Springer-Verlag,Berlin, Heidelberg, 2008, pp. 637-657.

[van der Aalst 2011] van der Aalst, W. M. P.: ProcessMining: Discovery, Conformance and Enhance-ment of Business Processes. Springer-Verlag,Berlin, Heidelberg, 2011.

[van Dongen et al. 2005] van Dongen, B.; de Medeiros, A. K. A.;Verbeek, H.; Weijters, A. J. M. M.; van der Aalst,W. M. P.: The ProM Framework: A New Era inProcess Mining Tool Support. Applications andTheory of Petri Nets 2005 (ICATPN 2005), LNCS3536. Springer-Verlag, Berlin, 2005, pp. 444-454.

Tom Thaler M.Sc.PD Dr. Peter FettkeProf. Dr. Peter LoosDeutsches Forschungszentrum für künstliche Intelligenz (DFKI)Institut für Wirtschaftsinformatik (IWi)Stuhlsatzenhausweg 366123 Saarbrücken{tom.thaler, peter.fettke, peter.loos}@iwi.dfki.dehttp://iwi.dfki.de

Thaler, T.; Fettke, P.; Loos, P.: Process Mining – Fallstudie leginda.de. HMD – Praxis der Wirtschaftsinformatik 50 (2013), 293, S. 56-65.