BI Architecture
Part of BI for operations management
Analysing service delays by process stage
Rebuild case timelines, distinguish recorded work from elapsed gaps, compare process routes and investigate delays without assuming their cause.
To locate where service cases spend time, reconstruct each case’s path and measure intervals between defined events. Separate recorded active work from waiting only when the data supports that split. A long interval points to a stage or handoff to investigate; it does not establish the cause.
Define the case and stage boundaries
Choose one service outcome and a stable case ID. Capture every available activity name, timestamp, stage, responsible team and final state. Decide whether cases can skip a stage, return to one, or run activities in parallel.
Define each stage’s start and end events before calculating its duration. If “review started” is recorded only when someone opens a file, time from intake to that event is a pre-review interval, not active review time. A record with only status-change timestamps may show elapsed time between changes but not how long staff worked.
Build a case timeline
Order each case’s events by timestamp, using a documented rule for ties and corrections. Calculate intervals between events and assign each to a defined stage or handoff. Keep cases with missing events visible as incomplete; silently dropping them can make remaining paths look faster.
An activity with reliable start and end timestamps can have a recorded active duration. The gap from its end to the next activity’s start can be measured separately. With only one timestamp per event, an interval combines unobserved work and waiting—label it as elapsed time between recorded events.
In Power Automate Process Mining, mean waiting time is described as the average time spent between activities. Mean active time is available when two timestamps are recorded and imported.
| View | What to inspect | Why it matters |
|---|---|---|
| Stage entries and exits | Distinct cases entering and leaving | A stage with a long queue may also receive more work. |
| Completed stage intervals | Median and spread | An average can hide a long tail. |
| Handoffs | Elapsed time between recorded stage events | The gap needs an operational explanation. |
| Rework | Cases returning to an earlier stage | Repeated work can lengthen the journey. |
| Open cases | Age at the current stage and reporting cutoff | Completed cases exclude unfinished waits. |
Compare like paths
Split cases by route, priority and type where these differences matter. A complex request needing another approval is not directly comparable with a straightforward one. State whether durations use elapsed hours or business hours, and whether weekends, Australian public holidays and customer-held periods count. Holiday rules may differ by state or territory.
Show completed-case durations separately from the age of work still open. A completed-only view can miss the worst ongoing delays. If activities overlap, adding their durations may exceed the case’s end-to-end elapsed time.
Investigate the apparent bottleneck
Inspect case histories from a stage with a substantial queue or long tail. Check for missing documents, dependencies, resource limits, batch schedules, rework and recording problems. Compare the records with staff who perform the work. A process map shows where recorded time accumulates; it does not explain why.
For a proposed change, define the affected case population and expected effect, then compare results using the same stage definitions. Record routing or timestamp changes that would make before-and-after figures unlike.
