Duur Tussen Twee Evenementattributen

Overzicht

De verrijking Duur Tussen Twee Evenementattributen berekent het tijdsverschil tussen twee tijdstempel- of tijdsduurvelden binnen hetzelfde gebeurtenisrecord. Deze krachtige verrijking stelt je in staat om verstreken tijd te meten tussen gerelateerde temporele gegevenspunten die op afzonderlijke evenementen aanwezig zijn, zoals de tijd tussen een geplande afspraak en de daadwerkelijke aankomst, of tussen het indienen van een verzoek en goedkeuring binnen één transactie.

In tegenstelling tot verrijkingen die duur meten over verschillende gebeurtenissen in een case, werkt deze operator exclusief op het evenementniveau en vergelijkt hij twee datetime- of timespan-attributen die al bestaan op elk evenement. Dit maakt het bijzonder waardevol voor het analyseren van vertragingen, doorlooptijden en omkeermetingen waarbij zowel de start- als eindtijdstempels als aparte velden in jouw bronsysteem worden vastgelegd. De verrijking ondersteunt zowel DateTime- als TimeSpan-attributen, en biedt maximale flexibiliteit voor diverse tijdberekeningen.

De verrijking creëert een nieuw timespan-attribuut op evenementniveau met de berekende duur, dat vervolgens kan worden gebruikt in filters, visualisaties en prestatieanalyses om knelpunten te identificeren, naleving van serviceniveaus te meten en timingvariaties in jouw procesinstanties te begrijpen. De berekening wordt uitgevoerd als (Attribute Last - Attribute First), waardoor zowel positieve duur (wanneer evenementen vertraging hebben) als negatieve duur (wanneer evenementen vroegtijdig worden afgerond of eerder aankomen) mogelijk is.

Veelvoorkomende Toepassingen

  • Bereken afspraakvertraging door de tijd te meten tussen geplande afspraaktijd en daadwerkelijke aankomsttijd van patiënten in zorgprocessen
  • Meet doorlooptijd van goedkeuring door tijdstempel bij indiening te vergelijken met goedkeuringstijdstempel in hetzelfde transactierecord
  • Volg verzendvertragingen door het verschil te berekenen tussen beloofde leverdatum en daadwerkelijke leverdatum
  • Analyseer reactietijd door de duur te meten tussen tijdstempel van klantvraag en eerste reactie
  • Evalueer schema-naleving door geplande starttijd te vergelijken met daadwerkelijke starttijd voor onderhoudsactiviteiten
  • Meet verwerkefficiëntie door tijd te berekenen tussen ontvangsttijdstempel document en voltooiingstijdstempel verwerking
  • Bewaak SLA-naleving door tijd te meten tussen ticketcreatie en eerste respons binnen supportticketrecords
  • Volg productieplansverschillen door geplande versus daadwerkelijke productiestarttijden te vergelijken

Instellingen

Nieuwe Attribuutnaam: De naam van het nieuwe evenementattribuut dat het berekende tijdsverschil opslaat. Dit attribuut wordt aangemaakt als een TimeSpan datatype en verschijnt in jouw evenemententabel naast andere evenementattributen. Kies een beschrijvende naam die duidelijk aangeeft welke duur wordt gemeten, zoals "Goedkeuringsvertraging", "Leveringsvariantie" of "Verwerkingstijd". De attribuutnaam dient te voldoen aan de naamgevingsconventies van jouw organisatie en betekenisvol te zijn bij gebruik in filters en visualisaties. Dit veld accepteert elke geldige attribuutnaam en wordt de identifier om de berekende duur in volgende analysetappen te benaderen.

Attribuutnaam Eerste: Het evenementattribuut dat de vroegere tijdstempel in de duurberekening bevat. Dit moet een bestaand DateTime- of TimeSpan-attribuut zijn in jouw evenemententabel. De verrijking gebruikt dit als startpunt voor de duurmeting. Bijvoorbeeld, bij het meten van afspraakvertragingen is dit het veld "Geplande Afspraaktijd". De dropdown filtert automatisch op geldige DateTime- en TimeSpan-attributen uit jouw evenemententabel, met uitsluiting van berekende en verborgen attributen. Dit garandeert dat je alleen geschikte temporele data voor de berekening kunt selecteren.

Attribuutnaam Laatste: Het evenementattribuut dat de latere tijdstempel in de duurberekening bevat. Dit moet een bestaand DateTime- of TimeSpan-attribuut zijn in jouw evenemententabel. De verrijking gebruikt dit als eindpunt voor de duurmeting. Bijvoorbeeld, bij het meten van afspraakvertragingen is dit het veld "Werkelijke Aankomsttijd". De berekening wordt uitgevoerd als (Attribuutnaam Laatste - Attribuutnaam Eerste), zorg dat je hier de chronologisch latere tijdstempel selecteert. Positieve resultaten betekenen dat de tweede tijdstempel na de eerste valt (vertraging of duur), terwijl negatieve resultaten aangeven dat de tweede tijdstempel vóór de eerste valt (vroege voltooiing).

Voorbeelden

Voorbeeld 1: Analyse van Afspraakvertraging in de Zorg

Scenario: Een medische kliniek wil afspraakvertragingen meten door geplande afspraaktijden te vergelijken met daadwerkelijke aankomsttijden. Beide tijdstempels worden in hun afsprakensysteem als aparte velden op elk afspraakevenement vastgelegd. Inzicht in deze vertragingen helpt bij het optimaliseren van de planning en verhoging van patiënttevredenheid.

Instellingen:

  • Nieuwe Attribuutnaam: Afspraakvertraging
  • Attribuutnaam Eerste: Geplande Tijd
  • Attribuutnaam Laatste: Werkelijke Aankomsttijd

Resultaat: De verrijking creëert een nieuw evenementattribuut "Afspraakvertraging" met TimeSpan-waarden die het verschil tussen geplande en werkelijke tijden weergeven:

  • Evenementen waar patiënten te vroeg aankomen, geven negatieve duurwaarden (bijv. -00:15:00 voor 15 minuten te vroeg)
  • Evenementen waar patiënten op tijd zijn, tonen nul of bijna nul duurwaarden (bijv. 00:02:00 voor 2 minuten te laat)
  • Evenementen waar patiënten te laat zijn, tonen positieve duurwaarden (bijv. 00:45:00 voor 45 minuten te laat)

Voorbeeldgegevens: | Patient ID | Geplande Tijd | Werkelijke Aankomsttijd | Afspraakvertraging | |------------|---------------|-------------------------|--------------------| | P-1001 | 2024-01-15 09:00 | 2024-01-15 09:12 | 00:12:00 | | P-1002 | 2024-01-15 10:30 | 2024-01-15 10:25 | -00:05:00 | | P-1003 | 2024-01-15 14:00 | 2024-01-15 14:38 | 00:38:00 |

Inzichten: De kliniek ontdekte dat 35% van de patiënten meer dan 15 minuten te laat verschijnen voor afspraken in de middag, wat leidt tot opeenvolgende vertragingen in het schema. Ze hebben hun planningsalgoritme aangepast door buffer tijd toe te voegen tussen middagsessies, wat de wachttijd met 22% verminderde.

Voorbeeld 2: Doorlooptijd Goedkeuring Inkooporder

Scenario: Een inkoopafdeling wil de tijd meten tussen indiening van een inkooporder en de goedkeuring ervan. Beide tijdstempels bestaan in hun ERP-systeem als aparte velden op elk PO-record. Het volgen van deze doorlooptijd helpt goedkeuringsknelpunten identificeren en tijdige aankoopbeslissingen garanderen.

Instellingen:

  • Nieuwe Attribuutnaam: Doorlooptijd Goedkeuring
  • Attribuutnaam Eerste: Tijdstip Indiening
  • Attribuutnaam Laatste: Tijdstip Goedkeuring

Resultaat: Een nieuw evenementattribuut "Doorlooptijd Goedkeuring" wordt aangemaakt dat de verstreken tijd voor elke PO-goedkeuring laat zien:

  • Snelle goedkeuringen: 00:15:30 (15 minuten en 30 seconden)
  • Normale goedkeuringen: 1.08:20:00 (1 dag, 8 uur, 20 minuten)
  • Vertraagde goedkeuringen: 5.14:30:00 (5 dagen, 14 uur, 30 minuten)

Voorbeeldgegevens: | PO Nummer | Bedrag | Tijdstip Indiening | Tijdstip Goedkeuring | Doorlooptijd Goedkeuring | |-----------|--------|-------------------|---------------------|--------------------------| | PO-8821 | $450 | 2024-02-10 08:30 | 2024-02-10 09:15 | 00:45:00 | | PO-8822 | $15,200 | 2024-02-10 10:00 | 2024-02-12 14:30 | 2.04:30:00 | | PO-8823 | $89,500 | 2024-02-10 11:20 | 2024-02-16 09:45 | 5.22:25:00 |

Inzichten: Analyse toonde aan dat inkooporders boven $50.000 gemiddeld 4,5 dag nodig hebben voor goedkeuring, terwijl orders onder $1.000 binnen 2 uur worden goedgekeurd. De organisatie implementeerde geautomatiseerde goedkeuringsworkflows voor lage waarde aankopen, wat de totale goedkeuringstijd met 40% reduceerde.

Voorbeeld 3: Naleving Productieplanning

Scenario: Een fabriek volgt geplande starttijden versus daadwerkelijke starttijden van productieruns. Elke productorder heeft een geplande starttijd en een werkelijke starttijd vastgelegd in hun MES (Manufacturing Execution System). Het meten van deze afwijkingen helpt bij het beoordelen van planningsnauwkeurigheid en capaciteitsplanning.

Instellingen:

  • Nieuwe Attribuutnaam: Starttijdsafwijking
  • Attribuutnaam Eerste: Geplande Starttijd
  • Attribuutnaam Laatste: Werkelijke Starttijd

Resultaat: Het attribuut "Starttijdsafwijking" toont of productieruns vroeg (negatief), op tijd (bijna nul) of laat (positief) zijn gestart:

  • Vroege starts wijzen op beschikbare capaciteit of schemaflexibiliteit
  • Late starts geven planningconflicten of upstream vertragingen aan
  • Consistente patronen helpen productieplanning optimaliseren

Voorbeeldgegevens: | Werkorder | Productielijn | Geplande Starttijd | Werkelijke Starttijd | Starttijdsafwijking | |-----------|--------------|--------------------|---------------------|---------------------| | WO-5501 | Lijn A | 2024-03-05 06:00 | 2024-03-05 06:00 | 00:00:00 | | WO-5502 | Lijn B | 2024-03-05 08:00 | 2024-03-05 09:45 | 01:45:00 | | WO-5503 | Lijn C | 2024-03-05 12:00 | 2024-03-05 11:50 | -00:10:00 |

Inzichten: De fabriek ontdekte dat Lijn B consequent 1-2 uur te laat start door langere omsteltijden van de vorige shift. Door parallelle omstelactiviteiten te implementeren, verminderden ze de gemiddelde starttijdsafwijking van 90 minuten tot 15 minuten en verhoogden ze de dagelijkse productiecapaciteit met 8%.

Voorbeeld 4: Reactietijd Klantenservice

Scenario: Een klantenserviceorganisatie wil meten hoe snel agenten hun eerste reactie op binnenkomende supporttickets geven. Hun ticketsysteem registreert zowel het aanmaaktijdstip van het ticket als het tijdstip van de eerste reactie als aparte velden. Het monitoren van deze reactietijd is cruciaal voor SLA-naleving en klanttevredenheid.

Instellingen:

  • Nieuwe Attribuutnaam: Tijd Tot Eerste Reactie
  • Attribuutnaam Eerste: Aanmaakdatum Tijdstip
  • Attribuutnaam Laatste: Tijdstip Eerste Reactie

Resultaat: De verrijking produceert het attribuut "Tijd Tot Eerste Reactie" met verstreken tijd tot eerste reactie voor elk ticket:

  • Uitstekende reactie: 00:08:30 (8 minuten 30 seconden)
  • SLA gehaald: 00:55:20 (55 minuten 20 seconden)
  • SLA overtreden: 02:15:45 (2 uur 15 minuten 45 seconden)

Voorbeeldgegevens: | Ticket ID | Prioriteit | Aanmaakdatum Tijdstip | Tijdstip Eerste Reactie | Tijd Tot Eerste Reactie | |-----------|------------|----------------------|------------------------|------------------------| | TKT-9001 | Hoog | 2024-04-12 10:22 | 2024-04-12 10:30 | 00:08:00 | | TKT-9002 | Medium | 2024-04-12 11:15 | 2024-04-12 12:05 | 00:50:00 | | TKT-9003 | Laag | 2024-04-12 14:30 | 2024-04-12 16:55 | 02:25:00 |

Inzichten: Het supportteam ontdekte dat tickets met hoge prioriteit gemiddeld 12 minuten nodig hebben tot eerste reactie, ruim binnen hun SLA van 30 minuten, maar tickets met gemiddelde prioriteit gemiddeld 75 minuten tegen een streefwaarde van 60 minuten. Ze pasten hun triageproces en personeelsniveaus aan om tickets met gemiddelde prioriteit te prioriteren, waardoor de SLA-naleving steeg van 78% naar 94%.

Voorbeeld 5: Logistieke Leveringsprestaties

Scenario: Een logistiek bedrijf wil leveringsprestaties analyseren door beloofde leverdatums te vergelijken met daadwerkelijke leverdatums. Beide datums worden vastgelegd in hun zendingvolgsysteem bij ordercreatie en leveringsbevestiging. Inzicht in leveringsvariantie helpt vervoerdersprestaties te identificeren en klantverwachtingen te verbeteren.

Instellingen:

  • Nieuwe Attribuutnaam: Leveringsvariantie
  • Attribuutnaam Eerste: Beloofde Leverdatum
  • Attribuutnaam Laatste: Werkelijke Leverdatum

Resultaat: Het attribuut "Leveringsvariantie" geeft aan of leveringen vroeg (negatief), op tijd (nul of klein positief) of laat (positief) waren:

  • Vroege leveringen: -1.00:00:00 (1 dag te vroeg)
  • Op tijd leveringen: 00:00:00 tot 04:00:00 (op tijd tot 4 uur te laat)
  • Late leveringen: 2.08:30:00 (2 dagen 8 uur 30 minuten te laat)

Voorbeeldgegevens: | Zending ID | Vervoerder | Beloofde Leverdatum | Werkelijke Leverdatum | Leveringsvariantie | |------------|------------|---------------------|----------------------|--------------------| | SHP-7701 | FastShip | 2024-05-20 17:00 | 2024-05-20 15:30 | -01:30:00 | | SHP-7702 | QuickCargo | 2024-05-21 12:00 | 2024-05-21 11:45 | -00:15:00 | | SHP-7703 | StandardPost | 2024-05-22 10:00 | 2024-05-24 14:20 | 2.04:20:00 |

Inzichten: Analyse toonde aan dat 18% van de leveringen meer dan 1 dag te laat waren, waarbij StandardPost voor 65% van deze vertragingen verantwoordelijk is. Het bedrijf heronderhandelde serviceniveaus met vervoerders en implementeerde een dynamisch vervoerderselectie-algoritme gebaseerd op historische prestaties, waarmee late leveringen werden teruggebracht van 18% naar 7% en de klanttevredenheidsscores met 15 punten stegen.

Output

De verrijking Duur Tussen Twee Evenementattributen creëert een enkel nieuw evenementattribuut met de volgende kenmerken:

Datatype: TimeSpan - Het nieuwe attribuut slaat duurwaarden op in TimeSpan-formaat, dat het tijdsverschil tussen de twee geselecteerde attributen vertegenwoordigt. TimeSpan-waarden kunnen positief zijn (wanneer de tweede tijdstempel later is), negatief (wanneer de tweede tijdstempel eerder is) of nul (wanneer beide tijdstempels identiek zijn).

Locatie Attribuut: Het nieuwe attribuut wordt toegevoegd aan de evenemententabel en verschijnt naast andere evenementattributen in jouw dataset. Het wordt gemarkeerd als een afgeleid attribuut en is zichtbaar in evenementfilters, lijsten met evenementattributen en kan via statistische verrijkingen worden geaggregeerd naar case-niveau.

Berekeningsmethode: Voor elk evenement wordt (Attribuutnaam Laatste - Attribuutnaam Eerste) berekend. Als een van de bronattributen null of ontbrekend is voor een bepaald evenement, blijft het nieuwe attribuut voor dat evenement null, zodat dataintegriteit behouden blijft zonder onjuiste nultijden te creëren.

Weergaveformaat: TimeSpan-waarden worden weergegeven in standaard duurformaat (dagen.uren:minuten:seconden). Bijvoorbeeld:

  • 00:15:30 staat voor 15 minuten en 30 seconden
  • 1.08:20:00 staat voor 1 dag, 8 uur en 20 minuten
  • -00:05:00 staat voor negatieve 5 minuten (vroegere aankomst)

Integratie Met Andere Functies: Het berekende duurattribuut kan op verschillende manieren worden gebruikt:

  • Evenementfilters: Filter evenementen op duurgrenzen (bijv. alleen evenementen tonen waar reactietijd langer dan 1 uur is)
  • Caseaggregaties: Gebruik Sum, Average, Min of Max verrijkingen om duurwaarden op evenementniveau te aggregeren naar case-niveau
  • Prestatieanalyse: Visualiseer duurverdelingen in grafieken en identificeer afwijkingen
  • Rekenmachines: Verwijs naar de duur in aangepaste rekenkundige expressies voor complexe bedrijfslogica
  • Conformance Checking: Definieer nalevingsregels op basis van acceptabele duurintervallen

Afhankelijkheden: De verrijking is afhankelijk van de twee bronattributen die in de configuratie zijn opgegeven. Wordt een van deze bronattributen hernoemd, verborgen of verwijderd uit de dataset, dan moet de berekende duurattribuut opnieuw worden ingesteld of wordt deze mogelijk ongeldig. De verrijking bewaakt deze afhankelijkheden en waarschuwt gebruikers bij wijzigingen in bronattributen.

Prestatieoverwegingen: Deze verrijking voert voor elk evenement een eenvoudige aftreksom uit en heeft minimale impact op de prestaties, zelfs bij grote datasets met miljoenen evenementen. De berekening wordt één keer uitgevoerd bij het toepassen van de verrijking en de resultaten worden opgeslagen, zodat latere analysetaken direct de vooraf berekende waarden gebruiken zonder extra berekeningen.

Zie Ook

Deze documentatie maakt deel uit van het mindzie Studio process mining platform.