Evenementen Voor of Na Activiteit

Overzicht

De filter Evenementen Voor of Na Activiteit selecteert of verwijdert evenementen op basis van hun positie ten opzichte van specifieke activiteiten binnen elk case. Deze krachtige filter op evenementniveau stelt je in staat om je te concentreren op delen van je proces door alleen evenementen te behouden die plaatsvinden vóór, na, of tussen opgegeven activiteiten. Je kunt processegmenten analyseren, patronen in specifieke workflowfasen identificeren, of irrelevante evenementen verwijderen die buiten je interessegebied vallen.

Veelvoorkomende Toepassingen

  • Analyseren van evenementen die plaatsvinden vóór een kritieke mijlpaal of beslispunt
  • Focussen op activiteiten die plaatsvinden na een specifieke procesfase
  • Extractie van processegmenten tussen twee belangrijke activiteiten
  • Verwijderen van voorlopige evenementen om te focussen op kernverwerkingsactiviteiten
  • Identificeren van patronen in workflows na goedkeuring of afwijzing
  • Bestuderen van procesgedrag tussen start- en eindmijlpalen

Instellingen

Activity Name: De primaire activiteit die als referentiepunt of grens dient.

Activity Name 2: (Alleen voor Between-operaties) De tweede activiteit die de eindgrens definieert.

Before/After Selection: Kies de filtermodus die bepaalt welke evenementen behouden of verwijderd worden.

Modus Beschrijving Voorbeeldgebruik
Before Evenementen vóór de eerste keer dat de Activiteit voorkomt Analyseren van activiteiten voorafgaand aan de eerste goedkeuring
Before and Including Evenementen vóór en inclusief de eerste keer dat de Activiteit voorkomt Inclusief goedkeuring in de pre-goedkeuringsanalyse
After Evenementen ná de laatste keer dat de Activiteit voorkomt Bestuderen van opvolgactiviteiten na voltooiing
After and Including Evenementen ná en inclusief de laatste keer dat de Activiteit voorkomt Inclusief voltooiing in de post-voltooiingsanalyse
Between Evenementen tussen de eerste keren van twee activiteiten Analyseren van verwerking tussen indiening en goedkeuring
Between and Including Evenementen tussen en inclusief beide activiteiten Inclusief grenzen in segmentanalyse

Remove Events: Kies of de overeenkomende evenementen behouden of verwijderd moeten worden.

  • Keep (false): Retourneert alleen evenementen die aan de criteria voldoen
  • Remove (true): Verwijdert evenementen die aan de criteria voldoen en behoudt alle overige

Voorbeelden

Voorbeeld 1: Analyseren van Pre-Goedgekeurde Activiteiten

Scenario: Je wilt alle activiteiten analyseren die plaatsvinden vóór de eerste "Manager Approval" in je onkostennota-proces om te begrijpen welke voorbereidingen er plaatsvinden voordat claims worden goedgekeurd.

Instellingen:

  • Activity Name: "Manager Approval"
  • Before/After Selection: Before (niet inclusief)
  • Remove Events: Keep (false)

Resultaat:

Voor elke case worden alleen evenementen behouden die vóór de eerste "Manager Approval" plaatsvinden. Case #EXP-1234 kan "Submit Claim," "Attach Receipts," "Department Review" tonen, maar niet "Manager Approval" of iets daarna. Dit stelt je in staat om de indienings- en voorbereidingsfase afzonderlijk te analyseren.

Inzichten: Door pre-goedgekeurde activiteiten te isoleren, kun je de voorbereidingstijd meten, knelpunten in documentverzameling identificeren en begrijpen welke activiteiten consequent voorafgaan aan goedkeuring. Dit helpt bij het optimaliseren van de indieningsfase van je workflow.

Voorbeeld 2: Bestuderen van Post-Afwijkingsactiviteiten

Scenario: Wanneer leningaanvragen worden afgewezen, wil je analyseren wat er daarna gebeurt – of klanten opnieuw aanvragen, bezwaar maken, of het proces verlaten. Je wilt je alleen richten op evenementen na de activiteit "Application Rejected".

Instellingen:

  • Activity Name: "Application Rejected"
  • Before/After Selection: After (niet inclusief)
  • Remove Events: Keep (false)

Resultaat:

Voor elke afgewezen case worden alleen evenementen behouden die plaatsvinden na de laatste "Application Rejected". Case #LOAN-5678 kan "Appeal Requested," "Additional Documents," "Manager Review" tonen, maar niet het afwijzingsevenement zelf of iets daarvoor. Dit isoleert de post-afwijzing workflow.

Inzichten: Dit onthult klantgedrag na afwijzing en identificeert kansen voor procesverbetering. Je kunt meten hoeveel klanten opnieuw aanvragen, hoe lang ze wachten voordat ze bezwaar maken, en of bepaalde afwijzingstypen leiden tot meer bezwaren.

Voorbeeld 3: Analyseren van Verwerking Tussen Activiteiten

Scenario: Je verzekeringsclaimproces heeft een duidelijk verwerkingsvenster tussen "Initial Assessment" en "Final Decision". Je wilt alleen de activiteiten analyseren die plaatsvinden tijdens deze kernverwerkingsfase, exclusief voorlopige en opvolgingsactiviteiten.

Instellingen:

  • Activity Name: "Initial Assessment"
  • Activity Name 2: "Final Decision"
  • Before/After Selection: Between (niet inclusief)
  • Remove Events: Keep (false)

Resultaat:

Voor elke case worden alleen evenementen tussen de eerste "Initial Assessment" en de eerste "Final Decision" behouden, exclusief beide grensactiviteiten. Case #CLM-9876 kan "Document Verification," "Expert Consultation," "Additional Information Request" tonen, maar niet de beoordeling of beslissing zelf.

Inzichten: Dit isoleert je kernactiviteiten voor claimsverwerking, waardoor je verwerkings efficiëntie kunt meten, veelvoorkomende onderzoekstappen kunt identificeren, en knelpunten in de evaluatiefase kunt analyseren zonder ruis van voorlopige of post-beslissingsactiviteiten.

Voorbeeld 4: Verwijderen van Post-Voltooiingsactiviteiten

Scenario: Je orderafhandelingsanalyse moet zich alleen richten op activiteiten tot en met levering. Evenementen na "Delivered" zoals "Customer Survey" en "Feedback Collected" zijn belangrijk maar moeten uitgesloten worden van analyse van de doorlooptijd van de fulfilment.

Instellingen:

  • Activity Name: "Delivered"
  • Before/After Selection: After and Including (Delivered)
  • Remove Events: Remove (true)

Resultaat:

Voor elke case worden de "Delivered"-gebeurtenis en alles daarna verwijderd, alleen de fulfilment-activiteiten worden behouden. Case #ORD-4567 behoudt "Order Received," "Payment Processed," "Shipped" maar verwijdert "Delivered," "Survey Sent," en "Feedback Received."

Inzichten: Door post-leveringsactiviteiten te verwijderen, weerspiegelen je doorlooptijd-berekeningen de daadwerkelijke fulfilment-duur zonder dat klantenfeedback wordt meegeteld. Dit levert nauwkeurige operationele metrieken op terwijl je feedbackactiviteiten apart kunt analyseren met een andere filterconfiguratie.

Voorbeeld 5: Volledige Workflowsegmentanalyse

Scenario: Je wilt de complete goedkeuringsworkflow analyseren inclusief zowel het beginpunt "Approval Request Submitted" als het eindpunt "Final Approval Decision", en alles buiten dit segment uitsluiten.

Instellingen:

  • Activity Name: "Approval Request Submitted"
  • Activity Name 2: "Final Approval Decision"
  • Before/After Selection: Between and Including
  • Remove Events: Keep (false)

Resultaat:

Voor elke case worden evenementen vanaf de eerste "Approval Request Submitted" tot en met de eerste "Final Approval Decision" behouden, inclusief beide grensactiviteiten. Dit geeft je het volledige goedkeuringssegment met duidelijke start- en eindpunten.

Inzichten: Het meenemen van beide grenzen geeft je volledige goedkeuringsworkflow-statistieken inclusief de activiteiten die het begin en het einde van het goedkeuringsproces markeren. Dit is ideaal voor het meten van de totale goedkeuringstijd en het analyseren van de complete reeks aan goedkeuringsgerelateerde activiteiten.

Output

Deze filter werkt op het niveau van evenementen en kan je proceslog aanzienlijk herstructureren:

  • Before/After-modi: Vind de eerste (Before) of laatste (After) keer dat de opgegeven activiteit voorkomt
  • Between-modi: Vind evenementen tussen de eerste voorkomens van Activity Name en Activity Name 2
  • Remove-modus: Keert de selectie om (verwijdert overeenkomende evenementen in plaats van ze te behouden)
  • Cases blijven in de dataset, ook als evenementen worden verwijderd
  • Lege cases kunnen ontstaan als alle evenementen worden gefilterd
  • Evenementvolgorde en attributen blijven behouden voor behouden evenementen

Gebruik deze filter om je analyse te richten op specifieke processegmenten, gedragspatronen vóór of na belangrijke mijlpalen te begrijpen, of irrelevante evenementen buiten je interessegebied te verwijderen.


Deze documentatie maakt deel uit van het mindzieStudio process mining platform.