BPMN & Business Process Analysis

Process Metrics & Analysis

18 min Lesson 9 of 10

Process Metrics & Analysis

Modeling a business process with BPMN gives you a visual map of what happens and who does it. But a map alone does not tell you whether the journey is fast, cheap, or efficient. For that you need process metrics — quantitative measures that expose performance, cost, and the hidden delays that silently consume time and money. This lesson equips you with four of the most powerful analysis tools in a business analyst's kit: cycle time, wait time, cost per instance, and bottleneck identification.

Cycle Time

Cycle time is the total elapsed time from when a process instance starts to when it ends, measured from the customer's or requester's perspective. It is the most fundamental process metric because it is what the person waiting on the other side actually experiences.

For a logistics firm processing a delivery order, the cycle time begins when the customer places the order and ends when the parcel is marked delivered. Everything that happens in between — picking, packing, dispatch, transit, final delivery — is included, whether the order is actively being worked on or sitting idle in a queue.

Cycle Time = End Timestamp − Start Timestamp
           = Sum of all task durations + Sum of all wait times

Analysts break cycle time into two components: value-added time (activities that directly transform the work and the customer would pay for) and non-value-added time (everything else — waiting, rework, unnecessary handoffs). A well-run process minimises non-value-added time. In many real organisations, value-added time is only 10–30% of total cycle time; the rest is waiting.

Wait Time

Wait time (also called queue time or idle time) is the time a process instance spends doing nothing — waiting for a person to become available, a system to respond, an approval to arrive, or the next scheduled batch to run. Wait time is non-value-added by definition, and it is almost always the largest single component of cycle time.

Common sources of wait time in organisational processes include:

Approval queues — a manager reviews expense claims only on Friday afternoons, so every claim submitted Monday through Thursday waits up to four days.
Batch processing — a medical lab runs tests in batches of 20; samples collected in the afternoon wait overnight for the next batch run.
Resource contention — only one team member handles a specialised task; all other instances queue behind the active one.
System latency — an automated step triggers an external API and waits for a synchronous response that sometimes takes minutes.

The wait-time illusion: Process owners often believe their process is slow because the tasks take too long. In reality the tasks are usually fast; the process is slow because instances spend most of their time waiting between tasks. Always measure wait time explicitly — do not assume it is small.

Cost Per Instance

Cost per instance is the total cost consumed by one execution of the process from start to end. It combines labour cost, system cost, and overhead attributable to that execution.

Cost per Instance =
  Sum of (Task Duration × Loaded Labour Rate) for each human task
  + Sum of (System Usage Cost) for each automated task
  + Allocated overhead (facilities, licences, supervision)

For a bank processing a loan application, one instance might involve 45 minutes of a credit analyst's time (at a loaded rate of $80/hr = $60), 10 minutes of a manager review ($120/hr = $20), and $15 in system API fees, giving a cost per instance of $95 before overhead. Multiply by 3,000 applications per month and you have $285,000 monthly cost — a number that instantly justifies investment in automation or redesign.

Analysts use cost per instance to compare the As-Is process with the proposed To-Be process and to build the cost–benefit case for improvement. It is also the denominator for calculating cost of poor quality: if 8% of applications require rework, the rework cost is an additional overhead that must be allocated back to each instance.

Bottleneck Analysis

A bottleneck is any task, resource, or decision point where work accumulates because it is processed more slowly than it arrives. Bottlenecks determine the maximum throughput of the entire process — no matter how efficiently you optimise every other step, the bottleneck caps total output.

The classic indicator of a bottleneck is a growing queue upstream of a task. Secondary indicators include: one resource running at near-100% utilisation while others are idle; long wait times immediately before one task; and errors or rework concentrated at one activity because rushed workers make mistakes under pressure.

The five-step bottleneck analysis analysts follow:

Map the process — use the BPMN model from lessons 7 and 8 as the baseline.
Measure task duration and wait time per step — collect actual timestamps, not estimates.
Calculate utilisation per resource — utilisation = (time busy) / (available time). Any resource above 85% is a candidate bottleneck.
Identify where queues form — look for process instances waiting more than 20% of their cycle time at a single step.
Validate with data — confirm that improving the bottleneck would meaningfully reduce overall cycle time before investing in the fix.

Goldratt's Theory of Constraints reminder: Fixing a non-bottleneck step will not increase overall throughput. Focus your improvement effort on the single binding constraint first; only after it is resolved will the next bottleneck reveal itself. This is why bottleneck analysis must precede any process redesign.

Visualising Metrics on a BPMN Model

The diagram below shows a simplified online-store order fulfilment process annotated with cycle time, wait time, and a highlighted bottleneck. This is a standard technique analysts use when presenting the As-Is analysis to stakeholders — the BPMN model carries both the structural and quantitative story.

Figure 1 — Order fulfilment process annotated with task duration, wait time, and the bottleneck (Pick Items). Value-added time is only 46% of cycle time; the queue upstream of the bottleneck alone accounts for 43% of total elapsed time.

Building a Process Metrics Dashboard

Analysts consolidate measurements into a simple metrics dashboard that is shared with process owners and sponsors. The dashboard tracks key indicators over time and triggers investigation when values deviate from targets.

A practical dashboard for the order fulfilment example above would include:

Average cycle time — target: under 60 minutes; current: 81 minutes. Status: red.
Average wait time — target: under 15 minutes; current: 44 minutes. Status: red.
Value-added ratio — target: above 60%; current: 46%. Status: amber.
Cost per instance — target: under $4.50; current: $6.20 (pickers earning $20/hr × 18 min + QC staff × 6 min + overhead). Status: red.
Bottleneck utilisation (Pick Items) — current: 94%. Status: red (critical constraint).

Averages hide the real pain. Always report the 80th or 90th percentile cycle time alongside the average. If the average is 81 minutes but the P90 is 3.5 hours, a large minority of customers are experiencing something far worse — and that is where complaints and churn originate. The average can look acceptable while the tail experience is a serious problem.

Linking Metrics Back to the BPMN Model

The power of combining BPMN with metrics is that you can annotate every task and flow with real measurements, giving stakeholders both the what (the process structure) and the how bad (the quantitative evidence) in a single visual artefact. This annotated As-Is model is the primary input to Lesson 8's To-Be redesign: every improvement decision must trace back to a metric it is expected to improve.

The diagram below shows a metrics heat map — a technique where task boxes are shaded by their contribution to excess cycle time, making the priority order for improvement immediately obvious to non-technical stakeholders.

Figure 2 — Process metrics heat map. Red (critical) tasks have wait ratios above 60% and are redesigned first; amber (high) tasks are addressed second. The heat map makes the improvement priority order self-evident to stakeholders.

From Metrics to Improvement Decisions

Once you have the full picture — cycle time decomposed into tasks and waits, cost per instance calculated, and the bottleneck identified — you can generate targeted improvement options and estimate their impact before committing to implementation:

Add capacity to the bottleneck — hire a second picker or automate part of the picking step. Projected impact: reduce Pick Items wait from 35 minutes to 8 minutes, cutting total cycle time by 33%.
Reduce batch sizes — if Quality Check runs every 10 orders, switch to continuous processing. Eliminates 12-minute average wait between tasks 3 and 4.
Parallel execution — run Validate Order and system inventory check simultaneously rather than sequentially. Zero wait time benefit but cuts task time.
Eliminate the step entirely — if data shows the Quality Check catches fewer than 0.3% of defects, the wait cost may exceed the defect prevention value.

Each option should be documented as a process improvement hypothesis: a before-metric, the proposed change, the expected after-metric, and how success will be measured. This connects directly to the As-Is/To-Be BPMN models you produce in lessons 7 and 8, and forms the quantitative backbone of the feasibility analysis from Tutorial 6.

Summary

Cycle time is the total elapsed time per process instance, including both active work and waiting. It is the customer's lived experience of the process.
Wait time is the non-value-added component of cycle time and is typically the largest single driver of slow processes. Measure it explicitly.
Cost per instance combines labour, system, and overhead costs for one execution. It builds the business case for improvement.
Bottleneck analysis identifies the step where work accumulates, caps throughput, and must be addressed before any other improvement yields meaningful benefit.
Annotate your BPMN As-Is model with real metrics to create an evidence-based case for redesign. Each improvement option should predict its impact on a specific metric.