Makigami process map

A Makigami (Japanese for "roll of paper") maps an office or information process on one long sheet. Lanes run across for every role, department and system that touches the work, and the steps of one real case sit in those lanes in the order they happened. Underneath every step it captures four things a standard flowchart doesn't: tools (the documents and IT systems used), time (active processing time against wait time), quality (how often the work handed on is complete and accurate — its percent complete and accurate, or %C&A) and friction (errors, rework and bottlenecks). Makigami originates from the administrative pillar of Total Productive Maintenance (TPM); its closest equivalent is metrics-based process mapping. Where a value stream map reveals where a flow is blocked, a Makigami shows why — the hidden delays, handoffs and rework that drain an office process.

Scope and the real case

Name who receives the result, what exactly starts the process and what exactly ends it, and pick one real, recent case to follow — an actual invoice, order or request. One scenario per map: if the process branches, map the most common path, then use Save as a copy to map another scenario rather than drawing decision points. Set an ambitious target, such as halving the lead time.

The map

Work in layers. First who does what: a lane for everyone who touches the work, and the steps of the real case in order, each named verb + noun. Mark a step confirmed once someone from that lane has checked it against the case. Then how long: the hands-on work time, and how long it waited before the step started — counting nights, weekends and waiting for meetings. Waits and hands-on work each have their own unit, so waits can run in days while work stays in minutes; work is converted before it's added to lead time. Leave a time blank rather than guess. Note what you saw at each step — the email, form or ticket — so the map can be checked against the evidence. Then what it touches: every document, system and channel, and whether data already captured somewhere is typed in again.

Summary

Computed from the map — you don't type these in. Lead time follows the longest path through the case; the activity ratio is work time divided by lead time; handoffs count every time the work changes lanes, plus work sent back to another lane. Rolled first-pass yield — every step's percent complete and accurate multiplied together — appears once most steps have a score. A blank means data is still missing, and the summary says what.

What goes wrong

Pin a note to the step wherever the work waits, gets re-checked, re-typed, chased or sent back — quantity over polish, with how often it happens. Add a rework loop wherever work comes back to an earlier step. Ask the next person, not the sender, how often what arrives is complete and accurate. Tag each step as value-adding, needed but not value-adding, or waste. Describe the step, never the person.

Future state

Start the future state from a copy of the current map, then remove steps, merge handoffs and take out re-keying and approvals that add nothing. Removed and changed steps are marked, and the before-and-after numbers sit side by side. Work through four questions in turn: what can be eliminated, what can be combined, what can be rearranged, and what can be simplified. Remove the need to move work around rather than speeding up the moving.

Ideas and 100-day plan

Write ideas that each remove named problems, and sort them by who can fix them: A, the team on this map; B, needs another department; C, needs a company decision. Do the As first. Turn ideas into owned, dated actions — just do it, a kaizen event, or a project — and set a day-100 check.

The example below follows one real vendor invoice through Meridian Business Services' approval process: six lanes, eight steps, the documents and systems each step touches, work and wait times, a rework loop when the purchase order doesn't match, and seven problems pinned where they happen. Nearly all of the lead time is waiting while the work itself takes minutes. The future state removes the re-keying and a manual scheduling step, runs two approvals side by side, and comes with ideas sorted by who can fix them and a 100-day plan.

• Mapping how the process is supposed to work instead of what happened to a real case.

  The procedure never shows the inbox that sits for two days, the phone call to chase a missing number, or the side spreadsheet. Those are the whole point. Follow an actual case and ask "is this what happened last time?" at every step.

• Guessing times, or leaving waits out.

  In office processes the waiting usually outweighs the work many times over. A map with work times but no waits hides the biggest loss, and a guessed number looks as solid as a measured one. Check a timestamp, or leave it blank until you can.

• Going so detailed the map stops being readable.

  Hundreds of keystroke-level steps bury the handoffs and waits. If one process needs dozens of steps, split it into linked Makigamis — and if each step is really a whole department's work, you want a value stream map instead.

• Naming people in the problem notes.

  "Jo is slow to approve" puts people on the defensive and points at the wrong fix. "Approval request has no reminder" describes the step, which is what you can actually change.

• Stopping at the map.

  A beautiful wall with no owned actions changes nothing. The map earns its keep only when ideas trace to the problems they remove and someone checks the result on day 100.