Kwaliteit en lifecyclemanagement van eventlogs

Kwaliteit en lifecyclemanagement van eventlogs
Kwaliteit van eventlogs is vaak een probleem bij de toepassing van process mining. Een mogelijke oplossing is aandacht voor lifecyclemanagement van eventlogs bij de ontwikkeling en aanpassing van informatiesystemen en bedrijfsprocessen.
Maria Haasnoot-Bezverhaya
Uit praktijkervaring met de toepassing van process mining komt duidelijk naar voren dat de data in de informatiesystemen vaak niet geschikt is voor process-mininganalyse. De data is niet in het systeem te vinden, is van slechte kwaliteit of moeilijk te verkrijgen. Soms zijn de benodigde velden niet ingevuld of niet in het systeem geactiveerd. Hierdoor is het onmogelijk om een eventlog van goede kwaliteit te verkrijgen.
 
Lessons learned
Een van de belangrijkste aandachtspunten bij de toepassing van process mining is de kwaliteit van de gelogde data. Binnen de Rijksoverheid is een aantal projecten met process mining uitgevoerd. De belangrijkste lessen en aandachtspunten uit deze onderzoeken zijn [Haasnoot, 2012]:
• Een kant-en-klaar eventlog is niet altijd beschikbaar;
• Het is vaak lastig de benodigde data te vinden;
• Data is niet altijd volledig of is van slechte kwaliteit: ontbrekend, incorrect, onnauwkeurig, niet relevant;
• Event-namen zijn soms niet consequent;
• Aanpassingen in het systeem achteraf zijn vaak duur en complex;
• Een eventlog kan meerdere varianten van een proces bevatten, ‘concept drift’ [Bose, 2013].
 
Beschikbaarheid eventlog
Sommige systemen, zoals bijvoorbeeld het SAP-systeem, hebben geen kant-en-klaar eventlog van een bepaald proces dat voor process-mininganalyse geschikt is. De data over de processen is opgeslagen in de verschillende tabellen van het systeem en de processtappen (events) zijn niet gedefinieerd. Bovendien is vaak het tijdstip van de events niet geregistreerd in het systeem. In dit geval moet de onderzoeker zelf de data uit verschillende tabellen combineren, de events definiëren en indien mogelijk aannames doen over de niet geregistreerde tijdstippen. Het kan ook zijn dat een proces via een aantal systemen verloopt. In dit geval is de unieke sleutel (case-id) van belang en het is belangrijk dat deze sleutel in alle systemen en tabellen aanwezig en uniek is. Al deze bovengenoemde ‘obstakels’ openbaarden zich bij de analyse van een inkoopproces dat in SAP is geïmplementeerd. Hierdoor was het voorbereiden van data en het opstellen van de eventlog tijdrovend en arbeidsintensief.
 
Vinden van juiste data
In een (ERP-)systeem is het vaak lastig om de data te vinden die voor process mining nodig is. Bijvoorbeeld tijdens de analyse van het inkoopproces in het SAP-systeem is in eerste instantie voor datum en tijdstip van een van de events het standaardveld in het systeem gebruikt. Later
bleek dat een ander maatwerkveld de juiste registratie voor dit event bevat, maar deze informatie was nergens gedocumenteerd en was alleen bij een bepaalde systeembeheerder bekend. Een ander voorbeeld is ontbrekende of slechte documentatie over de inrichting van de processen, zoals dit bijvoorbeeld het geval was bij de analyse van een subsidieproces dat via een workflow in het SAP-systeem verloopt.
 
Datakwaliteit
De data in de informatiesystemen is vaak niet volledig of van onvoldoende kwaliteit om process mining te kunnen toepassen. Dat wil zeggen, als de data handmatig ingevuld moet worden, ontstaan soms typefouten (zoals bijvoorbeeld een handmatig ingevulde datum ‘12-02-1900’) of worden velden overgeslagen (bijvoorbeeld bij verplichte velden vullen de medewerkers alleen een spatie in in plaats van een verplichte tekst). Data kan ook ontbreken, incorrect, onnauwkeurig en niet relevant zijn. In de context van een eventlog kunnen deze problemen spelen bij onder andere cases, events, activiteiten en tijdstippen. Bij ontbrekende of onjuiste cases kan het gevolg zijn dat bepaalde relevante project paden niet in de analyse zichtbaar worden of verkeerd worden geclassificeerd. Bij ontbrekende, onjuiste of onnauwkeurige tijdstippen is het gevolg dat de precieze volgorde van stappen niet bepaald kan worden en ‘oorzaak-en-gevolg-analyses’ niet betrouwbaar zijn.
 
Event-namen niet consequent
Uit een andere analyse van een factuurverwerkingsproces dat via een workflow in SAP verloopt, kwam naar voren dat een aantal processtappen dezelfde betekenis hadden, maar deze waren op verschillende manieren beschreven, zoals bijvoorbeeld ‘factuur in de wacht gezet’ en ‘factuur in wacht gezet’ (zonder ‘de’); ‘creditnota geboekt’ en ‘credit nota geboekt’ (los van elkaar geschreven). Deze verschillen waren niet gedocumenteerd en niemand binnen de organisatie kon de verschillen met zekerheid toelichten. Uiteindelijk bleek dat de events wel bij verschillende typen deelprocessen hoorden.
 
Aanpassingen in het systeem
Sommige SAP-tabellen, die bijvoorbeeld workflow-data bevatten, zijn enorm groot: circa een miljoen transacties per dag en zijn hierdoor niet te downloaden. Maar voor process mininganalyse is deze informatie heel belangrijk. Om deze data toch te kunnen verkrijgen is voor het factuurverwerkingsproces een verzoek binnen de organisatie ingediend om een overzichtelijke rapportage ten behoeve van de process-mininganalyse te maken. Dit wijzigingsverzoek moest een duur en langdurig changemanagementtraject doorlopen en na een aantal maanden kon uiteindelijk de process mining-analyse worden doorgevoerd. Dit voorbeeld geeft aan dat aanpassingen achteraf in het systeem heel tijdrovend (en daarom kostbaar) kunnen zijn.
 
Concept drift
Naast de eerder genoemde dataproblemen zijn ook proceseigenschappen van invloed op de bruikbaarheid van de eventlog. De evolutie en de veranderingen van processen bepalen of op basis van de eventlog een bruikbare procesanalyse kan worden gedaan. Wanneer een eventlog meerdere varianten van een proces bevat, omdat het proces in de loop van de tijd is aangepast, kan dit tot gevolg hebben dat een onjuist en ten onrechte complex procesmodel wordt ontdekt (figuur 1) . In de literatuur wordt dit ook wel aangeduid met ‘concept drift’ [Bose, 2013].
Figuur 1. Illustratie van concept drift
 
Volwassenheidsniveau’s eventlogs
Het Process Mining Manifest behandelt kwaliteit van data en van eventlogs en definieert een model voor de volwassenheidsniveau’s van eventlogs. Dit model onderscheidt vijf verschillende volwassenheidsniveau’s: het laagste niveau hebben de eventlogs van slechte kwaliteit, die handmatig geregistreerd zijn, waarbij ‘de geregistreerde eventlogs niet overeenkomen met de werkelijkheid en events kunnen ontbreken’. De eventlogs van het hoogste niveau zijn van excellente kwaliteit, dat wil zeggen dat de events duidelijk gedefinieerd , betrouwbaar en compleet zijn [Aalst, 2012]. Bepalen van het volwassenheidsniveau van de eventlogs is belangrijk om te kunnen beoordelen welke verbeteringen in het systeem en/of in het proces uitgevoerd moeten worden. Figuur 2 toont een voorbeeld van een eventlog van slechte/matige kwaliteit van het factuurverwerkingsproces in SAP:
• Attributen zoals wie de activiteit heeft uitgevoerd is onderdeel van een ‘string tekst’, de attributen zijn niet apart gecodeerd;
• Activiteiten hebben verschillende schrijfwijzen: bijvoorbeeld ‘in wacht gezet’ versus ‘in de wacht gezet’;
• Tijdstip is niet gelogd, alleen de datum, hierdoor is de volgorde niet goed te bepalen;
Figuur 2: Eventlog van het factuurverwerkingsproces uit het systeem die nog niet voor process mining geschikt is
 
Om deze eventlog voor process mining toch te kunnen gebruiken, moest een aanvullende slag uitgevoerd worden om de activiteiten en attributen te splitsen (figuur 3) . Dit is een bewerkte, verbeterde eventlog maar deze is nog niet optimaal. Om tijdregistratie en consistente naamgeving door te voeren zijn in dit geval aanpassingen in het systeem zelf nodig.
Figuur 3: De aangepaste eventlog van het factuur- verwerkingsproces die voor process mining geschikt is
 
Mogelijke oplossing
Een mogelijke oplossing voor de genoemde ‘obstakels’ is, om al over de toepassing van process mining na te denken in de vroege fase van de ontwikkeling van de informatiesystemen en bedrijfsprocessen, namelijk in de analyse- en ontwerpfase. Als de registratie van data op een zorgvuldige manier wordt ingericht en uitgevoerd, produceert het systeem eventlogs van hoge kwaliteit en kunnen betrokkenen de bedrijfsprocessen en -systemen (eventueel continu) controleren en analyseren. Samenwerking van process-miningdeskundigen en het design/ development-team, en vervolgens het implementatieteam is belangrijk om tot een betere inrichting van de eventlogs te komen [Haasnoot, 2013]. Binnen de Rijksoverheid krijgt de voor procesanalyse benodigde data in de beginfase van de ontwikkeling en implementatie van de systemen steeds meer aandacht. Bij sommige Rijksoverheidorganisaties zijn reeds de eerste stappen gezet om toepassing van process mining bij de ontwikkeling van de systemen mee te nemen. Een voorbeeld hiervan is een nieuw systeem voor ketenbeheer waarbij eventlogs worden ingericht vanuit process-miningperspectief.
 
Lifecyclemanagement eventlogs
Lifecyclemanagement is belangrijk voor de ontwikkeling van nieuwe systemen, maar is ook relevant voor reeds bestaande systemen om ervoor te zorgen dat alle aanpassingen in systemen ook goed in de eventlog worden verwerkt. In principe loopt de implementatie van eventlogs gelijk op met de implementatie van een informatiesysteem. Hieronder volgt een korte beschrijving van de fases en aandachtspunten voor hoe de kwaliteit van de eventlog het beste gewaarborgd kan worden (figuur 4) .
Figuur 4. Lifecyclemanagement van een eventlog
 
Fase 1: Vooronderzoek en eisenanalyse
In deze fase bepaalt men de eisen voor de opzet van het eventlog. Basis hiervoor is de benodigde stuurinformatie van het proces en de key performance indicators. Om het proces en systeem voor te bereiden op toekomstige analyse met behulp van process-miningtechnieken is het belangrijk uitgangspunten te formuleren voor het detailniveau van de definitie van processtappen (events) en requirements op te stellen ten aanzien van volledigheid, juistheid, nauwkeurigheid (en relevantie) van de data die voor een eventlog (en voor toekomstige analyse) noodzakelijk is. Het is hierbij aan te raden om vanaf het begin event-gerelateerde data als ‘first class citizens’ te behandelen om zo problemen met betrekking tot datakwaliteit te voorkomen [Aalst, 2012].
Fase 2: Ontwerp
De eisen uit het vooronderzoek bepalen welke data opgeslagen moet worden. In deze fase wordt het ontwerp van de eventlog en van het logging-mechanisme in het systeem gemaakt. Het is bijzonder belangrijk om het ontwerp goed te documenteren om in de latere fasen gemakkelijk inzicht te krijgen in de opzet en werking van de eventlog en de relatie tussen de in het systeem opgeslagen gegevens en de gegevens in de eventlog. Door het ontwerp in de (centrale) architectuur-repository op te nemen en de data-aspecten in een (meta)data-dictionary te beschrijven, kan men ervoor zorgen dat het ontwerp toegankelijk blijft in de latere (gebruiks)fasen. En men kan tijdrovende en kostbare reverse engineering en mogelijke fouten door misverstanden over de opzet voorkomen.
Fase 3: Bouw en testen
Nadat de eventlog in het systeem volgens het ontwerp is gebouwd kan de eventlog worden getest op de functionele en niet-functionele specificaties. Men dient te testen of de eventlog conform het ontwerp is opgezet, of deze correct wordt gevuld en of deze voor de testdata en testtransacties voldoet aan de opgestelde eisen met betrekking tot datakwaliteit. Indien bepaalde aanpassingen nodig zijn, is het eenvoudiger en minder kostbaar om deze door te voeren voordat het systeem ‘live’ gaat.
Fase 4: Implementatie
Bij het implementeren van de eventlog is het van belang ook de technische metadata, zoals locatie van de fysieke bestanden en eventuele configuratieparameters, zodanig vast te leggen dat deze toegankelijk zijn bij analyses en bij aanpassingen aan het systeem.
Fase 5: Changemanagement
Het is essentieel dat men bij wijzigingen en aanpassingen aan het systeem (bijvoorbeeld in de vorm van maatwerk naar aanleiding van een RFC) kijkt naar de impact op de eventlog. Wijzigingen in het systeem en in het proces moeten correct in de eventlog worden meegenomen. Anders geeft de eventlog niet de werkelijke werking van het systeem (of proces) weer en is het proces niet controleerbaar. Hier blijkt ook het belang van goede documentatie van het ontwerp en het vastleggen van de opzet van de eventlog in de systeem- en data-architectuur en in een (meta)data-dictionary. Deze aanpassingen moeten uiteraard ook in de documentatie worden verwerkt. Behalve dat dit nodig is voor toekomstige aanpassingen kan het ook bruikbaar zijn bij process-mininganalyses om te bepalen wat de systeem/procesaanpassingen waren in een bepaald tijdvak of wat een geschikt tijdvak voor analyse is.
 
Aandacht voor documentatie en metadata
In de beschrijving van de verschillende fases is aangegeven dat documentatie van het ontwerp en het vastleggen van metadata over de eventlog belangrijk is. Met metadata worden in dit geval zaken als naamgeving, definitie, structuur, betekenis van velden, tabellen en coderingen, relaties tussen data-elementen en naamgeving/locatie van fysieke opslagbestanden bedoeld. Wanneer deze informatie up-to-date is en snel toegankelijk, zijn impact-analyses bij aanpassingen gemakkelijk te maken. Bij proces-miningonderzoek kan men dan eenvoudig inzicht krijgen in welke data waar in welke vorm beschikbaar is. Zonder deze documentatie zou bij elke aanpassing en bij elk process-miningonderzoek deze data eerst verzameld en achterhaald moeten worden. Dit zou tijdrovend en kostbaar zijn. De kans op fouten door verkeerde interpretatie zou vergroten en in sommige gevallen zelfs onmogelijk zijn. Als bijvoorbeeld de benodigde kennis niet meer binnen de organisatie of bij medewerkers aanwezig is.
 
Bewustwording en verantwoordelijkheden
Om lifecylemanagement van eventlogs goed vorm te geven zal men zich binnen de organisatie bewust moeten worden van het belang en de voordelen ervan. Door verantwoordelijkheid hiervoor expliciet bij bepaalde medewerkers te beleggen, en de bijbehorende richtlijnen en procedures op te stellen (en deze ook te monitoren), kan men ervoor zorgen dat een systeem en proces controleerbaar blijft conform de geldende eisen ten aanzien van controleerbaarheid.
 
Kwaliteitsaspecten van eventlogs
Om de kwaliteit van de eventlogs te kunnen beoordelen, heb ik een referentiekader voorgesteld (figuur 5) . Met deze kwaliteitsaspecten zou men rekening moeten houden bij de ontwikkeling van de eventlog en deze aspecten zouden in de testfase van de implementatie van de eventlog getest moeten worden [Haasnoot, 2013]. De beoordeling van de eventlogs kan ook periodiek na de implementatie uitgevoerd worden, bijvoorbeeld door IT-auditors, om de zekerheid te geven dat de kwaliteit van de eventlog nog steeds voldoet aan de eisen.
 
Figuur 5. Het referentiekader voor de beoor- deling van de kwaliteit van de eventlog
 
Tot slot
Problemen omtrent de kwaliteit van data en eventlogs kunnen worden opgelost door betere documentatie van ontwerp en aanpassingen, lifecyclemanagement van eventlogs, en door niet achteraf, maar al in de vooronderzoek-/ontwerpfase van systeemontwikkeling aandacht te besteden aan de registratie van procesgerelateerde data. In de vooronderzoek-/ontwerpfase is het relatief goedkoop om eventlogging (en voorbereiding op process mining) goed mee te nemen en te documenteren. De betrokkenen moeten in deze fase immers toch al het proces in detail uitwerken en de processtappen goed definiëren. Deze stappen later uitvoeren zal vaak duurder uitvallen. Dan moet namelijk opnieuw procesanalyse worden uitgevoerd, benodigde ontwerpdocumentatie worden verzameld, benodigde kennis worden opgebouwd, impact-analyses voor systeemwijzigingen gedaan worden et cetera. In een ongunstig geval zijn de kosten om later aanpassingen uit te voeren zelfs zeer hoog omdat ontwerpdocumentatie niet meer toegankelijk is of up-to-date, en kennis van de technische werking van het systeem niet meer in de organisatie aanwezig is. Wanneer het eventlog in het begin al goed is ingericht en wordt bijgehouden (en goed gedocumenteerd) kan process mining in de complete levenscyclus van het proces worden gebruikt om het proces te controleren (en te optimaliseren).
 
Maria Haasnoot-Bezverhaya MSc. EMITA RE Haasnoot-Bezverhaya is werkzaam als informatiemanager bij het College ter Beoordeling van Geneesmiddelen (het agentschap van het ministerie van VWS). Daarvoor heeft zij vijf jaar als IT-auditor bij de departementale Auditdienst Rijk (ADR) van het ministerie van Financiën gewerkt. Ze heeft verschillende publicaties over process mining op haar naam staan. Ook geeft zij regelmatig lezingen en advies over dit onderwerp. Haar interesse gaat vooral uit naar process mining, softwarekwaliteit, IT-governance, projectmanagement, informatiebeveiliging en naar de Wet bescherming persoonsgegevens (Wbp). E-mail: ma.haasnoot@cbg-meb.nl
 
Literatuur Haasnoot-Bezverhaya M.A. (2012), Lessons learned bij toepassing van process mining. De IT-Auditor, nummer 2 Haasnoot-Bezverhaya M.A. (2013), Controleerbaarheid en kwaliteit van event logs. De IT-Auditor, nummer 2 Bose R.P. (2013), Wanna Improve Process Mining Results? Van der Aalst (2012), Process Mining Manifest
 

Tag

Onderwerp



Niet gevonden? Vraag het de redactie!

Heeft u het antwoord op uw vraag niet gevonden, of bent u op zoek naar specifieke informatie? Laat het ons weten! Dan zorgen we ervoor dat deze content zo snel mogelijk wordt toegevoegd, of persoonlijk aan u wordt geleverd!

Stel uw vraag