![\"\"](\"https:\/\/agilos.nl\/wp-content\/uploads\/2026\/07\/1-raw-data-1024x682.png\")
<\/figure>\n\nOrganisaties hebben toegang tot meer operationele data dan ooit tevoren. Applicaties registreren statuswijzigingen, gebruikersacties, transacties, tijdstempels, systeemberichten en processtappen. In theorie cre\u00ebert dit een rijke basis voor business intelligence, process mining, workforce analytics en kunstmatige intelligentie. <\/p>\n\n
In de praktijk zijn operationele data meestal veel minder bruikbaar dan verwacht.<\/p>\n\n
Een technisch record kan volledig accuraat zijn, terwijl het toch bijna geen betekenis heeft voor een analist of proceseigenaar. Een gebeurtenis zoals ZSTAT_07, STATUS_UPDATE of ROUTE_SYS_03 kan precies beschrijven wat een applicatie heeft geregistreerd, maar legt nog niet uit wat er daadwerkelijk in de bedrijfsvoering is gebeurd. <\/p>\n\n
Dit is gebaseerd op zes publicaties (deze publicaties benaderen datavoorbereiding vanuit verschillende perspectieven, maar hun gezamenlijke conclusie is consistent:<\/p>\n\n
Betrouwbare operationele analyses kunnen niet worden gecre\u00eberd door simpelweg ruwe systeemgegevens in een analytisch platform te laden.<\/p>\n\n
De data moet eerst worden gerepareerd, gereconstrueerd, ge\u00efnterpreteerd en verbonden met de realiteit van de organisatie.<\/p>\n\n
![\"\"](\"https:\/\/agilos.nl\/wp-content\/uploads\/2026\/07\/2-articles.png\")
<\/figure>Ruwe data is geen kant en klare analyse data. Het is gewoon ruwe data met mogelijkheden. <\/strong><\/h2>\n\n\n\nDaar ligt de ware grens van datakwaliteit.<\/p>\n\n\n\n
Zes wetenschappelijke publicaties over datakwaliteit, eventlog-extractie en process mining beschrijven gezamenlijk wat nodig is om operationele data geschikt te maken voor betrouwbare analyse. Hun bevindingen tonen aan dat datavoorbereiding geen eenvoudige technische preprocessingstap is. Het is een gestructureerd proces van het repareren, ontdekken, verbinden, interpreteren en valideren van data. <\/p>\n<\/div><\/div>\n\n
\nDatakwaliteit start niet in het dashboard<\/strong><\/h2>\n\n\n\nWanneer analytics onjuiste, onvolledige of onverklaarbare resultaten oplevert, zoeken organisaties vaak naar de oorzaak in het dashboard, het process-miningmodel of het algoritme.<\/p>\n\n\n\n
Wanneer analytics onjuiste, onvolledige of onverklaarbare resultaten oplevert, zoeken organisaties vaak naar de oorzaak in het dashboard, het process-miningmodel of het algoritme.<\/p>\n\n\n\n
Wanneer analytics onjuiste, onvolledige of onverklaarbare resultaten oplevert, zoeken organisaties vaak naar de oorzaak in het dashboard, het process-miningmodel of het algoritme.<\/p>\n\n\n\n
Maar het probleem begint meestal veel eerder.<\/p>\n\n\n\n
De brongegevens kunnen bevatten:<\/p>\n\n\n\n
\n- dubbele of onvolledige records;<\/li>\n\n\n\n
- identificaties die veranderen tussen systemen of procesfasen;<\/li>\n\n\n\n
- waardevolle informatie verborgen in technische tekstvelden;<\/li>\n\n\n\n
- gebeurtenissen zonder herkenbare zakelijke betekenis;<\/li>\n\n\n\n
- verschillende niveaus van granulariteit;<\/li>\n\n\n\n
- gefragmenteerde records van meerdere applicaties;<\/li>\n\n\n\n
- ontbrekende context over gebruikers, klanten, producten of casussen.<\/li>\n<\/ul>\n\n\n\n
Een dashboard kan deze problemen niet oplossen. Een aantrekkelijke visualisatie maakt onbetrouwbare informatie alleen overtuigender. Een AI-model kan niet betrouwbaar relaties reconstrueren die nooit expliciet zijn gemaakt in de onderliggende data. <\/p>\n\n\n\n
Voor operationele analyse moet de datakwaliteit daarom worden beoordeeld op meer dan alleen volledigheid en technische correctheid. De gegevens moeten ook zijn: <\/p>\n\n\n\n
Geldig:<\/strong> Het moet aantoonbaar aansluiten op en de daadwerkelijke bedrijfsvoering vertegenwoordigen.<\/p>\n\n\n\nWaardevol:<\/strong> Het moet inzichten bieden die mensen kunnen gebruiken om beslissingen te nemen en actie te ondernemen.<\/p>\n\n\n\nNauwkeurig:<\/strong> De resulterende informatie moet het vertrouwen verdienen van de mensen die ervan afhankelijk zijn.<\/p>\n\n\n\nSamen bepalen deze eigenschappen het verschil tussen data die slechts beschikbaar is en data die echt nuttig is.<\/p>\n<\/div>![\"\"](\"https:\/\/agilos.nl\/wp-content\/uploads\/2026\/07\/2-data-quality-724x1024.png\")
<\/figure><\/div>\n\n![\"\"](\"https:\/\/agilos.nl\/wp-content\/uploads\/2026\/07\/1-repairing.png\")
<\/figure>\n1. Het herstellen van technische inconsistenties en imperfecties<\/strong><\/a><\/h2>\n\n\n\nOperationele data is zelden schoon, consistent en compleet wanneer deze voor het eerst beschikbaar komt.<\/p>\n\n\n\n
Velden kunnen leeg zijn. Namen kunnen op verschillende manieren worden geschreven. Kolommen kunnen meerdere waarden bevatten. Gegevenstypen kunnen vari\u00ebren tussen bronnen. Hetzelfde evenement kan meer dan eens zijn geregistreerd. <\/p>\n\n\n\n
Dit is de meest bekende vorm van datakwaliteitsherstel. Het omvat activiteiten zoals: <\/p>\n\n\n\n
\n- het verwijderen van dubbele records;<\/li>\n\n\n\n
- het corrigeren en standaardiseren van waarden;<\/li>\n\n\n\n
- het splitsen of combineren van kolommen;<\/li>\n\n\n\n
- het verwijderen van irrelevante archieven;<\/li>\n\n\n\n
- het invullen van ontbrekende waarden;<\/li>\n\n\n\n
- standaardisatieformaten en naamgevingsconventies.<\/li>\n<\/ul>\n\n\n\n
Deze transformaties zijn noodzakelijk, maar ze zijn slechts het begin.<\/p>\n\n\n\n
Een opgeschonen technische code blijft een technische code. De plaat kan consistenter worden zonder betekenisvoller te worden. <\/p>\n\n\n\n
Binnen de Evidant Data Transform Raffinaderij kunnen deze correcties worden uitgevoerd met componenten zoals de kolomschoonmaker<\/strong>, rijextractor<\/strong> en rijvuller<\/strong>. In tegenstelling tot een eenmalig opruimscript blijven de transformatieregels zichtbaar, testbaar, herhaalbaar en onderhoudbaar. <\/p>\n\n\n\n<\/p>\n<\/div><\/div>\n\n
\n2. Het ontdekken van bedrijfsinformatie in technische verzamelingen<\/strong><\/a><\/h2>\n\n\n\n<\/p>\n\n\n\n
Waardevolle informatie wordt niet altijd gemakkelijk opgeslagen in een speciale kolom.<\/p>\n\n\n\n
Een case-ID kan verborgen zijn in een URL. Een activiteit is mogelijk alleen herkenbaar aan een combinatie van woorden in een auditspoor. Een applicatielogboek kan tientallen technische elementen bevatten, terwijl slechts een klein deel van het record nuttige zakelijke informatie biedt. <\/p>\n\n\n\n
De gegevens moeten daarom eerst worden onderzocht:<\/p>\n\n\n\n
\n- Welke delen van een document bevatten zakelijke betekenis?<\/li>\n\n\n\n
- Hoe kunnen identifiers uit technische tekst worden gehaald?<\/li>\n\n\n\n
- Welke patronen geven een activiteit of statusverandering aan?<\/li>\n\n\n\n
- Welke technische details kunnen veilig worden verwijderd?<\/li>\n\n\n\n
- Welke elementen moeten worden behouden voor latere interpretatie?<\/li>\n<\/ul>\n\n\n\n
Dit is niet zomaar een inname-taak. Het is een vorm van dataontdekking. <\/p>\n\n\n\n
De Ingest Nodes en <\/strong>Row Extractor van de DTR <\/strong> maken het mogelijk om informatie uit lange strings, applicatielogs, URL’s en andere technische velden te extraheren en deze in herkenbare attributen te plaatsen.ens bruikbaar worden voor operationele analyse..<\/p>\n\n\n\n<\/p>\n<\/div>![\"\"](\"https:\/\/agilos.nl\/wp-content\/uploads\/2026\/07\/2-discovering.png\")
<\/figure><\/div>\n\n![\"\"](\"https:\/\/agilos.nl\/wp-content\/uploads\/2026\/07\/3-correlating-682x1024.png\")
<\/figure>\n3. Het correleren van gebeurtenissen met de juiste case-id of procesinstantie<\/strong><\/a><\/h2>\n\n\n\nEen individueel evenement heeft beperkte analytische waarde wanneer onduidelijk is waartoe dat evenement behoort.<\/p>\n\n\n\n
Voor process mining moet elk event normaal gesproken gekoppeld zijn aan een case, order, claim, pati\u00ebnt, klant, gebruiker of procesinstantie. Binnen \u00e9\u00e9n applicatie kan er een duidelijke case-ID bestaan. Zodra meerdere systemen betrokken zijn, komen organisaties de vertrouwde verzameling incompatibele sleutels, inconsistente definities en identificaties tegen die halverwege een proces veranderen. <\/p>\n\n\n\n
Correlatie van case-id\u2019s is daarom een van de moeilijkste onderdelen van het construeren van een betrouwbaar gebeurtenislogboek.<\/p>\n\n\n\n
Een proces kan beginnen onder \u00e9\u00e9n identificatie, later worden verdeeld in meerdere subgevallen en uiteindelijk worden afgerond onder een andere identificatie. Een analyse die alleen op de uiteindelijke ID is gebaseerd, kan verschillende afzonderlijke processen tonen waarbij de organisatie daadwerkelijk \u00e9\u00e9n verbonden werksequentie uitvoerde. <\/p>\n\n\n\n
DTR reconstrueert deze relaties met componenten zoals:<\/p>\n\n\n\n
\n- Group Attributor<\/strong>, voor het herkennen en corrigeren van groepen van gerelateerde gebeurtenissen;<\/li>\n\n\n\n
- Column Lookup <\/strong>voor het toevoegen van attributen uit andere datasets;<\/li>\n\n\n\n
- Farm Joiner<\/strong>, voor het combineren van gebeurtenissen uit verschillende databronnen;<\/li>\n\n\n\n
- Join-IDs<\/strong>, om consistente relaties tussen datafarms te cre\u00ebren.<\/li>\n<\/ul>\n\n\n\n
Het resultaat is niet langer slechts een verzameling tijdgestempelde gegevens. Het wordt een verbonden weergave van wat er binnen een zaak, proces of operationele context is gebeurd.n voor operationele analyse.. <\/p>\n\n\n\n
<\/p>\n<\/div><\/div>\n\n
\n4. Het vertalen van technische gebeurtenissen naar herkenbare activiteiten<\/a><\/strong><\/h2>\n\n\n\nEen informatiesysteem registreert wat het systeem doet.<\/p>\n\n\n\n
De organisatie wil begrijpen wat haar mensen, teams en processen doen.<\/p>\n\n\n\n
Dat onderscheid is fundamenteel.<\/p>\n\n\n\n
Technische evenementen zoals ITEM_CREATE, SAVE_FORM_04 en ROUTE_SYS_03 kunnen gezamenlijk \u00e9\u00e9n herkenbare bedrijfsactiviteit vertegenwoordigen: Klantaanvraag beoordelen. Zonder semantische vertaling blijft de analyse gevangen op het niveau van applicatiegedrag. <\/p>\n\n\n\n
Deze vertaling van technische registraties naar betekenisvolle zakelijke concepten wordt doorgaans omschreven als semantische abstractie<\/strong>.<\/p>\n\n\n\nDTR ondersteunt het cre\u00ebren van deze semantische laag via componenten zoals:<\/p>\n\n\n\n
\n- Evenementnaamgever;<\/strong><\/li>\n\n\n\n
- Groepsnaam voor evenementen<\/strong>;<\/li>\n\n\n\n
- Activiteitsnaamgever<\/strong><\/li>\n<\/ul>\n\n\n\n
Deze transformers zoeken naar patronen, actie-objectcombinaties en groepen van gerelateerde gebeurtenissen. Ze kunnen vervolgens herkenbare namen toewijzen zoals: <\/p>\n\n\n\n
\n- Order goedkeuren;<\/li>\n\n\n\n
- Herzieningsclaim;<\/li>\n\n\n\n
- Route Case;<\/li>\n\n\n\n
- Betaling verifi\u00ebren;<\/li>\n\n\n\n
- Werk klantgegevens bij.<\/li>\n<\/ul>\n\n\n\n
Dit cre\u00ebert een gedeelde taal tussen de data en de organisatie.<\/p>\n\n\n\n
Dat is aanzienlijk nuttiger dan een dashboard vol mysterieuze systeemcodes waarvan de betekenis alleen bekend is bij de ontwikkelaar die het bedrijf twee jaar geleden heeft verlaten.<\/p>\n\n\n\n
<\/p>\n<\/div>![\"\"](\"https:\/\/agilos.nl\/wp-content\/uploads\/2026\/07\/4-translating-682x1024.png\")
<\/figure><\/div>\n\n![\"\"](\"https:\/\/agilos.nl\/wp-content\/uploads\/2026\/07\/5-granularity.png\")
<\/figure>\n5. Het cre\u00ebren van het juiste niveau van granulariteit<\/strong><\/h2>\n\n\n\nMeer detail is niet automatisch beter.<\/p>\n\n\n\n
Een applicatie kan honderden technische gebeurtenissen genereren voor \u00e9\u00e9n menselijke handeling. Wanneer al deze gebeurtenissen afzonderlijk in een procesmodel worden opgenomen, is het resultaat meestal een onleesbaar spaghettidiagram. <\/p>\n\n\n\n
Aan het andere uiterste kunnen te hoog geaggregeerde gegevens belangrijke verschillen tussen taken en activiteiten verbergen.<\/p>\n\n\n\n
Het juiste detailniveau hangt af van de analytische vraag.<\/p>\n\n\n\n
Technische probleemoplossing kan event-level data vereisen. Workforce analytics kan taken vereisen. Procesanalyse profiteert meestal van herkenbare bedrijfsactiviteiten. <\/p>\n\n\n\n
De data moet daarom veranderingen in granulariteit ondersteunen:<\/p>\n\n\n\n
Subtaken \u2192 taken \u2192 activiteiten<\/strong><\/p>\n\n\n\nDe DTR Farm Converter<\/strong> verzamelt gebeurtenissen tot het vereiste analytische niveau. De onderliggende details kunnen behouden blijven voor een diepgaande analyse, terwijl de hoofdstructuur duidelijker en beter begrijpelijk wordt. <\/p>\n\n\n\nHet resultaat is niet simpelweg minder data. Het is beter georganiseerde data. <\/p>\n\n\n\n
Dat is aanzienlijk nuttiger dan een dashboard vol mysterieuze systeemcodes waarvan de betekenis alleen bekend is bij de ontwikkelaar die het bedrijf twee jaar geleden heeft verlaten.<\/p>\n\n\n\n
<\/p>\n<\/div><\/div>\n\n
\n<\/p>\n\n\n\n
6. Domeinkennis onderdeel maken van de transformatie<\/strong><\/a><\/h2>\n\n\n\nData kan niet onafhankelijk bepalen wat een bedrijfsactiviteit betekent.<\/p>\n\n\n\n
Een algoritme kan patronen ontdekken, maar het weet niet automatisch:<\/p>\n\n\n\n
\n- wanneer een activiteit echt begint of eindigt;<\/li>\n\n\n\n
- welke uitzonderingen operationeel van belang zijn;<\/li>\n\n\n\n
- of verschillende technische codes dezelfde handeling vertegenwoordigen;<\/li>\n\n\n\n
- of een ontbrekende identificatie redelijkerwijs kan worden aangevuld;<\/li>\n\n\n\n
- welke technische stappen samen \u00e9\u00e9n taak vormen;<\/li>\n\n\n\n
- of een veranderende zaak-ID nog steeds bij dezelfde werkervaring hoort.<\/li>\n<\/ul>\n\n\n\n
Dat vereist kennis van mensen die de werking begrijpen.<\/p>\n\n\n\n
Hoogwaardige data-opbouw is daarom een samenwerkingsactiviteit tussen dataspecialisten, analisten en zakelijke professionals. Hun kennis mag niet beperkt blijven tot vergadernotities, specificatiedocumenten of het geheugen van \u00e9\u00e9n ervaren medewerker. <\/p>\n\n\n\n
Het moet worden vertaald naar expliciete transformatielogica.<\/p>\n\n\n\n
DTR maakt domeinkennis operationeel via configureerbare regels, datapreviews, rule-hit statistieken en iteratief testen. Aannames worden zichtbaar en kunnen worden onderzocht. <\/p>\n\n\n\n
Dit is belangrijk omdat sommige transformaties onvermijdelijk interpretatie vereisen.<\/p>\n\n\n\n
Het invullen van een ontbrekende zaak-ID op basis van tijdsnabijheid kan bijvoorbeeld aanzienlijke analytische waarde cre\u00ebren. Maar het resultaat moet gebaseerd zijn op een expliciete en toetsbare aanname, in plaats van onzichtbare logica die verborgen zit in aangepaste code. <\/p>\n\n\n\n
Transparante regels maken interpretatie beheersbaar.<\/p>\n\n\n\n
Verborgen regels maken fouten alleen maar moeilijker te vinden.<\/p>\n<\/div>![\"\"](\"https:\/\/agilos.nl\/wp-content\/uploads\/2026\/07\/6-domain-knowledge.png\")
<\/figure><\/div>\n\n![\"\"](\"https:\/\/agilos.nl\/wp-content\/uploads\/2026\/07\/7-data-quality-683x1024.png\")
<\/figure>\n7. Datakwaliteit is een proces, geen eenmalig opruimproject<\/strong><\/h2>\n\n\n\nTraditionele datavoorbereidingsprojecten produceren vaak een script, een exportbestand of een handmatig samengestelde dataset.<\/p>\n\n\n\n
Zes maanden later is de broncode veranderd, werkt de oorspronkelijke logica niet meer en niemand kan zich herinneren waarom bepaalde beslissingen zijn genomen.<\/p>\n\n\n\n
Betrouwbare datakwaliteit moet daarom herhaalbaar en onderhoudbaar zijn.<\/p>\n\n\n\n
Een nuttige dataraffinaderij:<\/p>\n\n\n\n
\n- verwerkt data in een gedefinieerde volgorde;<\/li>\n\n\n\n
- documenteert de regels die worden toegepast;<\/li>\n\n\n\n
- toont intermediate resultaten;<\/li>\n\n\n\n
- maakt uitzonderingen en mist meetbaar;<\/li>\n\n\n\n
- ondersteunt iteratieve tests;<\/li>\n\n\n\n
- kan worden aangepast wanneer systemen of processen veranderen;<\/li>\n\n\n\n
- herhaaldelijk dezelfde semantische structuur produceert uit nieuwe data.<\/li>\n<\/ul>\n\n\n\n
In dit model wordt de configuratie de documentatie van de transformatie. Niet een specificatiedocument dat ceremonieel wordt genegeerd na implementatie, maar uitvoerbare logica die zichtbaar en testbaar blijft <\/p>\n<\/div><\/div>\n\n
\n8. Het cre\u00ebren van \u00e9\u00e9n betrouwbare databasis voor meerdere vormen van analyse<\/strong><\/h2>\n\n\n\n<\/p>\n\n\n\n
Het doel is niet om nog een exportbestand te maken.<\/p>\n\n\n\n
Het doel is om een herbruikbare semantische dataset te cre\u00ebren die meerdere analytische toepassingen kan ondersteunen:<\/p>\n\n\n\n
\n- procesmijnbouw;<\/li>\n\n\n\n
- bedrijfsinlichtingen;<\/li>\n\n\n\n
- arbeidsmarktanalyse;<\/li>\n\n\n\n
- operationele prestatie-analyse;<\/li>\n\n\n\n
- nalevingsmonitoring;<\/li>\n\n\n\n
- Kunstmatige intelligentie en machine learning.<\/li>\n<\/ul>\n\n\n\n
DTR cre\u00ebert deze analyse-klare datafarms en levert deze aan databases, bestanden en analyseplatforms via configureerbare Data <\/strong>Writers.<\/p>\n\n\n\nDe interpretatie van de brondata hoeft daarom niet afzonderlijk opnieuw opgebouwd te worden voor elk dashboard, proces-mining platform of AI-project.<\/p>\n\n\n\n
Bouw \u00e9\u00e9n keer, consumeer overal.<\/strong> Dit vermindert meer dan alleen dubbele inspanning. Het zorgt ervoor dat verschillende analytische toepassingen dezelfde definities, relaties en zakelijke betekenis gebruikencumentatie van de transformatie. Niet een specificatiedocument dat ceremonieel wordt genegeerd na implementatie, maar uitvoerbare logica die zichtbaar en testbaar blijft <\/p>\n<\/div>![\"\"](\"https:\/\/agilos.nl\/wp-content\/uploads\/2026\/07\/8-multiple-analytics.png\")
<\/figure><\/div>\n\n<\/figure>\nVan ruwe registraties tot betrouwbare informatie<\/a><\/strong><\/h2>\n\n\n\n<\/h2>\n\n\n\n
Samen beschrijven de zes publicaties een herkenbare data-voorbereidingsreeks:<\/p>\n\n\n\n
repareren \u2192 extraheren \u2192 correleren \u2192 \u2192 aggregate interpreteren \u2192 \u2192 hergebruik valideren<\/strong><\/p>\n\n\n\nDeze volgorde transformeert technische systeemregistraties in geldige, waardevolle en nauwkeurige informatie.<\/p>\n\n\n\n
De Evidant Data Transform Raffinaderij vertaalt deze academische thema’s naar een operationele, testbare en herbruikbare dataraffinaderij.<\/p>\n\n\n\n
Het beweert niet dat datakwaliteit volledig geautomatiseerd kan worden. In plaats daarvan brengt het technologie, domeinkennis en transparante transformatieregels samen. <\/p>\n\n\n\n
Omdat betrouwbare analyses niet in het dashboard beginnen.<\/p>\n\n\n\n
Het begint met de vraag of de onderliggende data echt beschrijft wat de organisatie doet.<\/p>\n<\/div><\/div>\n\n
<\/p>\n\n
<\/p>\n\n
De zes publicaties achter dit perspectief<\/h2>\n\n
<\/p>\n\n
<\/p>\n\n
![\"\"](\"https:\/\/agilos.nl\/wp-content\/uploads\/2026\/07\/article-1.png\")
<\/figure>\n1. Proces-data kwaliteit: De ware grens van procesmining<\/a><\/h3>\n\n\n\nArthur H. M. ter Hofstede et al.<\/p>\n\n\n\n
Download de openbare PDF<\/a><\/p>\n\n\n\nDeze publicatie positioneert proces-datakwaliteit als een fundamentele uitdaging voor process mining en betoogt dat kwaliteit gedurende de volledige data- en analysecyclus moet worden meegenomen. Gebeurtenislogboeken in de praktijk bevatten aanzienlijke kwaliteitsproblemen die moeten worden ge\u00efdentificeerd en opgelost voordat zinvolle analyse mogelijk is, en slechte kwaliteit gebeurtenisdata verhindert dat process mining zijn volledige organisatorische impact bereikt. <\/p>\n\n\n\n
Waarom het belangrijk is voor DTR \u2014 <\/strong>Biedt de sterkste onafhankelijke validatie van DTR’s algemene propositie \u2014 de waarde van process mining hangt af van de kwaliteit van de gebeurtenisgegevens die eraan worden geleverd.<\/p>\n\n\n\nTR-mogelijkheden \u2014 Kolomschoonmaker, Row Extractor, Farm Joiner, Column Lookup, Results Dashboards en het semantische datafarmmodel.<\/p>\n<\/div><\/div>\n\n
\n2. Extractie, correlatie en abstractie van gebeurtenisgegevens voor process mining<\/h3>\n\n\n\n
Kiarash Diba, Kimon Batoulis, Matthias Weidlich en Mathias Weske<\/p>\n\n\n\n
Download de openbare PDF<\/a><\/p>\n\n\n\nDeze studie biedt een gestructureerd overzicht van de reis van ruwe brongegevens naar bruikbare gebeurtenislogs, met aandacht voor extractie, gebeurteniscorrelatie en semantische abstractie. Het kadert die reis als drie grote uitdagingen: het identificeren en extraheren van relevante data, het correleren van gebeurtenissen in procesinstanties, en het abstraheren van technische gebeurtenissen tot betekenisvolle procesconcepten. <\/p>\n\n\n\n
Waarom het belangrijk is voor DTR \u2014 <\/strong>Bijna een conceptueel blauwdruk voor DTR \u2014 het definieert het exacte upstreamgebied waarin DTR opereert: extractie, correlatie en abstractie.Relevante DTR-mogelijkheden \u2014 <\/strong>extractie via Row Extractor en Ingest Nodes; correlatie via Group Attributor, Farm Joiner en Join ID’s; abstractie via Event Namer, Event Group Namer, Activity Namer en Farm Converter<\/p>\n<\/div>![\"\"](\"https:\/\/agilos.nl\/wp-content\/uploads\/2026\/07\/article-2.png\")
<\/figure><\/div>\n\n![\"\"](\"https:\/\/agilos.nl\/wp-content\/uploads\/2026\/07\/article-3.png\")
<\/figure>\n3. Richting het begrijpen van de rol van de mens bij het extraheren van gebeurtenislogboeken<\/a><\/h3>\n\n\n\nVinicius Stein, Dani et al.<\/p>\n\n\n\n
Download de openbare PDF<\/a><\/p>\n\n\n\nDeze publicatie onderzoekt de essenti\u00eble rol van menselijke kennis en beoordeling bij het extraheren van gebeurtenislogboeken en laat zien waarom het opstellen van een gebeurtenislogboek niet als een puur technische oefening kan worden beschouwd. Het ontwikkelt een taxonomie van de menselijke activiteiten die betrokken zijn bij het extraheren van gebeurtenislogboeken en toont aan dat de voorbereidingsinspanningen die mensen verrichten \u2014 het verzamelen van gegevens uit verschillende databases en deze omzetten in een geschikt formaat \u2014 aanzienlijk is. <\/p>\n\n\n\n
Waarom het belangrijk is voor DTR \u2014 <\/strong>Ondersteunt DTR’s nadruk op samenwerking tussen dataspecialisten, operationele experts en analisten: het voorbereiden van gebeurtenislogboeken kan niet volledig losstaan van menselijke interpretatie en zakelijke kennis.<\/p>\n\n\n\nRelevante DTR-mogelijkheden \u2014 <\/strong>Visueel raffinaderijontwerp, regelgebaseerde configuratie, datapreviews, regel-hit statistieken, zelfdocumenterende transformaties en een gezamenlijk build-and-testproces.<\/p>\n<\/div><\/div>\n\n\n4. Patronen van onvolmaaktheid in gebeurtenislogboeken voor procesmijnbouw: Richting een systematische benadering van het schoonmaken van gebeurtenislogboeken<\/a><\/h3>\n\n\n\nSuriadi Suriadi, Robert Andrews, Arthur H. M. ter Hofstede en Moe Thandar Wynn<\/p>\n\n\n\n
Datakwaliteit start niet in het dashboard<\/strong><\/h2>\n\n\n\nWanneer analytics onjuiste, onvolledige of onverklaarbare resultaten oplevert, zoeken organisaties vaak naar de oorzaak in het dashboard, het process-miningmodel of het algoritme.<\/p>\n\n\n\n
Wanneer analytics onjuiste, onvolledige of onverklaarbare resultaten oplevert, zoeken organisaties vaak naar de oorzaak in het dashboard, het process-miningmodel of het algoritme.<\/p>\n\n\n\n
Wanneer analytics onjuiste, onvolledige of onverklaarbare resultaten oplevert, zoeken organisaties vaak naar de oorzaak in het dashboard, het process-miningmodel of het algoritme.<\/p>\n\n\n\n
Maar het probleem begint meestal veel eerder.<\/p>\n\n\n\n
De brongegevens kunnen bevatten:<\/p>\n\n\n\n
\n- dubbele of onvolledige records;<\/li>\n\n\n\n
- identificaties die veranderen tussen systemen of procesfasen;<\/li>\n\n\n\n
- waardevolle informatie verborgen in technische tekstvelden;<\/li>\n\n\n\n
- gebeurtenissen zonder herkenbare zakelijke betekenis;<\/li>\n\n\n\n
- verschillende niveaus van granulariteit;<\/li>\n\n\n\n
- gefragmenteerde records van meerdere applicaties;<\/li>\n\n\n\n
- ontbrekende context over gebruikers, klanten, producten of casussen.<\/li>\n<\/ul>\n\n\n\n
Een dashboard kan deze problemen niet oplossen. Een aantrekkelijke visualisatie maakt onbetrouwbare informatie alleen overtuigender. Een AI-model kan niet betrouwbaar relaties reconstrueren die nooit expliciet zijn gemaakt in de onderliggende data. <\/p>\n\n\n\n
Voor operationele analyse moet de datakwaliteit daarom worden beoordeeld op meer dan alleen volledigheid en technische correctheid. De gegevens moeten ook zijn: <\/p>\n\n\n\n
Geldig:<\/strong> Het moet aantoonbaar aansluiten op en de daadwerkelijke bedrijfsvoering vertegenwoordigen.<\/p>\n\n\n\nWaardevol:<\/strong> Het moet inzichten bieden die mensen kunnen gebruiken om beslissingen te nemen en actie te ondernemen.<\/p>\n\n\n\nNauwkeurig:<\/strong> De resulterende informatie moet het vertrouwen verdienen van de mensen die ervan afhankelijk zijn.<\/p>\n\n\n\nSamen bepalen deze eigenschappen het verschil tussen data die slechts beschikbaar is en data die echt nuttig is.<\/p>\n<\/div><\/figure><\/div>\n\n<\/figure>\n1. Het herstellen van technische inconsistenties en imperfecties<\/strong><\/a><\/h2>\n\n\n\nOperationele data is zelden schoon, consistent en compleet wanneer deze voor het eerst beschikbaar komt.<\/p>\n\n\n\n
Velden kunnen leeg zijn. Namen kunnen op verschillende manieren worden geschreven. Kolommen kunnen meerdere waarden bevatten. Gegevenstypen kunnen vari\u00ebren tussen bronnen. Hetzelfde evenement kan meer dan eens zijn geregistreerd. <\/p>\n\n\n\n
Dit is de meest bekende vorm van datakwaliteitsherstel. Het omvat activiteiten zoals: <\/p>\n\n\n\n
\n- het verwijderen van dubbele records;<\/li>\n\n\n\n
- het corrigeren en standaardiseren van waarden;<\/li>\n\n\n\n
- het splitsen of combineren van kolommen;<\/li>\n\n\n\n
- het verwijderen van irrelevante archieven;<\/li>\n\n\n\n
- het invullen van ontbrekende waarden;<\/li>\n\n\n\n
- standaardisatieformaten en naamgevingsconventies.<\/li>\n<\/ul>\n\n\n\n
Deze transformaties zijn noodzakelijk, maar ze zijn slechts het begin.<\/p>\n\n\n\n
Een opgeschonen technische code blijft een technische code. De plaat kan consistenter worden zonder betekenisvoller te worden. <\/p>\n\n\n\n
Binnen de Evidant Data Transform Raffinaderij kunnen deze correcties worden uitgevoerd met componenten zoals de kolomschoonmaker<\/strong>, rijextractor<\/strong> en rijvuller<\/strong>. In tegenstelling tot een eenmalig opruimscript blijven de transformatieregels zichtbaar, testbaar, herhaalbaar en onderhoudbaar. <\/p>\n\n\n\n<\/p>\n<\/div><\/div>\n\n
\n2. Het ontdekken van bedrijfsinformatie in technische verzamelingen<\/strong><\/a><\/h2>\n\n\n\n<\/p>\n\n\n\n
Waardevolle informatie wordt niet altijd gemakkelijk opgeslagen in een speciale kolom.<\/p>\n\n\n\n
Een case-ID kan verborgen zijn in een URL. Een activiteit is mogelijk alleen herkenbaar aan een combinatie van woorden in een auditspoor. Een applicatielogboek kan tientallen technische elementen bevatten, terwijl slechts een klein deel van het record nuttige zakelijke informatie biedt. <\/p>\n\n\n\n
De gegevens moeten daarom eerst worden onderzocht:<\/p>\n\n\n\n
\n- Welke delen van een document bevatten zakelijke betekenis?<\/li>\n\n\n\n
- Hoe kunnen identifiers uit technische tekst worden gehaald?<\/li>\n\n\n\n
- Welke patronen geven een activiteit of statusverandering aan?<\/li>\n\n\n\n
- Welke technische details kunnen veilig worden verwijderd?<\/li>\n\n\n\n
- Welke elementen moeten worden behouden voor latere interpretatie?<\/li>\n<\/ul>\n\n\n\n
Dit is niet zomaar een inname-taak. Het is een vorm van dataontdekking. <\/p>\n\n\n\n
De Ingest Nodes en <\/strong>Row Extractor van de DTR <\/strong> maken het mogelijk om informatie uit lange strings, applicatielogs, URL’s en andere technische velden te extraheren en deze in herkenbare attributen te plaatsen.ens bruikbaar worden voor operationele analyse..<\/p>\n\n\n\n<\/p>\n<\/div><\/figure><\/div>\n\n<\/figure>\n3. Het correleren van gebeurtenissen met de juiste case-id of procesinstantie<\/strong><\/a><\/h2>\n\n\n\nEen individueel evenement heeft beperkte analytische waarde wanneer onduidelijk is waartoe dat evenement behoort.<\/p>\n\n\n\n
Voor process mining moet elk event normaal gesproken gekoppeld zijn aan een case, order, claim, pati\u00ebnt, klant, gebruiker of procesinstantie. Binnen \u00e9\u00e9n applicatie kan er een duidelijke case-ID bestaan. Zodra meerdere systemen betrokken zijn, komen organisaties de vertrouwde verzameling incompatibele sleutels, inconsistente definities en identificaties tegen die halverwege een proces veranderen. <\/p>\n\n\n\n
Correlatie van case-id\u2019s is daarom een van de moeilijkste onderdelen van het construeren van een betrouwbaar gebeurtenislogboek.<\/p>\n\n\n\n
Een proces kan beginnen onder \u00e9\u00e9n identificatie, later worden verdeeld in meerdere subgevallen en uiteindelijk worden afgerond onder een andere identificatie. Een analyse die alleen op de uiteindelijke ID is gebaseerd, kan verschillende afzonderlijke processen tonen waarbij de organisatie daadwerkelijk \u00e9\u00e9n verbonden werksequentie uitvoerde. <\/p>\n\n\n\n
DTR reconstrueert deze relaties met componenten zoals:<\/p>\n\n\n\n
\n- Group Attributor<\/strong>, voor het herkennen en corrigeren van groepen van gerelateerde gebeurtenissen;<\/li>\n\n\n\n
- Column Lookup <\/strong>voor het toevoegen van attributen uit andere datasets;<\/li>\n\n\n\n
- Farm Joiner<\/strong>, voor het combineren van gebeurtenissen uit verschillende databronnen;<\/li>\n\n\n\n
- Join-IDs<\/strong>, om consistente relaties tussen datafarms te cre\u00ebren.<\/li>\n<\/ul>\n\n\n\n
Het resultaat is niet langer slechts een verzameling tijdgestempelde gegevens. Het wordt een verbonden weergave van wat er binnen een zaak, proces of operationele context is gebeurd.n voor operationele analyse.. <\/p>\n\n\n\n
<\/p>\n<\/div><\/div>\n\n
\n4. Het vertalen van technische gebeurtenissen naar herkenbare activiteiten<\/a><\/strong><\/h2>\n\n\n\nEen informatiesysteem registreert wat het systeem doet.<\/p>\n\n\n\n
De organisatie wil begrijpen wat haar mensen, teams en processen doen.<\/p>\n\n\n\n
Dat onderscheid is fundamenteel.<\/p>\n\n\n\n
Technische evenementen zoals ITEM_CREATE, SAVE_FORM_04 en ROUTE_SYS_03 kunnen gezamenlijk \u00e9\u00e9n herkenbare bedrijfsactiviteit vertegenwoordigen: Klantaanvraag beoordelen. Zonder semantische vertaling blijft de analyse gevangen op het niveau van applicatiegedrag. <\/p>\n\n\n\n
Deze vertaling van technische registraties naar betekenisvolle zakelijke concepten wordt doorgaans omschreven als semantische abstractie<\/strong>.<\/p>\n\n\n\nDTR ondersteunt het cre\u00ebren van deze semantische laag via componenten zoals:<\/p>\n\n\n\n
\n- Evenementnaamgever;<\/strong><\/li>\n\n\n\n
- Groepsnaam voor evenementen<\/strong>;<\/li>\n\n\n\n
- Activiteitsnaamgever<\/strong><\/li>\n<\/ul>\n\n\n\n
Deze transformers zoeken naar patronen, actie-objectcombinaties en groepen van gerelateerde gebeurtenissen. Ze kunnen vervolgens herkenbare namen toewijzen zoals: <\/p>\n\n\n\n
\n- Order goedkeuren;<\/li>\n\n\n\n
- Herzieningsclaim;<\/li>\n\n\n\n
- Route Case;<\/li>\n\n\n\n
- Betaling verifi\u00ebren;<\/li>\n\n\n\n
- Werk klantgegevens bij.<\/li>\n<\/ul>\n\n\n\n
Dit cre\u00ebert een gedeelde taal tussen de data en de organisatie.<\/p>\n\n\n\n
Dat is aanzienlijk nuttiger dan een dashboard vol mysterieuze systeemcodes waarvan de betekenis alleen bekend is bij de ontwikkelaar die het bedrijf twee jaar geleden heeft verlaten.<\/p>\n\n\n\n
<\/p>\n<\/div><\/figure><\/div>\n\n<\/figure>\n5. Het cre\u00ebren van het juiste niveau van granulariteit<\/strong><\/h2>\n\n\n\nMeer detail is niet automatisch beter.<\/p>\n\n\n\n
Een applicatie kan honderden technische gebeurtenissen genereren voor \u00e9\u00e9n menselijke handeling. Wanneer al deze gebeurtenissen afzonderlijk in een procesmodel worden opgenomen, is het resultaat meestal een onleesbaar spaghettidiagram. <\/p>\n\n\n\n
Aan het andere uiterste kunnen te hoog geaggregeerde gegevens belangrijke verschillen tussen taken en activiteiten verbergen.<\/p>\n\n\n\n
Het juiste detailniveau hangt af van de analytische vraag.<\/p>\n\n\n\n
Technische probleemoplossing kan event-level data vereisen. Workforce analytics kan taken vereisen. Procesanalyse profiteert meestal van herkenbare bedrijfsactiviteiten. <\/p>\n\n\n\n
De data moet daarom veranderingen in granulariteit ondersteunen:<\/p>\n\n\n\n
Subtaken \u2192 taken \u2192 activiteiten<\/strong><\/p>\n\n\n\nDe DTR Farm Converter<\/strong> verzamelt gebeurtenissen tot het vereiste analytische niveau. De onderliggende details kunnen behouden blijven voor een diepgaande analyse, terwijl de hoofdstructuur duidelijker en beter begrijpelijk wordt. <\/p>\n\n\n\nHet resultaat is niet simpelweg minder data. Het is beter georganiseerde data. <\/p>\n\n\n\n
Dat is aanzienlijk nuttiger dan een dashboard vol mysterieuze systeemcodes waarvan de betekenis alleen bekend is bij de ontwikkelaar die het bedrijf twee jaar geleden heeft verlaten.<\/p>\n\n\n\n
<\/p>\n<\/div><\/div>\n\n
\n<\/p>\n\n\n\n
6. Domeinkennis onderdeel maken van de transformatie<\/strong><\/a><\/h2>\n\n\n\nData kan niet onafhankelijk bepalen wat een bedrijfsactiviteit betekent.<\/p>\n\n\n\n
Een algoritme kan patronen ontdekken, maar het weet niet automatisch:<\/p>\n\n\n\n
\n- wanneer een activiteit echt begint of eindigt;<\/li>\n\n\n\n
- welke uitzonderingen operationeel van belang zijn;<\/li>\n\n\n\n
- of verschillende technische codes dezelfde handeling vertegenwoordigen;<\/li>\n\n\n\n
- of een ontbrekende identificatie redelijkerwijs kan worden aangevuld;<\/li>\n\n\n\n
- welke technische stappen samen \u00e9\u00e9n taak vormen;<\/li>\n\n\n\n
- of een veranderende zaak-ID nog steeds bij dezelfde werkervaring hoort.<\/li>\n<\/ul>\n\n\n\n
Dat vereist kennis van mensen die de werking begrijpen.<\/p>\n\n\n\n
Hoogwaardige data-opbouw is daarom een samenwerkingsactiviteit tussen dataspecialisten, analisten en zakelijke professionals. Hun kennis mag niet beperkt blijven tot vergadernotities, specificatiedocumenten of het geheugen van \u00e9\u00e9n ervaren medewerker. <\/p>\n\n\n\n
Het moet worden vertaald naar expliciete transformatielogica.<\/p>\n\n\n\n
DTR maakt domeinkennis operationeel via configureerbare regels, datapreviews, rule-hit statistieken en iteratief testen. Aannames worden zichtbaar en kunnen worden onderzocht. <\/p>\n\n\n\n
Dit is belangrijk omdat sommige transformaties onvermijdelijk interpretatie vereisen.<\/p>\n\n\n\n
Het invullen van een ontbrekende zaak-ID op basis van tijdsnabijheid kan bijvoorbeeld aanzienlijke analytische waarde cre\u00ebren. Maar het resultaat moet gebaseerd zijn op een expliciete en toetsbare aanname, in plaats van onzichtbare logica die verborgen zit in aangepaste code. <\/p>\n\n\n\n
Transparante regels maken interpretatie beheersbaar.<\/p>\n\n\n\n
Verborgen regels maken fouten alleen maar moeilijker te vinden.<\/p>\n<\/div><\/figure><\/div>\n\n<\/figure>\n7. Datakwaliteit is een proces, geen eenmalig opruimproject<\/strong><\/h2>\n\n\n\nTraditionele datavoorbereidingsprojecten produceren vaak een script, een exportbestand of een handmatig samengestelde dataset.<\/p>\n\n\n\n
Zes maanden later is de broncode veranderd, werkt de oorspronkelijke logica niet meer en niemand kan zich herinneren waarom bepaalde beslissingen zijn genomen.<\/p>\n\n\n\n
Betrouwbare datakwaliteit moet daarom herhaalbaar en onderhoudbaar zijn.<\/p>\n\n\n\n
Een nuttige dataraffinaderij:<\/p>\n\n\n\n
\n- verwerkt data in een gedefinieerde volgorde;<\/li>\n\n\n\n
- documenteert de regels die worden toegepast;<\/li>\n\n\n\n
- toont intermediate resultaten;<\/li>\n\n\n\n
- maakt uitzonderingen en mist meetbaar;<\/li>\n\n\n\n
- ondersteunt iteratieve tests;<\/li>\n\n\n\n
- kan worden aangepast wanneer systemen of processen veranderen;<\/li>\n\n\n\n
- herhaaldelijk dezelfde semantische structuur produceert uit nieuwe data.<\/li>\n<\/ul>\n\n\n\n
In dit model wordt de configuratie de documentatie van de transformatie. Niet een specificatiedocument dat ceremonieel wordt genegeerd na implementatie, maar uitvoerbare logica die zichtbaar en testbaar blijft <\/p>\n<\/div><\/div>\n\n
\n8. Het cre\u00ebren van \u00e9\u00e9n betrouwbare databasis voor meerdere vormen van analyse<\/strong><\/h2>\n\n\n\n<\/p>\n\n\n\n
Het doel is niet om nog een exportbestand te maken.<\/p>\n\n\n\n
Het doel is om een herbruikbare semantische dataset te cre\u00ebren die meerdere analytische toepassingen kan ondersteunen:<\/p>\n\n\n\n
\n- procesmijnbouw;<\/li>\n\n\n\n
- bedrijfsinlichtingen;<\/li>\n\n\n\n
- arbeidsmarktanalyse;<\/li>\n\n\n\n
- operationele prestatie-analyse;<\/li>\n\n\n\n
- nalevingsmonitoring;<\/li>\n\n\n\n
- Kunstmatige intelligentie en machine learning.<\/li>\n<\/ul>\n\n\n\n
DTR cre\u00ebert deze analyse-klare datafarms en levert deze aan databases, bestanden en analyseplatforms via configureerbare Data <\/strong>Writers.<\/p>\n\n\n\nDe interpretatie van de brondata hoeft daarom niet afzonderlijk opnieuw opgebouwd te worden voor elk dashboard, proces-mining platform of AI-project.<\/p>\n\n\n\n
Bouw \u00e9\u00e9n keer, consumeer overal.<\/strong> Dit vermindert meer dan alleen dubbele inspanning. Het zorgt ervoor dat verschillende analytische toepassingen dezelfde definities, relaties en zakelijke betekenis gebruikencumentatie van de transformatie. Niet een specificatiedocument dat ceremonieel wordt genegeerd na implementatie, maar uitvoerbare logica die zichtbaar en testbaar blijft <\/p>\n<\/div><\/figure><\/div>\n\n<\/figure>\nVan ruwe registraties tot betrouwbare informatie<\/a><\/strong><\/h2>\n\n\n\n<\/h2>\n\n\n\n
Samen beschrijven de zes publicaties een herkenbare data-voorbereidingsreeks:<\/p>\n\n\n\n
repareren \u2192 extraheren \u2192 correleren \u2192 \u2192 aggregate interpreteren \u2192 \u2192 hergebruik valideren<\/strong><\/p>\n\n\n\nDeze volgorde transformeert technische systeemregistraties in geldige, waardevolle en nauwkeurige informatie.<\/p>\n\n\n\n
De Evidant Data Transform Raffinaderij vertaalt deze academische thema’s naar een operationele, testbare en herbruikbare dataraffinaderij.<\/p>\n\n\n\n
Het beweert niet dat datakwaliteit volledig geautomatiseerd kan worden. In plaats daarvan brengt het technologie, domeinkennis en transparante transformatieregels samen. <\/p>\n\n\n\n
Omdat betrouwbare analyses niet in het dashboard beginnen.<\/p>\n\n\n\n
Het begint met de vraag of de onderliggende data echt beschrijft wat de organisatie doet.<\/p>\n<\/div><\/div>\n\n
<\/p>\n\n
<\/p>\n\n
De zes publicaties achter dit perspectief<\/h2>\n\n
<\/p>\n\n
<\/p>\n\n
<\/figure>\n1. Proces-data kwaliteit: De ware grens van procesmining<\/a><\/h3>\n\n\n\nArthur H. M. ter Hofstede et al.<\/p>\n\n\n\n
Download de openbare PDF<\/a><\/p>\n\n\n\nDeze publicatie positioneert proces-datakwaliteit als een fundamentele uitdaging voor process mining en betoogt dat kwaliteit gedurende de volledige data- en analysecyclus moet worden meegenomen. Gebeurtenislogboeken in de praktijk bevatten aanzienlijke kwaliteitsproblemen die moeten worden ge\u00efdentificeerd en opgelost voordat zinvolle analyse mogelijk is, en slechte kwaliteit gebeurtenisdata verhindert dat process mining zijn volledige organisatorische impact bereikt. <\/p>\n\n\n\n
Waarom het belangrijk is voor DTR \u2014 <\/strong>Biedt de sterkste onafhankelijke validatie van DTR’s algemene propositie \u2014 de waarde van process mining hangt af van de kwaliteit van de gebeurtenisgegevens die eraan worden geleverd.<\/p>\n\n\n\nTR-mogelijkheden \u2014 Kolomschoonmaker, Row Extractor, Farm Joiner, Column Lookup, Results Dashboards en het semantische datafarmmodel.<\/p>\n<\/div><\/div>\n\n
\n2. Extractie, correlatie en abstractie van gebeurtenisgegevens voor process mining<\/h3>\n\n\n\n
Kiarash Diba, Kimon Batoulis, Matthias Weidlich en Mathias Weske<\/p>\n\n\n\n
Download de openbare PDF<\/a><\/p>\n\n\n\nDeze studie biedt een gestructureerd overzicht van de reis van ruwe brongegevens naar bruikbare gebeurtenislogs, met aandacht voor extractie, gebeurteniscorrelatie en semantische abstractie. Het kadert die reis als drie grote uitdagingen: het identificeren en extraheren van relevante data, het correleren van gebeurtenissen in procesinstanties, en het abstraheren van technische gebeurtenissen tot betekenisvolle procesconcepten. <\/p>\n\n\n\n
Waarom het belangrijk is voor DTR \u2014 <\/strong>Bijna een conceptueel blauwdruk voor DTR \u2014 het definieert het exacte upstreamgebied waarin DTR opereert: extractie, correlatie en abstractie.Relevante DTR-mogelijkheden \u2014 <\/strong>extractie via Row Extractor en Ingest Nodes; correlatie via Group Attributor, Farm Joiner en Join ID’s; abstractie via Event Namer, Event Group Namer, Activity Namer en Farm Converter<\/p>\n<\/div><\/figure><\/div>\n\n<\/figure>\n3. Richting het begrijpen van de rol van de mens bij het extraheren van gebeurtenislogboeken<\/a><\/h3>\n\n\n\nVinicius Stein, Dani et al.<\/p>\n\n\n\n
Download de openbare PDF<\/a><\/p>\n\n\n\nDeze publicatie onderzoekt de essenti\u00eble rol van menselijke kennis en beoordeling bij het extraheren van gebeurtenislogboeken en laat zien waarom het opstellen van een gebeurtenislogboek niet als een puur technische oefening kan worden beschouwd. Het ontwikkelt een taxonomie van de menselijke activiteiten die betrokken zijn bij het extraheren van gebeurtenislogboeken en toont aan dat de voorbereidingsinspanningen die mensen verrichten \u2014 het verzamelen van gegevens uit verschillende databases en deze omzetten in een geschikt formaat \u2014 aanzienlijk is. <\/p>\n\n\n\n
Waarom het belangrijk is voor DTR \u2014 <\/strong>Ondersteunt DTR’s nadruk op samenwerking tussen dataspecialisten, operationele experts en analisten: het voorbereiden van gebeurtenislogboeken kan niet volledig losstaan van menselijke interpretatie en zakelijke kennis.<\/p>\n\n\n\nRelevante DTR-mogelijkheden \u2014 <\/strong>Visueel raffinaderijontwerp, regelgebaseerde configuratie, datapreviews, regel-hit statistieken, zelfdocumenterende transformaties en een gezamenlijk build-and-testproces.<\/p>\n<\/div><\/div>\n\n\n4. Patronen van onvolmaaktheid in gebeurtenislogboeken voor procesmijnbouw: Richting een systematische benadering van het schoonmaken van gebeurtenislogboeken<\/a><\/h3>\n\n\n\nSuriadi Suriadi, Robert Andrews, Arthur H. M. ter Hofstede en Moe Thandar Wynn<\/p>\n\n\n\n
Een dashboard kan deze problemen niet oplossen. Een aantrekkelijke visualisatie maakt onbetrouwbare informatie alleen overtuigender. Een AI-model kan niet betrouwbaar relaties reconstrueren die nooit expliciet zijn gemaakt in de onderliggende data. <\/p>\n\n\n\n
Voor operationele analyse moet de datakwaliteit daarom worden beoordeeld op meer dan alleen volledigheid en technische correctheid. De gegevens moeten ook zijn: <\/p>\n\n\n\n
Geldig:<\/strong> Het moet aantoonbaar aansluiten op en de daadwerkelijke bedrijfsvoering vertegenwoordigen.<\/p>\n\n\n\n Waardevol:<\/strong> Het moet inzichten bieden die mensen kunnen gebruiken om beslissingen te nemen en actie te ondernemen.<\/p>\n\n\n\n Nauwkeurig:<\/strong> De resulterende informatie moet het vertrouwen verdienen van de mensen die ervan afhankelijk zijn.<\/p>\n\n\n\n Samen bepalen deze eigenschappen het verschil tussen data die slechts beschikbaar is en data die echt nuttig is.<\/p>\n<\/div> Operationele data is zelden schoon, consistent en compleet wanneer deze voor het eerst beschikbaar komt.<\/p>\n\n\n\n Velden kunnen leeg zijn. Namen kunnen op verschillende manieren worden geschreven. Kolommen kunnen meerdere waarden bevatten. Gegevenstypen kunnen vari\u00ebren tussen bronnen. Hetzelfde evenement kan meer dan eens zijn geregistreerd. <\/p>\n\n\n\n Dit is de meest bekende vorm van datakwaliteitsherstel. Het omvat activiteiten zoals: <\/p>\n\n\n\n Deze transformaties zijn noodzakelijk, maar ze zijn slechts het begin.<\/p>\n\n\n\n Een opgeschonen technische code blijft een technische code. De plaat kan consistenter worden zonder betekenisvoller te worden. <\/p>\n\n\n\n Binnen de Evidant Data Transform Raffinaderij kunnen deze correcties worden uitgevoerd met componenten zoals de kolomschoonmaker<\/strong>, rijextractor<\/strong> en rijvuller<\/strong>. In tegenstelling tot een eenmalig opruimscript blijven de transformatieregels zichtbaar, testbaar, herhaalbaar en onderhoudbaar. <\/p>\n\n\n\n <\/p>\n<\/div><\/div>\n\n <\/p>\n\n\n\n Waardevolle informatie wordt niet altijd gemakkelijk opgeslagen in een speciale kolom.<\/p>\n\n\n\n Een case-ID kan verborgen zijn in een URL. Een activiteit is mogelijk alleen herkenbaar aan een combinatie van woorden in een auditspoor. Een applicatielogboek kan tientallen technische elementen bevatten, terwijl slechts een klein deel van het record nuttige zakelijke informatie biedt. <\/p>\n\n\n\n De gegevens moeten daarom eerst worden onderzocht:<\/p>\n\n\n\n Dit is niet zomaar een inname-taak. Het is een vorm van dataontdekking. <\/p>\n\n\n\n De Ingest Nodes en <\/strong>Row Extractor van de DTR <\/strong> maken het mogelijk om informatie uit lange strings, applicatielogs, URL’s en andere technische velden te extraheren en deze in herkenbare attributen te plaatsen.ens bruikbaar worden voor operationele analyse..<\/p>\n\n\n\n <\/p>\n<\/div> Een individueel evenement heeft beperkte analytische waarde wanneer onduidelijk is waartoe dat evenement behoort.<\/p>\n\n\n\n Voor process mining moet elk event normaal gesproken gekoppeld zijn aan een case, order, claim, pati\u00ebnt, klant, gebruiker of procesinstantie. Binnen \u00e9\u00e9n applicatie kan er een duidelijke case-ID bestaan. Zodra meerdere systemen betrokken zijn, komen organisaties de vertrouwde verzameling incompatibele sleutels, inconsistente definities en identificaties tegen die halverwege een proces veranderen. <\/p>\n\n\n\n Correlatie van case-id\u2019s is daarom een van de moeilijkste onderdelen van het construeren van een betrouwbaar gebeurtenislogboek.<\/p>\n\n\n\n Een proces kan beginnen onder \u00e9\u00e9n identificatie, later worden verdeeld in meerdere subgevallen en uiteindelijk worden afgerond onder een andere identificatie. Een analyse die alleen op de uiteindelijke ID is gebaseerd, kan verschillende afzonderlijke processen tonen waarbij de organisatie daadwerkelijk \u00e9\u00e9n verbonden werksequentie uitvoerde. <\/p>\n\n\n\n DTR reconstrueert deze relaties met componenten zoals:<\/p>\n\n\n\n Het resultaat is niet langer slechts een verzameling tijdgestempelde gegevens. Het wordt een verbonden weergave van wat er binnen een zaak, proces of operationele context is gebeurd.n voor operationele analyse.. <\/p>\n\n\n\n <\/p>\n<\/div><\/div>\n\n Een informatiesysteem registreert wat het systeem doet.<\/p>\n\n\n\n De organisatie wil begrijpen wat haar mensen, teams en processen doen.<\/p>\n\n\n\n Dat onderscheid is fundamenteel.<\/p>\n\n\n\n Technische evenementen zoals ITEM_CREATE, SAVE_FORM_04 en ROUTE_SYS_03 kunnen gezamenlijk \u00e9\u00e9n herkenbare bedrijfsactiviteit vertegenwoordigen: Klantaanvraag beoordelen. Zonder semantische vertaling blijft de analyse gevangen op het niveau van applicatiegedrag. <\/p>\n\n\n\n Deze vertaling van technische registraties naar betekenisvolle zakelijke concepten wordt doorgaans omschreven als semantische abstractie<\/strong>.<\/p>\n\n\n\n DTR ondersteunt het cre\u00ebren van deze semantische laag via componenten zoals:<\/p>\n\n\n\n Deze transformers zoeken naar patronen, actie-objectcombinaties en groepen van gerelateerde gebeurtenissen. Ze kunnen vervolgens herkenbare namen toewijzen zoals: <\/p>\n\n\n\n Dit cre\u00ebert een gedeelde taal tussen de data en de organisatie.<\/p>\n\n\n\n Dat is aanzienlijk nuttiger dan een dashboard vol mysterieuze systeemcodes waarvan de betekenis alleen bekend is bij de ontwikkelaar die het bedrijf twee jaar geleden heeft verlaten.<\/p>\n\n\n\n <\/p>\n<\/div> Meer detail is niet automatisch beter.<\/p>\n\n\n\n Een applicatie kan honderden technische gebeurtenissen genereren voor \u00e9\u00e9n menselijke handeling. Wanneer al deze gebeurtenissen afzonderlijk in een procesmodel worden opgenomen, is het resultaat meestal een onleesbaar spaghettidiagram. <\/p>\n\n\n\n Aan het andere uiterste kunnen te hoog geaggregeerde gegevens belangrijke verschillen tussen taken en activiteiten verbergen.<\/p>\n\n\n\n Het juiste detailniveau hangt af van de analytische vraag.<\/p>\n\n\n\n Technische probleemoplossing kan event-level data vereisen. Workforce analytics kan taken vereisen. Procesanalyse profiteert meestal van herkenbare bedrijfsactiviteiten. <\/p>\n\n\n\n De data moet daarom veranderingen in granulariteit ondersteunen:<\/p>\n\n\n\n Subtaken \u2192 taken \u2192 activiteiten<\/strong><\/p>\n\n\n\n De DTR Farm Converter<\/strong> verzamelt gebeurtenissen tot het vereiste analytische niveau. De onderliggende details kunnen behouden blijven voor een diepgaande analyse, terwijl de hoofdstructuur duidelijker en beter begrijpelijk wordt. <\/p>\n\n\n\n Het resultaat is niet simpelweg minder data. Het is beter georganiseerde data. <\/p>\n\n\n\n Dat is aanzienlijk nuttiger dan een dashboard vol mysterieuze systeemcodes waarvan de betekenis alleen bekend is bij de ontwikkelaar die het bedrijf twee jaar geleden heeft verlaten.<\/p>\n\n\n\n <\/p>\n<\/div><\/div>\n\n <\/p>\n\n\n\n Data kan niet onafhankelijk bepalen wat een bedrijfsactiviteit betekent.<\/p>\n\n\n\n Een algoritme kan patronen ontdekken, maar het weet niet automatisch:<\/p>\n\n\n\n Dat vereist kennis van mensen die de werking begrijpen.<\/p>\n\n\n\n Hoogwaardige data-opbouw is daarom een samenwerkingsactiviteit tussen dataspecialisten, analisten en zakelijke professionals. Hun kennis mag niet beperkt blijven tot vergadernotities, specificatiedocumenten of het geheugen van \u00e9\u00e9n ervaren medewerker. <\/p>\n\n\n\n Het moet worden vertaald naar expliciete transformatielogica.<\/p>\n\n\n\n DTR maakt domeinkennis operationeel via configureerbare regels, datapreviews, rule-hit statistieken en iteratief testen. Aannames worden zichtbaar en kunnen worden onderzocht. <\/p>\n\n\n\n Dit is belangrijk omdat sommige transformaties onvermijdelijk interpretatie vereisen.<\/p>\n\n\n\n Het invullen van een ontbrekende zaak-ID op basis van tijdsnabijheid kan bijvoorbeeld aanzienlijke analytische waarde cre\u00ebren. Maar het resultaat moet gebaseerd zijn op een expliciete en toetsbare aanname, in plaats van onzichtbare logica die verborgen zit in aangepaste code. <\/p>\n\n\n\n Transparante regels maken interpretatie beheersbaar.<\/p>\n\n\n\n Verborgen regels maken fouten alleen maar moeilijker te vinden.<\/p>\n<\/div> Traditionele datavoorbereidingsprojecten produceren vaak een script, een exportbestand of een handmatig samengestelde dataset.<\/p>\n\n\n\n Zes maanden later is de broncode veranderd, werkt de oorspronkelijke logica niet meer en niemand kan zich herinneren waarom bepaalde beslissingen zijn genomen.<\/p>\n\n\n\n Betrouwbare datakwaliteit moet daarom herhaalbaar en onderhoudbaar zijn.<\/p>\n\n\n\n Een nuttige dataraffinaderij:<\/p>\n\n\n\n In dit model wordt de configuratie de documentatie van de transformatie. Niet een specificatiedocument dat ceremonieel wordt genegeerd na implementatie, maar uitvoerbare logica die zichtbaar en testbaar blijft <\/p>\n<\/div><\/div>\n\n <\/p>\n\n\n\n Het doel is niet om nog een exportbestand te maken.<\/p>\n\n\n\n Het doel is om een herbruikbare semantische dataset te cre\u00ebren die meerdere analytische toepassingen kan ondersteunen:<\/p>\n\n\n\n DTR cre\u00ebert deze analyse-klare datafarms en levert deze aan databases, bestanden en analyseplatforms via configureerbare Data <\/strong>Writers.<\/p>\n\n\n\n De interpretatie van de brondata hoeft daarom niet afzonderlijk opnieuw opgebouwd te worden voor elk dashboard, proces-mining platform of AI-project.<\/p>\n\n\n\n Bouw \u00e9\u00e9n keer, consumeer overal.<\/strong> Dit vermindert meer dan alleen dubbele inspanning. Het zorgt ervoor dat verschillende analytische toepassingen dezelfde definities, relaties en zakelijke betekenis gebruikencumentatie van de transformatie. Niet een specificatiedocument dat ceremonieel wordt genegeerd na implementatie, maar uitvoerbare logica die zichtbaar en testbaar blijft <\/p>\n<\/div> Samen beschrijven de zes publicaties een herkenbare data-voorbereidingsreeks:<\/p>\n\n\n\n repareren \u2192 extraheren \u2192 correleren \u2192 \u2192 aggregate interpreteren \u2192 \u2192 hergebruik valideren<\/strong><\/p>\n\n\n\n Deze volgorde transformeert technische systeemregistraties in geldige, waardevolle en nauwkeurige informatie.<\/p>\n\n\n\n De Evidant Data Transform Raffinaderij vertaalt deze academische thema’s naar een operationele, testbare en herbruikbare dataraffinaderij.<\/p>\n\n\n\n Het beweert niet dat datakwaliteit volledig geautomatiseerd kan worden. In plaats daarvan brengt het technologie, domeinkennis en transparante transformatieregels samen. <\/p>\n\n\n\n Omdat betrouwbare analyses niet in het dashboard beginnen.<\/p>\n\n\n\n Het begint met de vraag of de onderliggende data echt beschrijft wat de organisatie doet.<\/p>\n<\/div><\/div>\n\n <\/p>\n\n <\/p>\n\n <\/p>\n\n <\/p>\n\n Arthur H. M. ter Hofstede et al.<\/p>\n\n\n\n Download de openbare PDF<\/a><\/p>\n\n\n\n Deze publicatie positioneert proces-datakwaliteit als een fundamentele uitdaging voor process mining en betoogt dat kwaliteit gedurende de volledige data- en analysecyclus moet worden meegenomen. Gebeurtenislogboeken in de praktijk bevatten aanzienlijke kwaliteitsproblemen die moeten worden ge\u00efdentificeerd en opgelost voordat zinvolle analyse mogelijk is, en slechte kwaliteit gebeurtenisdata verhindert dat process mining zijn volledige organisatorische impact bereikt. <\/p>\n\n\n\n Waarom het belangrijk is voor DTR \u2014 <\/strong>Biedt de sterkste onafhankelijke validatie van DTR’s algemene propositie \u2014 de waarde van process mining hangt af van de kwaliteit van de gebeurtenisgegevens die eraan worden geleverd.<\/p>\n\n\n\n TR-mogelijkheden \u2014 Kolomschoonmaker, Row Extractor, Farm Joiner, Column Lookup, Results Dashboards en het semantische datafarmmodel.<\/p>\n<\/div><\/div>\n\n Kiarash Diba, Kimon Batoulis, Matthias Weidlich en Mathias Weske<\/p>\n\n\n\n Download de openbare PDF<\/a><\/p>\n\n\n\n Deze studie biedt een gestructureerd overzicht van de reis van ruwe brongegevens naar bruikbare gebeurtenislogs, met aandacht voor extractie, gebeurteniscorrelatie en semantische abstractie. Het kadert die reis als drie grote uitdagingen: het identificeren en extraheren van relevante data, het correleren van gebeurtenissen in procesinstanties, en het abstraheren van technische gebeurtenissen tot betekenisvolle procesconcepten. <\/p>\n\n\n\n Waarom het belangrijk is voor DTR \u2014 <\/strong>Bijna een conceptueel blauwdruk voor DTR \u2014 het definieert het exacte upstreamgebied waarin DTR opereert: extractie, correlatie en abstractie.Relevante DTR-mogelijkheden \u2014 <\/strong>extractie via Row Extractor en Ingest Nodes; correlatie via Group Attributor, Farm Joiner en Join ID’s; abstractie via Event Namer, Event Group Namer, Activity Namer en Farm Converter<\/p>\n<\/div> Vinicius Stein, Dani et al.<\/p>\n\n\n\n Download de openbare PDF<\/a><\/p>\n\n\n\n Deze publicatie onderzoekt de essenti\u00eble rol van menselijke kennis en beoordeling bij het extraheren van gebeurtenislogboeken en laat zien waarom het opstellen van een gebeurtenislogboek niet als een puur technische oefening kan worden beschouwd. Het ontwikkelt een taxonomie van de menselijke activiteiten die betrokken zijn bij het extraheren van gebeurtenislogboeken en toont aan dat de voorbereidingsinspanningen die mensen verrichten \u2014 het verzamelen van gegevens uit verschillende databases en deze omzetten in een geschikt formaat \u2014 aanzienlijk is. <\/p>\n\n\n\n Waarom het belangrijk is voor DTR \u2014 <\/strong>Ondersteunt DTR’s nadruk op samenwerking tussen dataspecialisten, operationele experts en analisten: het voorbereiden van gebeurtenislogboeken kan niet volledig losstaan van menselijke interpretatie en zakelijke kennis.<\/p>\n\n\n\n Relevante DTR-mogelijkheden \u2014 <\/strong>Visueel raffinaderijontwerp, regelgebaseerde configuratie, datapreviews, regel-hit statistieken, zelfdocumenterende transformaties en een gezamenlijk build-and-testproces.<\/p>\n<\/div><\/div>\n\n Suriadi Suriadi, Robert Andrews, Arthur H. M. ter Hofstede en Moe Thandar Wynn<\/p>\n\n\n\n<\/figure><\/div>\n\n<\/figure>1. Het herstellen van technische inconsistenties en imperfecties<\/strong><\/a><\/h2>\n\n\n\n
\n
2. Het ontdekken van bedrijfsinformatie in technische verzamelingen<\/strong><\/a><\/h2>\n\n\n\n
\n
<\/figure><\/div>\n\n<\/figure>3. Het correleren van gebeurtenissen met de juiste case-id of procesinstantie<\/strong><\/a><\/h2>\n\n\n\n
\n
4. Het vertalen van technische gebeurtenissen naar herkenbare activiteiten<\/a><\/strong><\/h2>\n\n\n\n
\n
\n
<\/figure><\/div>\n\n<\/figure>5. Het cre\u00ebren van het juiste niveau van granulariteit<\/strong><\/h2>\n\n\n\n
6. Domeinkennis onderdeel maken van de transformatie<\/strong><\/a><\/h2>\n\n\n\n
\n
<\/figure><\/div>\n\n<\/figure>7. Datakwaliteit is een proces, geen eenmalig opruimproject<\/strong><\/h2>\n\n\n\n
\n
8. Het cre\u00ebren van \u00e9\u00e9n betrouwbare databasis voor meerdere vormen van analyse<\/strong><\/h2>\n\n\n\n
\n
<\/figure><\/div>\n\n<\/figure>Van ruwe registraties tot betrouwbare informatie<\/a><\/strong><\/h2>\n\n\n\n
<\/h2>\n\n\n\n
De zes publicaties achter dit perspectief<\/h2>\n\n
<\/figure>1. Proces-data kwaliteit: De ware grens van procesmining<\/a><\/h3>\n\n\n\n
2. Extractie, correlatie en abstractie van gebeurtenisgegevens voor process mining<\/h3>\n\n\n\n
<\/figure><\/div>\n\n<\/figure>3. Richting het begrijpen van de rol van de mens bij het extraheren van gebeurtenislogboeken<\/a><\/h3>\n\n\n\n
4. Patronen van onvolmaaktheid in gebeurtenislogboeken voor procesmijnbouw: Richting een systematische benadering van het schoonmaken van gebeurtenislogboeken<\/a><\/h3>\n\n\n\n
![\"\"](\"https:\/\/agilos.nl\/wp-content\/uploads\/2026\/07\/article-4.png\")
<\/figure><\/div>\n\n![\"\"](\"https:\/\/agilos.nl\/wp-content\/uploads\/2026\/07\/article5.png\")
<\/figure>![\"\"](\"https:\/\/agilos.nl\/wp-content\/uploads\/2026\/07\/article-6.png\")
<\/figure><\/div>\n\n