Estimating the Impact of Incidents on Process Delay - ICPM 2019
0 likes
views
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.
Recommended
Estimating the Impact of Incidents on Process Delay - ICPM 2019
- ESTIMATING THE IMPACT OF INCIDENTS ON PROCESS DELAY Felix Mannhardt, Petter Arnesen, Andreas D. Landmark
- 2
- 3 Image sources: banenor.no
- 4 Case Activity Railway Traffic Control Logs
- 5 Railway Traffic Logs – Example Process Model
- What is process delay? 6 Definition A Expected/Scheduled vs. Actual Performance Definition B Normal performance vs. Actual performance
- What is known about incidents? 7 Image sources: banenor.no
- 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?
- The Problem – Linking Incidents to Delay 9
- • 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!
- Proposed Approach – Assumptions #1 11
- Proposed Approach – Assumptions #2 12 Resource required for trains to pass station Støren! Image sources: banenor.no
- 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 𝑇𝑖𝑛𝑐𝑖𝑑𝑒𝑛𝑡
- Proposed Approach – Impact Estimation #2 14 Step 2: Determine normal process performance
- Proposed Approach – Impact Estimation #3 15 Step 3: Classify activity instances into three classes
- 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.
- 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 𝑇𝑒𝑛𝑑
- Proposed Approach – Impact Estimation #5 18 Step 5: Accumulate delay 𝑇𝑠𝑡𝑎𝑟𝑡 𝑇𝑒𝑛𝑑Count fully Discount with prob.Discount with prob.
- 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
- Evaluation – Delay Dashboard 20
- 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`
- • 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 Contact felix.mannhardt@sintef.no @fmannhardt Thanks to BaneNOR which funded part of this research!
- Teknologi for et bedre samfunn
Editor's Notes
- Bildet illustrerer: · bredden i SINTEFs ekspertise, fra havrom til verdensrom. · hvilke områder og bransjer vi jobber innen for å realisere visjonen Teknologi for et bedre samfunn. Bildestilen er basert på stikkordene fremtidsrettet, teknologi og norsk natur (naturressurser). SINTEFs visuelle univers er utviklet for SINTEF av Headspin Productions AS.