Process Metrics And KPIs

Why this matters

Great BPMN diagrams show how work flows; metrics and KPIs tell you if the flow performs well. As a Business Analyst, you will be asked to: define success criteria for a process change, size the improvement opportunity, track whether changes work, and flag risks early. Clear metrics convert a process map into measurable outcomes leadership can act on.

• Prioritize bottlenecks with data instead of opinion.
• Set targets that align with customer promises (SLAs).
• Prove impact after a redesign or automation.

Concept explained simply

Metrics quantify how a process behaves. KPIs are the few metrics that matter most to goals.

Mental model

Think of your BPMN process like a pipeline with checkpoints. Inputs enter, steps add value, queues add delays, and outputs leave. A KPI tree connects a top goal (e.g., faster cycle time) to drivers (wait time, rework, WIP) and then to actions (staffing, automation, policy).

Core metrics you will use

• Lead time: From request start to final completion.
• Cycle time: Time to complete a case once active in the process (often excludes backlog wait before entering).
• Touch time: Actual hands-on work time.
• Wait/Queue time: Non-working time between steps.
• Throughput: Completed cases per period.
• WIP (Work in Progress): Cases currently in the process.
• First Pass Yield (FPY): % of cases that finish without rework.
• Rework rate: % of cases looping back or requiring fixes.
• SLA attainment: % of cases meeting agreed time/quality.
• Error/defect rate: % with a defect found.
• Cost per case: Effort or money per completed case. Varies by country/company; treat as rough ranges.

From BPMN to metrics: a simple workflow

Worked examples

Example 1 — Invoice approval (straight-through)

Process: Receive invoice → Validate → Approve → Pay. Baseline from logs (business days):

• Validate: touch 10 min, wait 4 h
• Approve: touch 5 min, wait 8 h
• Pay: touch 5 min, wait 2 h
• Rework: 5% of invoices return from Approve→Validate

Calculations:

• Cycle time ≈ (10+5+5) min touch + (4+8+2) h wait ≈ 20 min touch + 14 h wait
• FPY = 95%; Rework rate = 5%
• Biggest delay: Approve wait (8 h) → candidate bottleneck

Example 2 — Support triage (SLA focus)

Process: New ticket → Triage → Resolve or Escalate. SLA: 90% resolved within 24 h.

• Throughput: 400/day; Completed within 24 h: 340 → SLA 85% (miss)
• p90 wait before Triage: 6 h; p90 touch for Resolve: 30 min

Insight: Queue before Triage dominates delay more than handling time. Increase triage coverage or institute follow-the-sun shifts.

Example 3 — Loan application (rework loop)

Process: Apply → Verify docs → Underwrite → Decision. 20% loop back from Underwrite → Verify.

• FPY = 80%
• Average extra wait per loop: 2 days → Major lead time driver

Quality gates and setting targets

• Use percentiles (p80/p90), not only averages, to reflect real customer experience.
• Align SLA with customer promise and internal capacity.
• Set guardrails: e.g., reduce lead time by 30% without lowering FPY below 95%.

Data collection checklist

• Unique case ID exists across systems.
• Timestamps captured for step start and end.
• Queue vs touch time distinguishable.
• Events for rework loops identifiable (return paths).
• Calendar vs business time clarified and consistent.
• Sample size covers typical variability (e.g., 4–6 weeks).

Exercises

Complete the exercises below, then open the solution inside each card to compare. Use the checklist before checking solutions.

Exercise 1 — Derive KPIs from a BPMN

Use the provided scenario in the exercise card below (ex1). Compute lead time components, FPY, and identify the bottleneck.

Exercise 2 — Build a KPI tree

Use the hiring process scenario in the exercise card below (ex2). Produce a KPI tree and 3 measurable targets.

Pre-submission checklist

• Definitions clear (lead vs cycle vs touch vs wait).
• Percentiles used for time targets (not only averages).
• No more than 5 KPIs; rest are diagnostics.
• Bottlenecks supported by data (wait or utilization), not hunch.

Common mistakes and self-check

• Only using averages: Add p90 or p95 for time metrics.
• Counting rework as throughput: Separate rework loops; use FPY and Rework rate.
• Unclear timers: Define exact event that starts/ends measurement.
• Goodhart’s law: If you target approvals/day, quality may drop. Pair speed KPIs with quality KPIs.
• Mixing calendar and business time: Be explicit and consistent.
• Too many KPIs: Keep 3–5 true KPIs, others are diagnostics.

Practical projects

• Project 1: Take a simple BPMN (3–5 tasks). Baseline lead time, FPY, and p90 wait. Propose one change and simulate expected impact.
• Project 2: Create a one-page KPI dashboard mockup: 3 KPIs + 3 diagnostics + trend sparkline mock data.
• Project 3: Run a bottleneck workshop: show data, collect root causes, draft actions with owners and dates.

Learning path

1. Clarify process outcome and customer promise.
2. Map the process in BPMN (happy path + rework loops).
3. Define metric timers and data sources.
4. Baseline and segment (by product, priority, channel).
5. Select 3–5 KPIs and set targets (percentiles).
6. Implement collection and simple dashboards.
7. Review weekly, iterate, and lock in improvements.

Who this is for

• New and practicing Business Analysts working with BPMN.
• Process owners and ops leads aiming to improve throughput and quality.

Prerequisites

• Basic BPMN familiarity (events, tasks, gateways, swimlanes).
• Comfort with basic math and percentages.

Next steps

• Apply metrics to a real process you know.
• Share a one-pager with KPIs, baselines, and first actions.
• Schedule a 2-week follow-up to review early results.

Mini challenge

Pick a process you mapped recently. In 10 minutes, write a KPI tree: top goal, 3 drivers, and one action per driver. Set one measurable target using a percentile.

Quick Test

Anyone can take the test. Logged-in users will see saved progress automatically.