Skip to content

Strategy & Systems Design

Current state mapping: draw the whole system before changing any part

Ask where things go wrong and you'll hear about the slowest tool. Draw every person and tool, and how information gets from one to the next, and the trouble is usually on the lines between them: a job typed twice, a phone number kept in three places, a step nobody owns. The map shows the problem before anyone pays to redesign it.
fills inemailsafter hours, nobody owns itreadstypes infill intext photosdropped offre-types each joblogs estimatestax, year-endcustomerwebsite formoffice inboxscheduling toolphone …0142technicians T1–T6office lead's phoneoffice leadshared spreadsheetphone …0117paper job sheetsaccountingphone …0190operations managerfinance11jobs re-typed from paper into accounting22a customer's phone number in three places, all different33job photos on a phone, linked to no job44estimate follow-ups nobody owns12 people and tools · 4 failure points · 1 link nobody owns

What the map records

Drawn from conversations with each role, the tools themselves and a few real jobs followed through. Not from the org chart.
  1. 01

    Everyone who touches the work

    Roles, not names

    Including the customer, and the person who covers when someone's off.

  2. 02

    Every tool, however small

    The spreadsheet counts

    The bought systems, and the inbox, phone and paper that fill the gaps between them.

  3. 03

    How information moves

    Typed, texted, emailed, carried

    Each line says how it really travels. That's where most of the time and most of the mistakes are.

  4. 04

    Who owns each piece

    And what nobody owns

    A link with no owner works until the one person who quietly does it is away.

  5. 05

    Where work waits

    Queues, piles, overnight

    The waiting is usually longer than the work, and it's invisible until it's drawn.

  6. 06

    Where it breaks

    Numbered, with what it costs

    Each failure point is something the redesign has to answer, or decide to leave alone.

Four failure points, and what each asks

The tools themselves work. Each failure point sits between two of them, and each one turns into a requirement for the design.
1 · Jobs re-typed from paper into accountingthe office lead's afternoons, and typos on invoicescapture each job once, on site
2 · A phone number in three placesreminders sent to old numbers; nobody knows which is rightone owner for customer contact details
3 · Photos on the office lead's phonephotos hunted for when a customer questions the workphotos stored against the job they belong to
4 · Follow-ups nobody ownsestimates go cold without anyone deciding to drop theman owner and a next step for every open estimate
The website form after hoursrequests wait until morning, sometimes longeran immediate reply and an owner for after-hours requests

Three maps for three questions

They're related, but not interchangeable. We draw the ones the project needs.

Who and what, and how they connect

Answers
which tools hold what, how information moves between them, who owns each piece
Shows
people, tools, links, owners and failure points, as in the current-state map
Drawn from
each role's day, the tools' screens and exports
Used for
deciding which system owns each record, and what to connect or replace

What goes in, and what the map is used for

Drawn from

Each role
how their day really goes
Each tool
screens and exports
Real jobs
followed through
Current-state map
people, tools, links, owners, failure points

Used for

Future-state design
what the work becomes
Integration architecture
who owns each record
Opportunity analysis
what's worth changing

Worth drawing when several people and tools share the work

Good fit

  • Several tools and people touch the same job.
  • Nobody can say where a job is without asking around.
  • You're about to replace or connect tools and want to know what depends on them.

Not the right fit

  • One person, one tool, and the problem is already clear.
  • A single connection between two tools. A short conversation covers it.

Questions about current state mapping

How is this different from process discovery?

Discovery follows one process through real cases to find the steps nobody wrote down. Mapping draws the whole landscape those processes run through: every tool, every link and who owns it. They're usually done together.

How long does it take?

As long as the business needs. A few conversations for a small team with three tools; longer when there are several locations and many systems. We agree the scope before starting.

Do you need access to our systems?

A walk-through with the people who use them, and screens or exports where helpful. Mapping doesn't need administrator access.

What if the map shows nothing needs to change?

Then it says so, and you've avoided paying for something you didn't need. More often it shows that one or two links matter far more than the rest.