Attribute-Activiteitenmatrix
Overzicht
De Attribute-Activiteitenmatrix calculator biedt een uitgebreide kruisverdeling die de relatie tussen attributen en activiteiten in uw eventlog laat zien. Voor elke combinatie van attribuut en activiteit toont deze het aantal cases dat waarden heeft, zodat beheerders patronen in datacompleetheid kunnen begrijpen en datakwaliteitsproblemen kunnen identificeren.
BELANGRIJK: Dit is een calculator uitsluitend voor beheerders, bedoeld voor technische analyse en beoordeling van datakwaliteit. Het genereert een matrix die laat zien hoe attributen worden ingevuld over verschillende activiteiten heen, wat essentieel is voor het begrijpen van data-extractiepatronen, het identificeren van ontbrekende data en het valideren van de eventlog-structuur.
Deze calculator wordt voornamelijk gebruikt door systeembeheerders en datakwaliteitsspecialisten die attributen-populatiepatronen over procesactiviteiten willen begrijpen voor probleemoplossing, validatie of optimalisatie van datasets.
Veelvoorkomende Toepassingen
- Identificeren welke activiteiten specifieke attributen vullen om de dataflow door het proces te begrijpen
- Ontdekken van ontbrekende attribuutwaarden voor activiteiten die data zouden moeten bevatten
- Valideren dat kritieke attributen op de verwachte procesfasen zijn ingevuld
- Problemen bij data-extractie diagnosticeren door systematische hiaten in attribuutpopulatie te identificeren
- Begrijpen van attribuutafhankelijkheden van bepaalde activiteiten voor ETL-ontwerp
- Documenteren welke activiteiten bijdragen aan welke attributen voor technische specificaties
Instellingen
Deze calculator vereist geen specifieke configuratie-instellingen. Bij uitvoering genereert hij automatisch een matrix met alle attributen (zowel case-niveau als event-niveau) tegenover alle activiteiten, waarbij de celwaarden het aantal cases aangeven waarin dat attribuut een waarde heeft voor die activiteit.
Opmerking: Voor datasets met veel attributen en activiteiten kan deze matrix erg groot zijn. De calculator toont de volledige matrix, wat scrollen kan vereisen om alle combinaties te bekijken.
Voorbeelden
Voorbeeld 1: Validatie van de volledigheid van goedkeuringsgegevens
Scenario: U heeft een nieuw systeem voor het bijhouden van goedkeuringen geïmplementeerd en wilt verifiëren dat goedkeuringsgerelateerde attributen correct worden ingevuld bij elke goedkeuringsfase in uw inkooporderproces.
Instellingen:
- Titel: "Analyse van Goedkeuringsattributen populatie"
- Beschrijving: "Valideer vastlegging van goedkeuringsdata in P2P-proces"
Output:
De calculator toont een matrix met activiteiten als kolommen en attributen als rijen. Voor de goedkeuringsattributen ziet u:
| Attribuut | PO Aanmaken | Indienen voor Goedkeuring | L1 Goedkeuring | L2 Goedkeuring | Financiële Goedkeuring | Verzenden naar Leverancier |
|---|---|---|---|---|---|---|
| ApproverName | 0 | 0 | 1,847 | 456 | 234 | 0 |
| ApprovalLevel | 0 | 0 | 1,847 | 456 | 234 | 0 |
| ApprovalTimestamp | 0 | 0 | 1,847 | 456 | 234 | 0 |
| ApprovalComments | 0 | 0 | 1,523 | 398 | 189 | 0 |
| DelegatedBy | 0 | 0 | 234 | 67 | 23 | 0 |
Inzichten: De matrix bevestigt dat goedkeuringsattributen alleen correct zijn ingevuld tijdens goedkeuringsactiviteiten (L1, L2, en Financiële goedkeuring), en nergens anders, zoals verwacht. Alle 1.847 cases die L1 Goedkeuring bereiken, hebben ApproverName, ApprovalLevel, en ApprovalTimestamp ingevuld, wat duidt op volledige datavastlegging. ApprovalComments heeft een lagere populatie (1.523 cases ipv. 1.847), wat betekent dat 324 cases geen opmerkingen bij goedkeuring bevatten - dit kan acceptabel zijn als opmerkingen optioneel zijn, maar verdient verdere inspectie. Het attribuut DelegatedBy verschijnt alleen bij een subgroep van goedkeuringen, wat correct de delegeringsscenario's vastlegt.
Voorbeeld 2: Identificeren van datakwaliteitshiaten bij extractie
Scenario: Na het samenvoegen van data uit meerdere bronsystemen in uw order-to-cash proces vermoedt u dat sommige attributen niet consistent worden ingevuld over alle verwachte activiteiten.
Instellingen:
- Titel: "Data Volledigheidscontrole Multi-Source"
- Beschrijving: "Valideer attribuutpopulatie vanuit CRM, ERP en verzendsystemen"
Output:
| Attribuut | Order Aanmaken | Kredietcontrole | Artikelen Picken | Artikelen Verpakken | Verzenden | Factuur Genereren | Ontvang Betaling |
|---|---|---|---|---|---|---|---|
| CustomerName | 2,456 | 2,456 | 2,456 | 2,456 | 2,456 | 2,456 | 2,456 |
| CreditScore | 2,456 | 2,456 | 2,456 | 2,456 | 2,456 | 2,456 | 2,456 |
| WarehouseLocation | 0 | 0 | 2,456 | 2,456 | 2,456 | 0 | 0 |
| CarrierName | 0 | 0 | 0 | 0 | 2,456 | 0 | 0 |
| TrackingNumber | 0 | 0 | 0 | 0 | 2,234 | 0 | 0 |
| InvoiceAmount | 0 | 0 | 0 | 0 | 0 | 2,456 | 2,456 |
| PaymentMethod | 0 | 0 | 0 | 0 | 0 | 0 | 1,987 |
Inzichten: De matrix toont verschillende datakwaliteitsproblemen. CustomerName en CreditScore zijn case-niveau attributen (over alle activiteiten gevuld voor alle cases), wat verwacht is. WarehouseLocation verschijnt correct alleen bij warehouse-activiteiten (Pick, Pack, Ship). TrackingNumber toont slechts 2.234 cases in plaats van de verwachte 2.456 bij activiteit Ship, wat betekent dat 222 zendingen track-and-trace nummers missen - een kritisch probleem dat nader onderzoek vereist. PaymentMethod verschijnt slechts in 1.987 gevallen bij Ontvang Betaling, in plaats van 2.456, wat suggereert dat 469 betalingen ontbrekende betalingswijzegegevens hebben, mogelijk door een integratieprobleem met het betalingssysteem.
Voorbeeld 3: Begrijpen van de levenscyclus van attributen
Scenario: U moet documenteren wanneer specifieke attributen beschikbaar komen tijdens de proceslevenscyclus om downstream analyses en rapportageontwerp te begeleiden.
Instellingen:
- Titel: "Documentatie van Attribuutlevenscyclus"
- Beschrijving: "Kaart wanneer elk attribuut wordt ingevuld in factuurverwerking"
Output:
| Attribuut | Factuur Ontvangen | Factuur Valideren | Matchen met PO | Betaling Goedkeuren | Betaling Inplannen | Betaling Uitvoeren | Case Sluiten |
|---|---|---|---|---|---|---|---|
| InvoiceNumber | 3,456 | 3,456 | 3,456 | 3,456 | 3,456 | 3,456 | 3,456 |
| VendorID | 3,456 | 3,456 | 3,456 | 3,456 | 3,456 | 3,456 | 3,456 |
| PONumber | 0 | 0 | 3,456 | 3,456 | 3,456 | 3,456 | 3,456 |
| MatchStatus | 0 | 0 | 3,456 | 3,456 | 3,456 | 3,456 | 3,456 |
| ApprovedAmount | 0 | 0 | 0 | 3,456 | 3,456 | 3,456 | 3,456 |
| PaymentDate | 0 | 0 | 0 | 0 | 3,456 | 3,456 | 3,456 |
| ActualPaymentDate | 0 | 0 | 0 | 0 | 0 | 3,456 | 3,456 |
| ClosureReason | 0 | 0 | 0 | 0 | 0 | 0 | 3,456 |
Inzichten: Deze matrix toont duidelijk de levenscyclus van attributen. InvoiceNumber en VendorID zijn vanaf het begin gevuld (case-niveau attributen ingesteld bij ontvangst van de factuur). PONumber en MatchStatus zijn pas beschikbaar na de activiteit Matchen met PO, waardoor ze in eerdere procesfasen niet beschikbaar zijn. ApprovedAmount verschijnt bij Betaling Goedkeuren en blijft gedurende de volgende activiteiten beschikbaar. PaymentDate (geplande datum) verschijnt bij Betaling Inplannen, terwijl ActualPaymentDate alleen bij Betaling Uitvoeren voorkomt, wat het verschil tussen geplande en daadwerkelijke datums weergeeft. ClosureReason wordt alleen bij de laatste activiteit ingevuld. Dit begrip van de levenscyclus is cruciaal voor het ontwerpen van analyses die op specifieke attributen vertrouwen.
Voorbeeld 4: Detecteren van systematische datakwaliteitsproblemen
Scenario: Gebruikers melden inconsistentie in data beschikbaarheid in analyses. U wilt identificeren of bepaalde activiteiten systematisch nalaten de verwachte attributen in te vullen.
Instellingen:
- Titel: "Systematische Data Hiaten Analyse"
- Beschrijving: "Identificeer activiteiten met ontbrekende attribuutpopulatie"
Output:
| Attribuut | Verzoek Controleren | Middelen Toewijzen | Werk Starten | Kwaliteitscontrole | Werk Voltooien | Resultaten Documenteren |
|---|---|---|---|---|---|---|
| RequestID | 5,678 | 5,678 | 5,678 | 5,678 | 5,678 | 5,678 |
| AssignedTo | 0 | 5,678 | 5,678 | 5,678 | 5,678 | 5,678 |
| WorkCategory | 0 | 5,678 | 5,678 | 5,678 | 5,678 | 5,678 |
| StartTime | 0 | 0 | 5,678 | 5,678 | 5,678 | 5,678 |
| QualityScore | 0 | 0 | 0 | 4,234 | 4,234 | 4,234 |
| CompletionNotes | 0 | 0 | 0 | 0 | 5,678 | 5,678 |
| DocumentationLink | 0 | 0 | 0 | 0 | 0 | 3,456 |
Inzichten: De matrix toont een kritisch datakwaliteitsprobleem. QualityScore zou bij Kwaliteitscontrole in alle 5.678 cases ingevuld moeten zijn, maar slechts 4.234 cases hebben deze waarde, wat betekent dat 1.444 cases (25%) geen kwaliteitsbeoordeling hebben. Dit is een systematisch probleem dat kan duiden op fouten in het kwaliteitscontrolesysteem of data-extractie. Daarnaast ontbreekt DocumentationLink in 2.222 cases (39%) bij Resultaten Documenteren, wat suggereert dat de documentatie voor een significant deel van het werk wordt overgeslagen. Deze systematische hiaten vereisen onmiddellijke aandacht om dataintegriteit te waarborgen.
Voorbeeld 5: Validatie van multi-systeem integratie
Scenario: Uw proces integreert data uit drie verschillende systemen (CRM, ERP, en logistiek), en u moet verifiëren dat attributen uit elk systeem correct zijn gekoppeld aan de juiste activiteiten.
Instellingen:
- Titel: "Validatie Multi-Systeem Integratie"
- Beschrijving: "Verifieer attribuutpopulatie vanuit CRM, ERP en logistieke systemen"
Output:
| Attribuut | Order Invoeren (CRM) | Voorraad Reserveren (ERP) | Voorraad Alloceren (ERP) | Verzenden (Logistiek) | Levering (Logistiek) | Ontvangst Bevestigen (CRM) |
|---|---|---|---|---|---|---|
| CustomerID (CRM) | 8,945 | 8,945 | 8,945 | 8,945 | 8,945 | 8,945 |
| SalesRepID (CRM) | 8,945 | 8,945 | 8,945 | 8,945 | 8,945 | 8,945 |
| SKU (ERP) | 8,945 | 8,945 | 8,945 | 8,945 | 8,945 | 8,945 |
| InventoryLocation (ERP) | 0 | 8,945 | 8,945 | 8,945 | 8,945 | 8,945 |
| StockLevel (ERP) | 0 | 8,945 | 8,945 | 8,945 | 8,945 | 8,945 |
| CarrierID (Logistiek) | 0 | 0 | 0 | 8,945 | 8,945 | 8,945 |
| DeliveryStatus (Logistiek) | 0 | 0 | 0 | 8,945 | 8,945 | 8,945 |
| ReceivedBy (CRM) | 0 | 0 | 0 | 0 | 0 | 7,234 |
Inzichten: De matrix valideert dat de meeste systeemintegraties correct functioneren. CRM-attributen (CustomerID, SalesRepID) zijn over het hele proces beschikbaar zoals verwacht voor case-niveau attributen. ERP-attributen (InventoryLocation, StockLevel) verschijnen correct vanaf de activiteit Voorraad Reserveren. Logistieke attributen (CarrierID, DeliveryStatus) komen terecht vanaf Verzenden. Er is echter een significant probleem met het attribuut ReceivedBy – slechts 7.234 cases van de 8.945 hebben dit ingevuld bij Ontvangst Bevestigen, wat betekent dat 1.711 leveringen (19%) geen bevestiging hebben van wie de order ontving. Dit vereist nader onderzoek van de CRM bevestigingsworkflow.
Voorbeeld 6: Plannen van een strategie voor attribuutsverbetering
Scenario: U wilt identificeren welke attributen schaars zijn ingevuld en kunnen profiteren van verrijking met referentiedata of verbeterde datacaptatieprocessen.
Instellingen:
- Titel: "Analyse Mogelijkheden Attribuutsverrijking"
- Beschrijving: "Identificeer schaarse attributen die verrijking nodig hebben"
Output:
| Attribuut | Claim Indienen | Documenten Reviewen | Schade Beoordelen | Bedrag Goedkeuren | Betaling Uitvoeren | Claim Sluiten |
|---|---|---|---|---|---|---|
| ClaimNumber | 12,456 | 12,456 | 12,456 | 12,456 | 12,456 | 12,456 |
| PolicyNumber | 12,456 | 12,456 | 12,456 | 12,456 | 12,456 | 12,456 |
| AdjusterID | 0 | 12,456 | 12,456 | 12,456 | 12,456 | 12,456 |
| AdjusterName | 0 | 0 | 0 | 0 | 0 | 0 |
| DamageCategory | 0 | 0 | 12,456 | 12,456 | 12,456 | 12,456 |
| EstimatedCost | 0 | 0 | 12,456 | 12,456 | 12,456 | 12,456 |
| ApprovalReason | 0 | 0 | 0 | 12,456 | 12,456 | 12,456 |
| PaymentMethodCode | 0 | 0 | 0 | 0 | 12,456 | 12,456 |
| PaymentMethodName | 0 | 0 | 0 | 0 | 0 | 0 |
Inzichten: De matrix toont uitstekende mogelijkheden voor verrijking. AdjusterID is vanaf Review Documents voor alle cases gevuld (12,456 cases), maar AdjusterName wordt nooit ingevuld. Verrijking van AdjusterID met de naam van de schade-expert via een medewerkers-opzoektafel zou analyses gebruiksvriendelijker maken. Evenzo is PaymentMethodCode ingevuld voor alle betalingen (12,456 cases), maar PaymentMethodName ontbreekt. Verrijking van betaalmethodecodes met beschrijvende namen zou de leesbaarheid van rapportages aanzienlijk verbeteren. Deze verrijkingen zouden met minimale inspanning aanzienlijke waarde toevoegen, omdat de referentie-ID’s al aanwezig zijn.
Output
De Attribute-Activiteitenmatrix calculator toont een uitgebreide mattabel met de volgende structuur:
Rijen: Elke rij vertegenwoordigt één attribuut uit uw eventlog, inclusief case-niveau attributen (van toepassing op de hele case) en event-niveau attributen (die per activiteit kunnen verschillen).
Kolommen: Elke kolom vertegenwoordigt één unieke activiteit uit uw proces.
Celwaarden: Elke cel bevat een getal dat aangeeft voor hoeveel cases dat attribuut voor die activiteit een waarde heeft. Een waarde van 0 betekent dat het attribuut niet is ingevuld voor cases bij die activiteit.
Begrijpen van celwaarden
Case-niveau attributen: Voor case-niveau attributen (zoals CustomerID, OrderNumber, enz.) is de celwaarde hetzelfde voor alle activiteiten in die rij, en toont het totaal aantal cases waarin het attribuut een waarde heeft.
Event-niveau attributen: Voor event-niveau attributen (zoals ApproverName, WarehouseLocation, enz.) variëren de celwaarden per activiteit, en tonen ze waar in het proces dat attribuut wordt ingevuld.
Nulwaarden: Een celwaarde van 0 betekent dat het attribuut bij die activiteit nooit wordt ingevuld. Dit kan verwacht gedrag zijn, of een datakwaliteitsprobleem afhankelijk van uw proces.
Interactieve functies
Sorteren en filteren: Klik op kolomkoppen om de matrix op activiteit te sorteren. Gebruik de browserzoekfunctie om snel specifieke attributen te vinden.
Resultaten exporteren: Exporteer de volledige matrix naar Excel of CSV voor gedetailleerde offline analyse, documentatie of delen met technische teams.
Grote matrices: Voor processen met veel activiteiten en attributen kan de matrix erg groot zijn. Gebruik horizontaal en verticaal scrollen om de volledige matrix te bekijken.
Interpreteren van populatiepatronen
Consistente populatie: Als een attribuut dezelfde niet-nulwaarde laat zien over alle activiteiten, betreft het een case-niveau attribuut dat vroeg in het proces wordt ingevuld.
Progressieve populatie: Als een attribuut nulwaarden toont voor vroege activiteiten en niet-nulwaarden voor latere activiteiten, duidt dit erop dat het attribuut bij een specifieke procesfase wordt ingevuld.
Deelpopulatie: Als een attribuut een waarde toont die lager is dan het totaal aantal cases, missen sommige cases dat attribuut, wat kan wijzen op datakwaliteitsproblemen of optionele velden.
Activiteit-specifieke populatie: Als een attribuut alleen niet-nulwaarden laat zien voor specifieke activiteiten, betreft het een event-niveau attribuut dat alleen relevant is voor deze activiteiten.
Prestatieoverwegingen
- Grote datasets: Voor datasets met honderden attributen en activiteiten kan deze calculator aanzienlijke verwerkingstijd vragen
- Resourcegebruik: De calculator scant alle combinaties van attribuut en activiteit, wat computational intensief is
- Best practices: Voer deze calculator uit tijdens daluren bij zeer grote datasets
Administratieve Toegang
Deze calculator is beperkt tot gebruikers met de rol Administrator. Reguliere gebruikers die datasetkenmerken willen begrijpen, kunnen in plaats daarvan de Dataset Information calculator gebruiken, die samenvattende metrics biedt zonder de gedetailleerde attribuut-activiteitverdeling.
Deze documentatie maakt deel uit van het mindzieStudio process mining platform.