How do I find the weak spots in a process?

Weak spots show up as patterns in a mapped process: cases that mostly wait, work that bounces between two teams, several approvals in a row, frequent queries, media breaks, rare exceptions that eat much of the time, and teams loaded close to their limit. Look for these patterns in the metrics, record each as a problem at the step where it occurs, then ask for the cause and rank by effect.

Start from the numbers, not from opinions

In a workshop everybody brings a favorite complaint. They are worth hearing, but they are not a ranking. Once the process is mapped with volumes and times (see mapping the current process), the metrics show where time and money actually go. The app runs a set of checks on every change and lists hints next to errors and warnings; each one jumps to the element concerned.

The seven patterns below are the ones those hints cover. None of them is automatically a problem. They are questions to ask the people who do the work.

Seven patterns and how to spot them

1. Waiting dominates. If a case spends more than 90% of its lead time waiting, the app gives a hint. In the worked example “Invoice check” the processing share is only 1.4%: 17.5 minutes of work in 1,229.5 minutes of lead time. Faster typing would barely change the lead time; shorter queues would. More in lead time calculation.
2. Ping-pong between two lanes. When a case switches between the same two lanes three times or more in a row along its most likely path, the app reports it. Typical cause: unclear responsibility or a missing piece of information that has to be fetched step by step.
3. Several approvals in a row. Two or more approvals following each other (tasks whose names begin with approve, approval or review, or decisions in another lane than the step before) are flagged. Often each approver checks the same thing.
4. High query rate. A task where more than 20% of the cases need a query gets a hint. Queries add effort and delay to every affected case (see branches and loops).
5. Media breaks. Each transition between two tasks where data changes its carrier gets a hint, also within one lane; the metric shows media breaks in total and how many of them occur at handoffs. See media breaks and forms.
6. Heavy exceptions. If a case type with less than 20% of the cases takes more than 40% of the processing time, the app points it out. That is the moment to look at case types and exceptions separately.
7. Teams near their limit. A lane loaded between 85% and 100% gets a hint, above 100% a warning with the backlog per period. See bottleneck analysis.

Example: customer complaints

The template “Customer complaint handling” makes several patterns visible. Customer service records a complaint in the CRM system and has to query in 25% of the cases, because photos or the delivery note number are missing. Quality management assesses the complaint; 40% of the goods are returned and inspected in the test laboratory, which means a long wait for the return shipment. For justified complaints the credit note and the root-cause analysis run in parallel before the customer is informed.

The query rate of 25% is above the 20% threshold and is recorded as a problem at “Record complaint”, with a measure attached: a complaint form with mandatory fields and photo upload in the customer portal. That is the pattern of a good entry: the problem sits at the step where it occurs, and the measure names a cause, not a symptom.

Record problems where they happen

In the app a problem is a marker attached to a step (or to the whole process). It has a short text and a category: waiting, query, media break, double entry, approval, missing information, error or other. Ideas and measures are markers too; a measure can name the problem it solves.

Attaching the problem to a step keeps the discussion concrete. “Things take too long” becomes “At ‘Check invoice’ one invoice in five is incomplete, usually the order number is missing.” The checks also remind you if a problem still has no measure.

Not every observation is confirmed yet. If it is unclear whether something is true or how often it happens (“Is every other invoice really sent back with a query?”), record it as a “To clarify” entry on the step rather than as a problem. Once you have the answer, tick “Clarified”, enter the outcome and only then add the problem if it holds. That way the ranking contains only weaknesses that are backed by facts.

From symptom to cause

Most patterns are symptoms. A long waiting time before an approval is rarely caused by the approver being slow; often the approver is away, approves in batches once a week, or receives cases that do not need an approval at all. Ask “why” at the step, with the person who does it, until you reach something that can be changed.

Useful questions: What is missing when the case arrives? Who could decide this instead? What happens if this step is skipped? Is this check repeated later? Which cases cause most of the work?

Rank by effect

A weak spot that affects every case and adds days of waiting beats one that costs two minutes in a rare case. Rank by the effect on the metric that matters for your occasion: lead time for customer-facing processes, cost and staffing for back-office work, completion rate where cases get lost.

The app makes the ranking quantitative: each measure can carry its changes to the model, and its effect is the difference in the metrics with and without it. How to set that up and how payback is calculated is explained in future process and measures.

Frequently asked questions

Keep learning