Data wordt alleen waardevol wanneer het de realiteit betekenisvol weergeeft
This is a translation of an english blog of Evidant DTR: Raw data is not analytics-ready data – Evidant
Organisaties hebben toegang tot meer operationele data dan ooit tevoren. Applicaties registreren statuswijzigingen, gebruikersacties, transacties, tijdstempels, systeemberichten en processtappen. In theorie creëert dit een rijke basis voor business intelligence, process mining, workforce analytics en kunstmatige intelligentie.
In de praktijk zijn operationele data meestal veel minder bruikbaar dan verwacht.
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.
Dit is gebaseerd op zes publicaties (deze publicaties benaderen datavoorbereiding vanuit verschillende perspectieven, maar hun gezamenlijke conclusie is consistent:
Betrouwbare operationele analyses kunnen niet worden gecreëerd door simpelweg ruwe systeemgegevens in een analytisch platform te laden.
De data moet eerst worden gerepareerd, gereconstrueerd, geïnterpreteerd en verbonden met de realiteit van de organisatie.
Ruwe data is geen kant en klare analyse data. Het is gewoon ruwe data met mogelijkheden.
Daar ligt de ware grens van datakwaliteit.
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.
Datakwaliteit start niet in het dashboard
Wanneer analytics onjuiste, onvolledige of onverklaarbare resultaten oplevert, zoeken organisaties vaak naar de oorzaak in het dashboard, het process-miningmodel of het algoritme.
Wanneer analytics onjuiste, onvolledige of onverklaarbare resultaten oplevert, zoeken organisaties vaak naar de oorzaak in het dashboard, het process-miningmodel of het algoritme.
Wanneer analytics onjuiste, onvolledige of onverklaarbare resultaten oplevert, zoeken organisaties vaak naar de oorzaak in het dashboard, het process-miningmodel of het algoritme.
Maar het probleem begint meestal veel eerder.
De brongegevens kunnen bevatten:
- dubbele of onvolledige records;
- identificaties die veranderen tussen systemen of procesfasen;
- waardevolle informatie verborgen in technische tekstvelden;
- gebeurtenissen zonder herkenbare zakelijke betekenis;
- verschillende niveaus van granulariteit;
- gefragmenteerde records van meerdere applicaties;
- ontbrekende context over gebruikers, klanten, producten of casussen.
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.
Voor operationele analyse moet de datakwaliteit daarom worden beoordeeld op meer dan alleen volledigheid en technische correctheid. De gegevens moeten ook zijn:
Geldig: Het moet aantoonbaar aansluiten op en de daadwerkelijke bedrijfsvoering vertegenwoordigen.
Waardevol: Het moet inzichten bieden die mensen kunnen gebruiken om beslissingen te nemen en actie te ondernemen.
Nauwkeurig: De resulterende informatie moet het vertrouwen verdienen van de mensen die ervan afhankelijk zijn.
Samen bepalen deze eigenschappen het verschil tussen data die slechts beschikbaar is en data die echt nuttig is.
1. Het herstellen van technische inconsistenties en imperfecties
Operationele data is zelden schoon, consistent en compleet wanneer deze voor het eerst beschikbaar komt.
Velden kunnen leeg zijn. Namen kunnen op verschillende manieren worden geschreven. Kolommen kunnen meerdere waarden bevatten. Gegevenstypen kunnen variëren tussen bronnen. Hetzelfde evenement kan meer dan eens zijn geregistreerd.
Dit is de meest bekende vorm van datakwaliteitsherstel. Het omvat activiteiten zoals:
- het verwijderen van dubbele records;
- het corrigeren en standaardiseren van waarden;
- het splitsen of combineren van kolommen;
- het verwijderen van irrelevante archieven;
- het invullen van ontbrekende waarden;
- standaardisatieformaten en naamgevingsconventies.
Deze transformaties zijn noodzakelijk, maar ze zijn slechts het begin.
Een opgeschonen technische code blijft een technische code. De plaat kan consistenter worden zonder betekenisvoller te worden.
Binnen de Evidant Data Transform Raffinaderij kunnen deze correcties worden uitgevoerd met componenten zoals de kolomschoonmaker, rijextractor en rijvuller. In tegenstelling tot een eenmalig opruimscript blijven de transformatieregels zichtbaar, testbaar, herhaalbaar en onderhoudbaar.
2. Het ontdekken van bedrijfsinformatie in technische verzamelingen
Waardevolle informatie wordt niet altijd gemakkelijk opgeslagen in een speciale kolom.
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.
De gegevens moeten daarom eerst worden onderzocht:
- Welke delen van een document bevatten zakelijke betekenis?
- Hoe kunnen identifiers uit technische tekst worden gehaald?
- Welke patronen geven een activiteit of statusverandering aan?
- Welke technische details kunnen veilig worden verwijderd?
- Welke elementen moeten worden behouden voor latere interpretatie?
Dit is niet zomaar een inname-taak. Het is een vorm van dataontdekking.
De Ingest Nodes en Row Extractor van de DTR 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..
3. Het correleren van gebeurtenissen met de juiste case-id of procesinstantie
Een individueel evenement heeft beperkte analytische waarde wanneer onduidelijk is waartoe dat evenement behoort.
Voor process mining moet elk event normaal gesproken gekoppeld zijn aan een case, order, claim, patiënt, klant, gebruiker of procesinstantie. Binnen één 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.
Correlatie van case-id’s is daarom een van de moeilijkste onderdelen van het construeren van een betrouwbaar gebeurtenislogboek.
Een proces kan beginnen onder één 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 één verbonden werksequentie uitvoerde.
DTR reconstrueert deze relaties met componenten zoals:
- Group Attributor, voor het herkennen en corrigeren van groepen van gerelateerde gebeurtenissen;
- Column Lookup voor het toevoegen van attributen uit andere datasets;
- Farm Joiner, voor het combineren van gebeurtenissen uit verschillende databronnen;
- Join-IDs, om consistente relaties tussen datafarms te creëren.
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..
4. Het vertalen van technische gebeurtenissen naar herkenbare activiteiten
Een informatiesysteem registreert wat het systeem doet.
De organisatie wil begrijpen wat haar mensen, teams en processen doen.
Dat onderscheid is fundamenteel.
Technische evenementen zoals ITEM_CREATE, SAVE_FORM_04 en ROUTE_SYS_03 kunnen gezamenlijk één herkenbare bedrijfsactiviteit vertegenwoordigen: Klantaanvraag beoordelen. Zonder semantische vertaling blijft de analyse gevangen op het niveau van applicatiegedrag.
Deze vertaling van technische registraties naar betekenisvolle zakelijke concepten wordt doorgaans omschreven als semantische abstractie.
DTR ondersteunt het creëren van deze semantische laag via componenten zoals:
- Evenementnaamgever;
- Groepsnaam voor evenementen;
- Activiteitsnaamgever
Deze transformers zoeken naar patronen, actie-objectcombinaties en groepen van gerelateerde gebeurtenissen. Ze kunnen vervolgens herkenbare namen toewijzen zoals:
- Order goedkeuren;
- Herzieningsclaim;
- Route Case;
- Betaling verifiëren;
- Werk klantgegevens bij.
Dit creëert een gedeelde taal tussen de data en de organisatie.
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.
5. Het creëren van het juiste niveau van granulariteit
Meer detail is niet automatisch beter.
Een applicatie kan honderden technische gebeurtenissen genereren voor één menselijke handeling. Wanneer al deze gebeurtenissen afzonderlijk in een procesmodel worden opgenomen, is het resultaat meestal een onleesbaar spaghettidiagram.
Aan het andere uiterste kunnen te hoog geaggregeerde gegevens belangrijke verschillen tussen taken en activiteiten verbergen.
Het juiste detailniveau hangt af van de analytische vraag.
Technische probleemoplossing kan event-level data vereisen. Workforce analytics kan taken vereisen. Procesanalyse profiteert meestal van herkenbare bedrijfsactiviteiten.
De data moet daarom veranderingen in granulariteit ondersteunen:
Subtaken → taken → activiteiten
De DTR Farm Converter 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.
Het resultaat is niet simpelweg minder data. Het is beter georganiseerde data.
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.
6. Domeinkennis onderdeel maken van de transformatie
Data kan niet onafhankelijk bepalen wat een bedrijfsactiviteit betekent.
Een algoritme kan patronen ontdekken, maar het weet niet automatisch:
- wanneer een activiteit echt begint of eindigt;
- welke uitzonderingen operationeel van belang zijn;
- of verschillende technische codes dezelfde handeling vertegenwoordigen;
- of een ontbrekende identificatie redelijkerwijs kan worden aangevuld;
- welke technische stappen samen één taak vormen;
- of een veranderende zaak-ID nog steeds bij dezelfde werkervaring hoort.
Dat vereist kennis van mensen die de werking begrijpen.
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 één ervaren medewerker.
Het moet worden vertaald naar expliciete transformatielogica.
DTR maakt domeinkennis operationeel via configureerbare regels, datapreviews, rule-hit statistieken en iteratief testen. Aannames worden zichtbaar en kunnen worden onderzocht.
Dit is belangrijk omdat sommige transformaties onvermijdelijk interpretatie vereisen.
Het invullen van een ontbrekende zaak-ID op basis van tijdsnabijheid kan bijvoorbeeld aanzienlijke analytische waarde creëren. Maar het resultaat moet gebaseerd zijn op een expliciete en toetsbare aanname, in plaats van onzichtbare logica die verborgen zit in aangepaste code.
Transparante regels maken interpretatie beheersbaar.
Verborgen regels maken fouten alleen maar moeilijker te vinden.
7. Datakwaliteit is een proces, geen eenmalig opruimproject
Traditionele datavoorbereidingsprojecten produceren vaak een script, een exportbestand of een handmatig samengestelde dataset.
Zes maanden later is de broncode veranderd, werkt de oorspronkelijke logica niet meer en niemand kan zich herinneren waarom bepaalde beslissingen zijn genomen.
Betrouwbare datakwaliteit moet daarom herhaalbaar en onderhoudbaar zijn.
Een nuttige dataraffinaderij:
- verwerkt data in een gedefinieerde volgorde;
- documenteert de regels die worden toegepast;
- toont intermediate resultaten;
- maakt uitzonderingen en mist meetbaar;
- ondersteunt iteratieve tests;
- kan worden aangepast wanneer systemen of processen veranderen;
- herhaaldelijk dezelfde semantische structuur produceert uit nieuwe data.
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
8. Het creëren van één betrouwbare databasis voor meerdere vormen van analyse
Het doel is niet om nog een exportbestand te maken.
Het doel is om een herbruikbare semantische dataset te creëren die meerdere analytische toepassingen kan ondersteunen:
- procesmijnbouw;
- bedrijfsinlichtingen;
- arbeidsmarktanalyse;
- operationele prestatie-analyse;
- nalevingsmonitoring;
- Kunstmatige intelligentie en machine learning.
DTR creëert deze analyse-klare datafarms en levert deze aan databases, bestanden en analyseplatforms via configureerbare Data Writers.
De interpretatie van de brondata hoeft daarom niet afzonderlijk opnieuw opgebouwd te worden voor elk dashboard, proces-mining platform of AI-project.
Bouw één keer, consumeer overal. 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
Van ruwe registraties tot betrouwbare informatie
Samen beschrijven de zes publicaties een herkenbare data-voorbereidingsreeks:
repareren → extraheren → correleren → → aggregate interpreteren → → hergebruik valideren
Deze volgorde transformeert technische systeemregistraties in geldige, waardevolle en nauwkeurige informatie.
De Evidant Data Transform Raffinaderij vertaalt deze academische thema’s naar een operationele, testbare en herbruikbare dataraffinaderij.
Het beweert niet dat datakwaliteit volledig geautomatiseerd kan worden. In plaats daarvan brengt het technologie, domeinkennis en transparante transformatieregels samen.
Omdat betrouwbare analyses niet in het dashboard beginnen.
Het begint met de vraag of de onderliggende data echt beschrijft wat de organisatie doet.
De zes publicaties achter dit perspectief
1. Proces-data kwaliteit: De ware grens van procesmining
Arthur H. M. ter Hofstede et al.
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ïdentificeerd en opgelost voordat zinvolle analyse mogelijk is, en slechte kwaliteit gebeurtenisdata verhindert dat process mining zijn volledige organisatorische impact bereikt.
Waarom het belangrijk is voor DTR — Biedt de sterkste onafhankelijke validatie van DTR’s algemene propositie — de waarde van process mining hangt af van de kwaliteit van de gebeurtenisgegevens die eraan worden geleverd.
Relevante DTR-mogelijkheden — Kolomschoonmaker, Row Extractor, Farm Joiner, Column Lookup, Results Dashboards en het semantische datafarmmodel.
2. Extractie, correlatie en abstractie van gebeurtenisgegevens voor process mining
Kiarash Diba, Kimon Batoulis, Matthias Weidlich en Mathias Weske
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.
Waarom het belangrijk is voor DTR — Bijna een conceptueel blauwdruk voor DTR — het definieert het exacte upstreamgebied waarin DTR opereert: extractie, correlatie en abstractie.Relevante DTR-mogelijkheden — 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
3. Richting het begrijpen van de rol van de mens bij het extraheren van gebeurtenislogboeken
Vinicius Stein, Dani et al.
Deze publicatie onderzoekt de essentiële 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 — het verzamelen van gegevens uit verschillende databases en deze omzetten in een geschikt formaat — aanzienlijk is.
Waarom het belangrijk is voor DTR — 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.
Relevante DTR-mogelijkheden — Visueel raffinaderijontwerp, regelgebaseerde configuratie, datapreviews, regel-hit statistieken, zelfdocumenterende transformaties en een gezamenlijk build-and-testproces.
4. Patronen van onvolmaaktheid in gebeurtenislogboeken voor procesmijnbouw: Richting een systematische benadering van het schoonmaken van gebeurtenislogboeken
Suriadi Suriadi, Robert Andrews, Arthur H. M. ter Hofstede en Moe Thandar Wynn
Dit artikel identificeert terugkerende patronen van gebeurtenislog-imperfecties en biedt een systematische basis voor het herkennen en corrigeren van problemen met datakwaliteit. In plaats van schoonmaken als saai, ad hoc werk te behandelen, catalogiseert het 11 terugkerende imperfectiepatronen en stelt het een systematische, patroongebaseerde aanpak voor om ze te identificeren en te repareren.
Waarom het belangrijk is voor DTR — Ondersteunt het omzetten van DTR-transformatorconfiguraties in herbruikbare oplossingen voor terugkerende gebeurtenisgegevensdefecten, in plaats van elke implementatie als uniek engineeringwerk te behandelen.
Relevante DTR-mogelijkheden — kolomschoonmaker, rij-extractor, rijvuller, groepsattributor, deduplicatie, behandeling van ontbrekende waarden en regelbibliotheken.
5. Event-case correlatie voor procesmining met behulp van probabilistische optimalisatie
Dina Bayomie, Claudio Di Ciccio en Jan Mendling
Dit onderzoek behandelt de uitdaging om gebeurtenissen te koppelen aan gevallen wanneer betrouwbare casusidentificaties niet beschikbaar zijn en stelt een probabilistische optimalisatiebenadering voor om die relaties te reconstrueren. Case-IDs ontbreken vaak wanneer data afkomstig is van meerdere systemen of niet-procesbewuste applicaties; De benadering reconstrueert gevallen door tijdgestempelde gebeurtenissen te groeperen op basis van proceskennis, attributen en beperkingen.
Waarom het belangrijk is voor DTR — Valideert direct een van DTR’s meest onderscheidende toepassingen — het reconstrueren van betrouwbare casusidentiteit wanneer identifiers ontbreken, gefragmenteerd zijn, ingebed zijn in technische velden of tijdens uitvoering worden gewijzigd.
Relevante DTR-mogelijkheden — Group Attributor, Row Extractor, Row Filler, Column Lookup, Farm Joiner, case- en parent-case-velden, en timeout- en sequencinglogica..
6. Gebeurtenissen en activiteiten koppelen: Voorbewerking van gebeurtenislogboeken voor procesanalyse
Thomas Baier
Dit promotieonderzoek richt zich op het koppelen van laag-niveau gebeurtenissen aan hogere bedrijfsactiviteiten en is bijzonder relevant voor semantische abstractie en de vertaling van technische gebeurtenissen naar herkenbaar operationeel werk. Omdat geregistreerde technische gebeurtenissen en bedrijfsactiviteiten op verschillende abstractieniveaus bestaan, is het koppelen van deze twee essentieel voor begrijpelijke procesontdekking, conformiteitscontrole en verbetering van procesmodellen.
Waarom het belangrijk is voor DTR — Ondersteunt direct het taak- en activiteitsabstractiemodel van DTR: ruwe applicatierecords vertegenwoordigen niet automatisch herkenbare eenheden van bedrijfswerk.
Relevante DTR-mogelijkheden — Event Namer, Event Group Header, Activity Namer, Farm Converter, actie-object naamgeving, en Subtask, Task and Activity farms.
