Instant calculation, simulation or process mining?

Instant calculation turns the estimates of the people involved into lead time, cost and utilization, deterministically and with a traceable calculation path. Simulation sends individual cases through the process with limited staff and shows how queues build up. Process mining reconstructs the real process from event logs of IT systems and needs data that often does not exist yet. They answer different questions and complement each other.

Instant calculation: typical times, average visits

The app recalculates with every change. For each case type it solves how often each step is passed on average, then adds up the typical processing and waiting times, costs, handoffs and media breaks and compares the work per lane with its capacity (see branches and loops). The result is the same every time for the same input, and every number can be traced back to the steps.

In the worked example “Invoice check” this gives a lead time of 1,229.5 minutes, cost of €17.04 per case and 101% utilization in accounts payable, immediately and without any setup.

Typical value and mean of the range

The instant calculation uses the typical value of every step, the time it usually takes. That is the figure people name in the interview and recognize in the result; the shortest and longest times go into the lead time range.

When a range is not even around the typical value, because a few cases take much longer, its mean lies above it. Over many cases, this is the work that actually arises on average. For staffing, utilization and annual cost the mean is therefore the more cautious figure. Like the simulation, the app takes a triangle of shortest, typical and longest time. If the result differs noticeably, the figure “with mean of the ranges” appears as a second figure next to utilization, staffing and cost. The simulation with variation works with the same means, which is why it can find a different bottleneck than the instant calculation.

An example with an assumed range: in the worked example “Invoice check”, “Enter invoice” usually takes 6 minutes, at least 4 and at most 14. The mean is (4 + 6 + 14) ÷ 3 = 8 minutes. With the typical value accounts payable needs 266.7 hours a month, with the mean 300 hours. With 264 hours of capacity that is 101% instead of 114% utilization, a backlog of 10 against 120 invoices a month and 1.82 instead of 2.05 FTE. Cost per case rises from €17.04 to €18.88. The typical time describes the normal case, the mean the load across all cases.

Simulation: cases through limited capacity

A discrete-event simulation creates individual cases over a period, lets each one draw its case type and path, and has each lane work through its queue with the people available. Cases a lane has already worked on go before new ones, with the same assumption “work in progress first” as the backlog of the instant calculation. Waiting from overload is then a result, not an input.

The app contains such a simulation in its analysis area. You set the simulated period in working days, the number of replications and whether cases arrive evenly or randomly. Processing times vary within the range you entered (best, typical, worst), as a triangular distribution. You can leave out the waiting times from the input to see how much waiting comes from utilization alone. The results include mean lead time, queues and utilization per lane compared with the instant calculation, open cases at the end, and what-if variants such as one more person per lane, halved query rates or each measure on its own. A variant is only called “better” or “worse” if the difference is larger than the spread between the replications; otherwise it reads “not distinguishable with these runs”; if the difference is above the minimum size, more runs can decide. If a relief such as one more person certainly shows more open cases, it is called “measurably opposite”. That is not random fluctuation but a consequence of counting open cases rather than the work in them; Staffing and utilization explains how this comes about.

Process mining: the real process from system data

Process mining reads event logs, for example “order created”, “order released”, “invoice posted” with time stamps, and reconstructs which paths the cases really took and how long they waited. Nothing is estimated; everything that happened in the system is visible.

The precondition is data: the steps must happen in IT systems that write usable logs, with a common case identifier. Work on paper, in email or in conversations leaves no log. Before an ERP implementation, when exactly these parts are to be replaced, there is usually little to mine.

Comparison

When to use what

• Instant calculation: during and right after the mapping workshop, for comparing the current and the future process, for cost and staffing questions, and whenever someone needs to understand where a number comes from (see process cost calculation).
• Simulation: when a team is close to or above full utilization and the question is how long cases will wait, or whether one more person helps (see bottleneck analysis).
• Process mining: when the process runs largely in systems with good logs and you want to check the estimates against reality, or find variants nobody mentioned.

Estimates are not a weakness to hide

Estimated times limit the precision of every metric. Ranges make that visible: the app calculates lead time for best, typical and worst case. A rough figure that is available in a workshop is often enough to decide which measure to pursue. Where the decision depends on precision, measure that particular step, or check it later with system data once it exists.

Frequently asked questions

Keep learning