Överensstämmelsekontroll
Överensstämmelsekontroll av affärsprocesser ( förkortat alias överensstämmelsekontroll ) är en familj av processutvinningstekniker för att jämföra en processmodell med en händelselogg för samma process. Den används för att kontrollera om det faktiska utförandet av en affärsprocess , som registrerats i händelseloggen, överensstämmer med modellen och vice versa.
Det kan till exempel finnas en processmodell som indikerar att inköpsorder på mer än en miljon euro kräver två kontroller. Analys av händelseloggen kommer att visa om denna regel följs eller inte.
Ett annat exempel är kontrollen av den så kallade " fyraögon"-principen som säger att vissa aktiviteter inte ska utföras av en och samma person. Genom att skanna händelseloggen med en modell som anger dessa krav kan man upptäcka potentiella fall av bedrägeri . Därför kan överensstämmelsekontroll användas för att upptäcka, lokalisera och förklara avvikelser och för att mäta hur allvarliga dessa avvikelser är.
Översikt
Överensstämmelsekontrolltekniker tar som indata en processmodell och händelselogg och returnerar en uppsättning skillnader mellan beteendet som fångas i processmodellen och beteendet som fångas i händelseloggen. Dessa skillnader kan representeras visuellt (t.ex. överlagrade ovanpå processmodellen) eller textuellt som listor över naturliga språkuttalanden (t.ex. aktivitet x utförs flera gånger i loggen, men detta är inte tillåtet enligt modellen). Vissa tekniker kan också ge ett normaliserat mått (mellan 0 och 1) som indikerar i vilken utsträckning processmodellen och händelseloggen matchar varandra.
Tolkningen av avvikelse beror på syftet med modellen:
- Om modellen är tänkt att vara beskrivande indikerar avvikelser mellan modell och logg att modellen behöver förbättras för att fånga verkligheten bättre.
- Om modellen är normativ kan sådana avvikelser tolkas på två sätt: de kan avslöja oönskade avvikelser (dvs. kontroll av överensstämmelse signalerar behovet av bättre kontroll av processen). eller kan avslöja önskvärda avvikelser (dvs. arbetare kan avvika för att betjäna kunderna bättre eller för att hantera omständigheter som inte förutses av processmodellen).
Tekniker
Syftet med överensstämmelsekontroll är att identifiera två typer av avvikelser:
- Opassande loggbeteende: beteende observerat i loggen som inte tillåts av modellen.
- Ytterligare modellbeteende: beteende tillåtet i modellen men aldrig observerat i loggen.
Det finns i stort sett tre familjer av tekniker för att upptäcka olämpligt loggbeteende: uppspelning, spåranpassning och beteendeanpassning.
I omspelningstekniker spelas varje spår upp mot processmodellen en händelse i taget. När ett uppspelningsfel upptäcks rapporteras det och en lokal korrigering görs för att återuppta uppspelningsproceduren. Den lokala korrigeringen kan till exempel vara att hoppa över/ignorera en uppgift i processmodellen eller att hoppa över/ignorera en händelse i loggen.
En allmän begränsning av uppspelningsmetoder är att felåterställning utförs lokalt varje gång ett fel påträffas. Därför kanske dessa metoder inte identifierar det minsta antalet fel som kan förklara det olämpliga loggbeteendet. Denna begränsning åtgärdas genom tekniker för spåruppriktning . Dessa senare tekniker identifierar, för varje spår i loggen, det närmaste motsvarande spår som kan analyseras av modellen. Spåruppriktningstekniker beräknar också en inriktning som visar divergenspunkterna mellan dessa två spår. Utgången är en uppsättning par av justerade spår. Varje par visar ett spår i loggen som inte exakt matchar ett spår i modellen, tillsammans med motsvarande närmaste spår som produceras av modellen.
Spårjusteringstekniker hanterar inte explicit samtidiga uppgifter eller cykliskt beteende (upprepning av uppgifter). Om till exempel fyra uppgifter bara kan förekomma i en fast ordning i processmodellen (t.ex. [A, B, C, D]), men de kan förekomma samtidigt i loggen (dvs i valfri ordning), kan denna skillnad inte upptäckas direkt av spårjustering, eftersom den inte kan observeras på nivån för individuella spår.
Andra metoder för att identifiera ytterligare beteende är baserade på negativa händelser. Dessa metoder börjar med att förbättra spåren i loggen genom att infoga falska (negativa) händelser i alla eller några spår av loggen. En negativ händelse infogas efter ett givet prefix av ett spår om denna händelse aldrig observeras föregås av det prefixet någonstans i loggen.
Till exempel, om händelse C aldrig observeras efter prefix AB, kan C infogas som en negativ händelse efter AB. Därefter spelas loggen förstärkt med negativa händelser upp mot processmodellen. Om processmodellen kan spela upp de negativa händelserna betyder det att det finns ett beteende fångat i processmodellen som inte fångas i loggen (eftersom de negativa händelserna motsvarar beteenden som aldrig observeras i loggen).
Anmärkningsvärda algoritmer
Jämföra fotavtrycksmatriser
Footprint-matriser visar orsaksberoendet för två aktiviteter i en händelselogg, t.ex. om aktivitet a i en händelselogg följs av aktivitet b i alla spår men aktivitet b följs aldrig av b. Mot denna typ av beroende deklareras en lista med ordningsrelationer :
Låt L vara en händelselogg kopplad till listan A över alla aktiviteter. Låt a, b vara två aktiviteter i A.
- a ᐳ L b om och endast om det finns ett spår σ i L, i vilket mönstret (a, b) förekommer.
- a → L b om och endast om a ᐳ L b och inte b ᐳ L a.
- a # L b om och endast om inte a ᐳ L b och inte b ᐳ L a.
- en || L b om och endast om a ᐳ L b och b ᐳ L a.
För en processmodell kan en sådan matris även härledas ovanpå exekveringssekvenserna genom att använda play-out-tekniken. Därför, baserat på footprint-matriserna, kan man resonera att om en händelselogg överensstämmer med en betraktad processmodell, är de två footprint-matriserna som representerar loggen och modellen identiska, dvs. de beteenden som registreras i modellen (i detta fall är orsaksberoende) visas minst en gång i händelseloggen.
Exempel : Låt L vara: {<a, b>, <a, c, d> } och en modell M av L . Antag att de två matriserna är följande:
| a | b | c | d | |
|---|---|---|---|---|
| a | # | → | → | # |
| b | ← | # | # | # |
| c | ← | # | # | → |
| d | # | # | ← | # |
| a | b | c | d | |
|---|---|---|---|---|
| a | # | → | → | → |
| b | ← | # | # | # |
| c | ← | # | # | → |
| d | ← | # | ← | # |
Vi kan märka att i fotavtrycksmatrisen för modell M tillåts mönstret (a, d) att förekomma, och därför orsakar det en avvikelse i jämförelse med händelseloggen. Lämpligheten mellan händelseloggen och modellen beräknas enligt följande:
I det här exemplet är konditionen .
Token-replay-teknik
Token-baserad replay är en teknik som använder 4 räknare (producerade tokens, konsumerade tokens, saknade tokens och återstående tokens) för att beräkna lämpligheten för ett observationsspår baserat på en given processmodell i Petri-net-notation. Dessa 4 räknare registrerar tokens status när ett spår spelas om på Petri-nätet. När en token produceras av en övergång, ökas producerade tokens med 1. När en token förbrukas för att avfyra en övergång , ökas förbrukade tokens med 1. När en token saknas för att avfyra en övergång, ökas saknade tokens med 1. Återstående tokens registrerar det totala antalet återstående tokens efter att spårningen är klar. Spårningen överensstämmer med processmodellen om och endast om det inte saknas tokens under repriset och inga återstående tokens i slutet.
Lämpligheten mellan en händelselogg och en processmodell beräknas enligt följande:
tokens , c är antalet förbrukade tokens, r är antalet återstående tokens, p är antalet producerade tokens.
Inriktningar
Även om token-replay-tekniken är effektiv och lätt att förstå, är tillvägagångssättet utformat för Petri net-notation och tar inte hänsyn till den lämpliga vägen som genereras av modellen för de olämpliga fallen. Justeringar infördes för att lösa begränsningarna och anses vara en mycket noggrann teknik för kontroll av överensstämmelse och kan användas för alla processmodelleringsnotationer. Tanken är att algoritmen utför en uttömmande sökning för att ta reda på den optimala anpassningen mellan det observerade spåret och processmodellen. Därför kommer det garanterat att ta reda på den mest relaterade modellen som körs i jämförelse med spåret.
- ^ Wil van der Aalst (2013). Process Mining: Upptäckt, överensstämmelse och förbättring av affärsprocesser . Springer.
- ^ Carmona, Josep; Dongen, Boudewijn van; Solti, Andreas; Weidlich, Matthias (2018-11-11). Överensstämmelsekontroll: relatera processer och modeller . Springer. ISBN 978-3-319-99414-7 .
- ^ Rozinat, Anne; van der Aalst, Wil (2008). "Konformitetskontroll av processer baserad på övervakning av verkligt beteende". Informationssystem . 33 (1): 64–95. doi : 10.1016/j.is.2007.07.001 .
- ^ Adriansyah, Arya (2014). Justera observerat och modellerat beteende (PhD-avhandling). Eindhovens tekniska universitet.
- ^ vanden Broucke, Seppe KLM; De Weerdt, Jochen; Vanthienen, Jan; Baesens, Bart (2014). "Bestämma processmodellprecision och generalisering med vägda konstgjorda negativa händelser" . IEEE-transaktioner på kunskaps- och datateknik . 26 (8): 1877–1889. doi : 10.1109/TKDE.2013.130 . S2CID 14365893 .
- ^ van der Aalst, Wil (2016), van der Aalst, Wil (red.), "Data Science in Action" , Process Mining: Data Science in Action , Berlin, Heidelberg: Springer, s. 3–23, doi : 10.1007 /978-3-662-49851-4_1 , ISBN 978-3-662-49851-4 , hämtad 2021-08-12
- ^ Rozinat, A.; van der Aalst, WMP (mars 2008). "Konformitetskontroll av processer baserad på övervakning av verkligt beteende" . Informationssystem . 33 (1): 64–95. doi : 10.1016/j.is.2007.07.001 . ISSN 0306-4379 .
- ^ van der Aalst, Wil; Adriansyah, Arya; van Dongen, Boudewijn (2012-01-30). "Återspela historia på processmodeller för överensstämmelsekontroll och prestandaanalys" . WIREs Data Mining och Knowledge Discovery . 2 (2): 182–192. doi : 10.1002/widm.1045 . ISSN 1942-4787 . S2CID 11294562 .