Process mining reveals how processes in organisations are actually performed and pinpoints deviations from the desired process execution. Process delay is one type of deviation that can be detected. Specific activities may take longer than expected or the waiting times between activities may deviate from service agreements. However, the quantification of processing or waiting times is often only the starting point in identifying the underlying root causes for process delay. One such root cause are adverse incidents in the environment of the process such as malfunctioning of supporting systems or unavailability of resources. Data about these external factors is often neither included in the event log nor recorded precisely enough to be directly linkable to a specific set of process instances. This paper presents a method for estimating process delay caused by incidents for which only the approximate occurrence time is known. We link incidents that are recorded in an incident log to process delay and calculate the effect of incidents on process delay using a Markov chain Monte Carlo sampling (MCMC) approach. Our proposed method was evaluated in a project conducted with the infrastructure manager of the Norwegian railway system. We applied it to a large event log of more than 120 million events capturing block-level movements of trains in the railway network and estimated the impact on process delay of about 50 000 infrastructure-related incidents. This showed that the method is useful for providing decision support and insights on the effects of maintenance. Since then the method has become part of the standard toolbox of the infrastructure manager.

1. ESTIMATING THE IMPACT
OF INCIDENTS ON
PROCESS DELAY
Felix Mannhardt, Petter Arnesen,
Andreas D. Landmark

2. 2

3. 3
Image sources: banenor.no

4. 4
Case Activity
Railway Traffic Control Logs

5. 5
Railway Traffic Logs – Example Process Model

6. What is process delay?
6
Definition A
Expected/Scheduled
vs.
Actual Performance
Definition B
Normal performance
vs.
Actual performance

7. What is known about incidents?
7
Image sources: banenor.no

8. What is known about incidents?
8
Incident Log
Issue registered
Mover/motor
turnout km 453
Work order created
Repair
Process
Work Order
DB
Manual
registration
Manual
registration
Registered?
Work started?
Contractor notified?
When was it fixed?

9. The Problem – Linking Incidents to Delay
9

10. • Internal performance factors
• Alignments to project performance information
• Identification of slow variants / combination of attributes
• Identification of slow resources
• Prediction of performance
• Remaining time to completion
• Some work considering inter-case parameters
• Visualisation of performance
• Dotted chart
• Others: Process Profiler, Performance Spectrum etc.
10
Existing work
None is addressing
the linking/estimation
challenge!

11. Proposed Approach – Assumptions #1
11

12. Proposed Approach – Assumptions #2
12
Resource required for trains
to pass station Støren!
Image sources: banenor.no

13. Proposed Approach – Impact Estimation #1
13 Step 1: Collect performance information from event log
Case 5262 took about 460s
for activity LMO-STØ (single track)
Approx. time for incident
on turnout XYZ
𝑇𝑖𝑛𝑐𝑖𝑑𝑒𝑛𝑡

14. Proposed Approach – Impact Estimation #2
14 Step 2: Determine normal process performance

15. Proposed Approach – Impact Estimation #3
15 Step 3: Classify activity instances into three classes

16. Proposed Approach – Impact Estimation #4
16 Step 4: Determine likely start/end of impact using MCMC
𝑇𝑠𝑡𝑎𝑟𝑡 ? 𝑇𝑒𝑛𝑑 ?
Metropolis-Hastings algorithms
20000 iterations
Priors for standard delay
e.g., 𝑝0 = (0.94, 0.055 0.005)
and incident-affected delay
e.g., 𝑝1 = (0.93, 0.06, 0.01)
hand tuned on small dataset.

17. Proposed Approach – Impact Estimation #4
17 Step 4: Determine likely start/end of impact using MCMC
𝑇𝑠𝑡𝑎𝑟𝑡 𝑇𝑒𝑛𝑑
Times at least 50% of the samples
between 𝑇𝑠𝑡𝑎𝑟𝑡 and 𝑇𝑒𝑛𝑑

18. Proposed Approach – Impact Estimation #5
18 Step 5: Accumulate delay
𝑇𝑠𝑡𝑎𝑟𝑡 𝑇𝑒𝑛𝑑Count fully Discount with prob.Discount with prob.

19. Evaluation – Case Study in Norway
19
TIOS
BaneData
Save result back
Traffic Control
System
Maintenance
Management
PRESENS-Algorithm
Data
Warehouse
Calculated the impact on delay for
each major incident since 2011
Work
orders
Driving
time
Delay
tagging
Validation

20. Evaluation – Delay Dashboard
20

21. Evaluation – Predictive Maintenance
21
• Prediction of "avoided" delay due
to smart maintenance
• Smart monitoring of turnouts
• Justification of investments
• Using the delay effect base on
historical data as proxy
• Not perfect, often rather small data basis
for prediction
• Better than management by `rule of
thumb`

22. • Explore application on non-infrastructure focussed processes
• Activity-incident relation is less obvious?
• Estimation of `normal` process performance challenging?
• Address the issue of multiple co-occurring incidents
• MCMC would have trouble with multi-modal distributions
• Address non-local knock-on effects on process delay
• Initial solution addresses the problem for single-track railway networks, but difficult to generalise!
• Investigate effects of queues etc. in non-physical processes
• Address the strong dependency on the chosen parameters in the prior
distribution  possible but high computational cost
22
Future work

23. 23
Contact
felix.mannhardt@sintef.no
@fmannhardt
Thanks to BaneNOR which funded part of this research!

24. Teknologi for et bedre samfunn