Process improvement

You make a process measurably better and keep it that way. That means starting from a number (how long, how many errors, how much it costs), finding where the time and errors actually come from, changing the fewest things that move the number most, proving it with data from a pilot, and leaving behind an owner and a check so it does not drift back. Automation comes last, after the process has been simplified.

When to use

• "Invoicing takes forever every month."
• "Too many orders go out wrong."
• "We're drowning in approvals."
• "Can we automate onboarding?"
• "Find us some efficiency savings in operations."

What you need

• A current map of the process with step times and quality measures (see process-mapping-and-sops; build one first if none exists).
• Data: volumes, timestamps (received, started, finished per item), error or rework counts, complaints, cost of the people involved. Pull from the systems the team uses (connected apps on the Connections page, or your own browser signed in by the owner, or exports).
• The people who do the work and the person who owns the outcome (ask_teammate, brief_team).
• The owner's goal and constraints: target, budget, what must not change (compliance steps, customer promises).

Method

Follow Define, Measure, Analyse, Improve, Control.

1. Define. Write the problem as a measurable gap: "Order-to-invoice takes a median of 6 working days; target 2. 1 in 4 invoices needs correcting." Agree scope (start and end points), the customer of the process, and the target with the owner.
2. Measure the baseline for at least 4 weeks or 30 items, with execute_code: lead time (median and 85th percentile, not just the average), throughput per week, work in progress, first-pass yield (share done right first time), rework rate, touch time, cost per item. Check Little's Law as a sanity test: average work in progress = throughput x average lead time.
3. Analyse where time goes. For each step: process time vs waiting time. Process cycle efficiency = value-adding time / total lead time; in office processes this is often in single-digit percentages, so the opportunity is usually in the waits, not in working faster.
4. Find the bottleneck: the step with the least capacity relative to demand, where work piles up. Improving anything else does not raise throughput. Apply the five focusing steps: identify it, get the most out of it (no idle time, no defects reaching it), make everything else serve its pace, add capacity only if still needed, then look for the next constraint.
5. Find the waste with the eight wastes (DOWNTIME): Defects (rework), Overproduction (work done before it is needed), Waiting, Non-utilised talent, Transport (handoffs and moving information between systems), Inventory (queues, backlogs), Motion (searching, switching screens), Extra processing (approvals and checks that add no value). Tag each step. Details and examples in references/improvement-toolkit.md.
6. Find the cause of errors with a Pareto of error types (often a few types cause most of the rework), then root causes for the top one or two (see operational-root-cause-analysis).
7. Design the future state in this order: Eliminate steps and approvals that add no value; Combine steps to cut handoffs; Rearrange to remove waits (do in parallel, batch less); Simplify what remains (templates, defaults, checklists, mistake-proofing). Automate only what is then stable and frequent. For each change: expected effect on the baseline numbers.
8. Prioritise on impact versus effort, and present the shortlist to the owner with a simple business case: hours saved per month x loaded hourly cost, error cost avoided, one-off cost, payback months. Changes that touch customers, compliance, finance controls or people's roles need the owner's approval before a pilot.
9. Pilot on a slice (one team, one product line, two weeks). Measure the same numbers the same way. Compare with the baseline using a run chart; a change is real when it is sustained, not one good week (see operations-metrics-dashboard for signal rules).
10. Control. Update the SOP, train, set an owner and a control plan (metric, target, check frequency, who acts when it slips), and schedule a check with cronjob at 30 and 90 days. Report the result to the owner in the original units.

Worked example: order-to-invoice

Define: median order-to-invoice 6 working days, target 2; one invoice in four needs correcting. Measure (4 weeks, 212 orders): median 6.1 days, 85th percentile 11 days, throughput 53 a week, work in progress 46. Little's Law check: 53 / 5 working days x 6.1 days = about 65 expected against 46 actual, so the period was not steady (a backlog cleared in week 1). Re-measured on weeks 2 to 4 before going further. Analyse: 35 minutes of hands-on work in a 74-hour lead time (0.8% process cycle efficiency). The invoicing step waits up to 48 hours for the dispatch note. Error Pareto: missing PO number 62% of corrections, wrong price 24%. Bottleneck: finance invoicing, done in one batch on Fridays. Future state, in ECRS order:

• PO number mandatory at order entry (removes the 62% of corrections at source).
• Invoice from the dispatch scan the same day (removes the 48-hour wait).
• Price list synced from the system of record (removes the 24%).
• Automate the dispatch-to-invoice trigger only after two weeks of the manual daily batch running clean. Business case:
• Time: 400 invoices a month x 6 minutes saved = 40 hours at 32 loaded = 1,280 a month.
• Errors: from 100 to 40 a month at 15 each = 900 a month.
• One-off cost 3,500; added software 180 a month; payback 3,500 / (2,180 minus 180) = 1.75 months. Pilot: product line A for two weeks. Median fell to 1.8 days and corrections to 7%; the run chart shows the shift held across both weeks. Recommendation: adopt, with a control plan owned by the finance lead and a weekly check.

Change the fewest things, in this order (ECRS)

1. Eliminate: steps, approvals and reports nobody would miss.
2. Combine: steps one person can do in one sitting.
3. Rearrange: in parallel, in smaller batches, with checks earlier.
4. Simplify: templates, defaults, mandatory fields, mistake-proofing.
5. Then automate what is stable, frequent and rule-based.

When the gap is quality rather than speed

Start from the error Pareto, not the map. Fix the top one or two error types at their source (usually a step or two upstream of where they are found), then re-measure first-pass yield over at least 30 items before touching anything else. One cause at a time, or you will not know what worked.

Output

• Improvement proposal (2 pages): problem and baseline, analysis (bottleneck, wastes, error Pareto), future state map, changes with expected effect, business case, risks, pilot plan, decision needed.
• After the pilot: before-and-after table and run chart, recommendation to adopt, adjust or drop.
• Updated SOP and control plan.
• A show_card: baseline vs target vs pilot result for the main measures, and the payback.

Checks before you finish

• Baseline is measured from data, with the period and sample size stated.
• Median and 85th percentile reported, not only the average.
• The bottleneck is identified from queue and capacity data, not opinion.
• Every proposed change names which waste or cause it removes and its expected effect.
• The business case uses loaded costs and the owner's numbers, with assumptions listed.
• Pilot results compare like with like (same measures, same definitions).
• A control plan has an owner and a review date.

Pitfalls

• Automating a broken process. You get the same mess, faster. Simplify first.
• Speeding up the wrong step. Only the bottleneck sets throughput.
• Averages that hide the tail. Customers feel the slow 15%.
• Declaring victory on one good week. Look for a sustained shift.
• Removing a control that exists for a reason (fraud, legal, safety) because it looks like waste. Find out why it is there; ask the owner.
• Solutions looking for problems. Start from the gap, not the tool.
• No owner afterwards. Improvements decay without a control plan.

See also

• process-mapping-and-sops, operations-metrics-dashboard, operational-root-cause-analysis.