Correcte Tijdzone

Overzicht

De Correcte Tijdzone verrijking past automatisch alle tijdstempels in uw process mining dataset aan van UTC (Coordinated Universal Time) naar een opgegeven lokale tijdzone. Deze verrijking is essentieel bij het analyseren van processen die meerdere geografische regio's omvatten of wanneer uw bronsystemen tijdstempels in UTC-formaat opslaan die moeten worden omgezet naar lokale kantooruren voor een nauwkeurige analyse.

Deze verrijking voert een uitgebreide conversie uit over uw gehele dataset, waarbij alle datum-/tijdwaarden in zowel case-attributen als gebeurtenisattributen worden getransformeerd om de correcte lokale tijdzone weer te geven. Dit zorgt ervoor dat tijdgebaseerde analyses, zoals berekeningen van werktijden, shiftanalyses en dagelijkse/weekpatronen, nauwkeurig de zakelijke realiteit in de lokale tijdzone waar de processen daadwerkelijk plaatsvinden, weerspiegelen.

Veelvoorkomende Toepassingen

  • Converteer UTC-tijdstempels van globale ERP-systemen naar lokale bedrijfstijdzones voor nauwkeurige analyse van werktijden
  • Breng tijdstempels uit meerdere bronsystemen met verschillende tijdzoneconventies in lijn naar één consistente lokale tijd
  • Bereid data voor shiftgebaseerde analyses voor door alle tijdstempels af te stemmen op de daadwerkelijke lokale tijd waarop werk werd uitgevoerd
  • Maak nauwkeurige berekening van bedrijfsuurstatistieken mogelijk door te converteren naar de tijdzone waarin het proces plaatsvindt
  • Ondersteun compliancerapportages die vereisen dat tijdstempels in specifieke regionale tijdzones worden weergegeven
  • Faciliteer procesvergelijkingen over regio’s heen door tijdstempels te standaardiseren naar de tijdzone van het hoofdkantoor
  • Corrigeer de weergave van tijdstempels voor zakelijke gebruikers die gebeurtenissen in hun lokale tijd willen zien in plaats van systeemtijd

Instellingen

Deze verrijking werkt automatisch met behulp van de tijdzoneconfiguratie die op datasetniveau is gespecificeerd. Er zijn geen aanvullende instellingen vereist in de verrijking zelf.

Dataset Tijdzone: De doeltijdzone voor conversie wordt geconfigureerd tijdens het importeren of configureren van uw dataset in mindzieStudio. De verrijking leest deze configuratie uit en past deze consistent toe op alle tijdstempels. Veelvoorkomende tijdzones zijn onder andere:

  • Eastern Standard Time
  • Pacific Standard Time
  • Central European Time
  • Greenwich Mean Time
  • Australia Eastern Standard Time
  • En alle andere standaard Windows tijdzone-identifiers

Automatische Detectie: De verrijking identificeert automatisch alle datum/tijd-kolommen in uw dataset (zowel in case- als gebeurtenisattributen) en converteert elke tijdstempel van UTC naar de opgegeven lokale tijdzone. Alleen tijdstempels die een tijdcomponent hebben (niet alleen datum) worden geconverteerd.

Overslaan Als Reeds Lokaal: Als uw dataset al is geconverteerd naar lokale tijd (aangegeven door de IsLocalTime-vlag), slaat deze verrijking de verwerking over om dubbele conversie te voorkomen.

Voorbeelden

Voorbeeld 1: Globale Productieprocesanalyse

Scenario: Een multinationaal productiebedrijf heeft fabrieken in Duitsland, China en Mexico, die allemaal rapporteren aan een SAP-systeem dat tijdstempels in UTC opslaat. Het Europese hoofdkantoor moet productieprocessen analyseren in Central European Time om aan te sluiten bij de bedrijfsrapportage.

Instellingen:

  • Dataset Tijdzone: Central European Standard Time
  • Geen aanvullende verrijkingsinstellingen vereist

Output: Oorspronkelijke UTC-tijdstempels worden geconverteerd naar CET/CEST:

  • UTC Gebeurtenis: 2024-03-15 14:30:00 wordt CET: 2024-03-15 15:30:00 (wintertijd)
  • UTC Gebeurtenis: 2024-07-15 14:30:00 wordt CEST: 2024-07-15 16:30:00 (zomertijd)

Alle case-attributen met tijdstempels (Order Date, Delivery Date, Payment Date) en gebeurtenistijdstempels worden automatisch aangepast. Dit maakt nauwkeurige analyse van werktijden (8:00-17:00 CET) en identificatie van overwerk mogelijk.

Inzichten: Na conversie ontdekt het bedrijf dat wat leek op productieactiviteiten laat in de nacht (22:00 UTC) in werkelijkheid normale middagshifts (15:00 lokale tijd) waren in hun Mexicaanse locatie, waardoor onterechte compliance-waarschuwingen werden voorkomen.

Voorbeeld 2: Afspraakplanning Zorg

Scenario: Een ziekenhuisnetwerk bestrijkt drie tijdzones in de Verenigde Staten. Hun gecentraliseerde planningssysteem slaat alle afspraken op in UTC, maar lokaal personeel moet afspraken in hun respectieve lokale tijd kunnen zien voor operationele planning.

Instellingen:

  • Dataset Tijdzone: Eastern Standard Time (voor analyse aan de oostkust)
  • Geen aanvullende verrijkingsinstellingen vereist

Output: Patiëntenreis-tijdstempels geconverteerd van UTC naar EST/EDT:

  • Registratie: 2024-02-20 18:00:00 UTC → 2024-02-20 13:00:00 EST
  • Afspraak: 2024-02-20 19:30:00 UTC → 2024-02-20 14:30:00 EST
  • Ontslag: 2024-02-20 21:45:00 UTC → 2024-02-20 16:45:00 EST

Inzichten: De conversie toont aan dat de meeste afspraken plaatsvinden tijdens reguliere kantooruren (9:00-17:00 EST), en niet ’s avonds zoals UTC-tijdstempels suggereerden. Dit helpt bij een correcte personeelsplanning en resourceallocatie.

Voorbeeld 3: Financieel Handelsproces

Scenario: Een investeringsfirma verwerkt wereldwijd transacties, waarbij alle gegevens in UTC worden gelogd. Voor naleving van regelgeving en prestatieanalyse moeten ze tijdstempels omzetten naar New York tijd (EST/EDT) om aan te sluiten bij de markturen.

Instellingen:

  • Dataset Tijdzone: Eastern Standard Time
  • Geen aanvullende verrijkingsinstellingen vereist

Output: Handelstijdstempels aangepast aan NYSE handelsuren:

  • Handel Ingezet: 2024-03-10 13:30:00 UTC → 2024-03-10 09:30:00 EDT (markt open)
  • Handel Uitgevoerd: 2024-03-10 13:31:15 UTC → 2024-03-10 09:31:15 EDT
  • Afwikkeling Bevestigd: 2024-03-10 20:00:00 UTC → 2024-03-10 16:00:00 EDT (markt sluit)

Inzichten: Na tijdzonecorrectie kan het bedrijf nauwkeurig vaststellen welke transacties tijdens reguliere markturen zijn uitgevoerd versus buiten de markturen, wat correcte kostenberekening en rapportage ondersteunt.

Voorbeeld 4: E-commerce Orderafhandeling

Scenario: Een online retailer met fulfillment centers wereldwijd wil orderverwerkingstijden analyseren in Pacific Time, om aan te sluiten bij de kantooruren van het hoofdkantoor en de klantenservice.

Instellingen:

  • Dataset Tijdzone: Pacific Standard Time
  • Geen aanvullende verrijkingsinstellingen vereist

Output: Levenscyclus-tijdstempels van orders geconverteerd van UTC naar PST/PDT:

  • Order Geplaatst: 2024-08-15 05:00:00 UTC → 2024-08-14 22:00:00 PDT (voorgaande dag)
  • Betaling Verwerkt: 2024-08-15 05:15:00 UTC → 2024-08-14 22:15:00 PDT
  • Warehouse Gepickt: 2024-08-15 15:00:00 UTC → 2024-08-15 08:00:00 PDT
  • Verzonden: 2024-08-15 23:00:00 UTC → 2024-08-15 16:00:00 PDT

Inzichten: De tijdzonecorrectie toont dat orders die op 5 uur ’s ochtends UTC leken geplaatst te zijn, in werkelijkheid om 10 uur ’s avonds PST de vorige avond werden geplaatst, wat hoge volumes bij nachtelijke bestellingen verklaart en helpt bij het optimaliseren van personeelsplanning voor ochtendsorteringen.

Voorbeeld 5: IT Service Desk Operaties

Scenario: Een wereldwijd IT-dienstenbedrijf analyseert de oplostijden van incidenten over meerdere regio’s. Hun ITSM-systeem logt alle gebeurtenissen in UTC, maar SLA-compliance moet gemeten worden in lokale kantooruren.

Instellingen:

  • Dataset Tijdzone: GMT Standard Time (voor analyse van UK-operaties)
  • Geen aanvullende verrijkingsinstellingen vereist

Output: Incidenttijdstempels geconverteerd van UTC naar GMT/BST:

  • Incident Gemaakt: 2024-06-20 08:00:00 UTC → 2024-06-20 09:00:00 BST
  • Eerste Reactie: 2024-06-20 08:45:00 UTC → 2024-06-20 09:45:00 BST
  • Geëscaleerd: 2024-06-20 11:00:00 UTC → 2024-06-20 12:00:00 BST
  • Opgelost: 2024-06-20 15:30:00 UTC → 2024-06-20 16:30:00 BST

Inzichten: Het converteren naar lokale tijd toont dat de meeste incidenten plaatsvinden tijdens Britse kantooruren (9:00-17:00 BST), en niet vroeg in de ochtend zoals UTC-tijdstempels suggereerden, wat huidige dienstpatronen valideert en piekperiodes in supportvraag identificeert.

Output

De Correcte Tijdzone verrijking wijzigt alle bestaande datum/tijd-attributen in uw dataset zonder nieuwe kolommen aan te maken. De conversie betreft:

Case Attributen:

  • Alle datum/tijd-velden in de casetabel worden geconverteerd van UTC naar de opgegeven lokale tijdzone
  • Voorbeelden: Case Start Time, Case End Time, Order Date, Due Date, Completion Date
  • Alleen tijdstempels met tijdcomponenten worden geconverteerd (puur datums zonder tijden blijven ongewijzigd)

Gebeurtenis Attributen:

  • Alle datum/tijd-velden in de gebeurtenistabel worden geconverteerd naar lokale tijd
  • Het primaire Timestamp-veld dat gebruikt wordt voor process mining wordt aangepast
  • Eventuele extra tijdstempelvelden (Start Time, End Time, Schedule Time) worden ook geconverteerd

Data-integriteit:

  • De relatieve volgorde van gebeurtenissen blijft onveranderd
  • Berekeningen van duur tussen tijdstempels blijven correct
  • De verrijking zet een interne vlag (IsLocalTime) om onbedoelde dubbele conversie te voorkomen

Integratienotities:

  • Na conversie gebruiken alle tijdgebaseerde verrijkingen en calculators de lokale tijdstempels
  • Filters gebaseerd op tijdsintervallen zullen op lokale tijdwaarden werken
  • Exportfuncties leveren de geconverteerde lokale tijdstempels uit
  • De conversie houdt automatisch rekening met wijzigingen door zomertijd

Zie ook

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