Process Map Template and Rework Register

Pick one process and name two observable events: the one that starts it and the one that ends it. "A purchase order arrives" is a start point you can find in a record. "Order intake" is a phase, and a map without hard edges keeps growing until it covers half the company.

Write down what is out of scope, such as rush jobs, so nobody argues about it later. Then fix the period you will measure, because every rate on the map needs a count of jobs behind it. If the team disagrees about what goes in and out, settle it first with a one-page SIPOC diagram.

Watch the work instead of mapping it from a desk. James Womack, founder of the Lean Enterprise Institute, suggests following one process from start to finish across departments¹, with everyone who touches it walking together. Ask each person what they do, what they wait for and where the work goes next.

The flowchart method from the Agency for Healthcare Research and Quality (AHRQ) lists every person, department and group involved² before anyone names a step. Give each team or role its own lane, and give the customer one too. Customer waits, like approving a proof, can be the longest on the map, and they vanish without a lane.

Start a new step whenever work changes hands. When one action involves two lanes, AHRQ writes it from both sides: "Ted telephones Mary" in one lane, "Mary receives a phone call" in the other.

Decide how much detail you need. The Institute for Healthcare Improvement calls a high-level flowchart of 6 to 12 steps³ a panoramic view. Detailed ones run to dozens of steps, and they make rework loops easy to spot.

Metrics-based process mapping, a method from the consultants Karen Martin and Mike Osterling, adds time and quality metrics to the swim lane map⁴. Give every step two numbers in separate columns: the touch time, when someone is working on it, and the wait since the previous step finished.

Never add them together. A step with 20 minutes of work behind a 2-day queue is not a 2-day step, and each number needs a different fix. Take the waits from records rather than memory: ticket histories, order dates, email timestamps. The IEEE Task Force on Process Mining notes that when events carry timestamps, you can find the bottlenecks⁵.

No timestamps? Count the queue: if 40 invoices are waiting and the team clears 10 a day, a new one waits about 4 days. Write 0 where a step runs straight into the next, and mark untimed waits as unmeasured, so a blank never passes for a zero.

Then total both columns. The Lean Enterprise Institute defines lead time as the time it takes one piece to move all the way through a process⁶. Set the touch total beside it: when work is touched for 14 hours of an 8-day lead time, faster hands won't fix the calendar.

A walkthrough gives you the happy path. People describe their work as it is meant to run, so the jobs that come back rarely get mentioned. The same IEEE task force describes process mining as reading existing event logs to see real processes, not assumed ones⁵. Look for traces of work going backwards:

• Status histories where a job visits the same status twice
• File version counts and revision numbers
• Reject logs and reject-reason fields
• Email threads where work went back for correction
• Quality, reprint and credit-note logs

Count each loop against a stated number of jobs. "88 of 260 jobs went back" survives a challenge, while "about a third" does not. Then note how many days each loop adds. A loop that hits 4% of jobs and adds 3 days costs more per job than one that hits 18% and adds half a day: 0.12 days against 0.09.

Loops cause loops. A late rejection is often the visible end of something missing early, such as a field the order form doesn't have. Trace each loop back to the step that creates the problem, because that is where the fix belongs.

At each handoff, ask the team receiving the work one question: what share of it can you use exactly as it arrives, with nothing chased or sent back? Ask the receiver, not the sender. Senders compare their work with what they were given, so they often rate it higher.

Lean teams put a version of this on value stream maps as percent complete and accurate⁶: the share of a step's work completed with perfect quality. Multiply it along the chain. Five handoffs that each pass 90% of work cleanly deliver only 59% end to end, while every team can honestly say its part is fine.

Then ask what they chase every time. It is often one or two pieces of information with no field to live in, and a missing field is fixable.

Take the draft back to the people who run each step. AHRQ's method ends the same way, by validating the chart's accuracy with the people actually involved². Keep improvements off this map and draw them on a separate future-state version, so today's process is recorded fairly.

Once the map is agreed, decide who owns each step with a RACI matrix. For incidents that break the normal flow, an escalation matrix sets out who gets called. The template at the top of this page has the sheets ready, and River can draft the first step register from your walkthrough and records.