Mapping the system before you change it: a practitioner's how-to

To map a system before you change it, pick one outcome that matters to the people the change is for, then draw everything that currently produces that outcome: the people and units involved, what flows between them, the rules that govern them, and the loops that keep the present state stable. A good map takes two to four weeks, is built with the people inside the system rather than about them, and ends with a short list of places where a change is likely to hold. Without it, a transformation usually changes the part of the system that is easiest to see and then watches the rest of the system quietly undo it.

Why the map comes first

Most transformation plans are drawn on an org chart. The org chart shows who reports to whom. It does not show how work actually moves, where a request waits for three weeks, or which informal rule everyone follows because breaking it once caused trouble. Those are the things that decide whether a change survives.

Systems thinking has a long tradition here. Peter Senge's The Fifth Discipline (1990) popularised the idea that organisations behave according to their structure, not their intentions, and Donella Meadows' essay Leverage Points: Places to Intervene in a System (1999) argued that the places people instinctively push, such as targets and budgets, are often the weakest places to act.

This article is the practical companion to Transformation fails at the customer's door, which sets out why change has to be felt by customers to count. Mapping is how you find out what currently stands between your organisation and that feeling.

Step 1: Choose the outcome, not the department

Start with one outcome described from the outside: "a small business gets a trading licence", "a patient is discharged and knows what to do next", "a supplier is paid on time". Avoid starting with a unit ("map the licensing department"), because the outcome almost always crosses three or four units and two outside parties.

Write the outcome in one sentence and agree two boundaries: where the system starts (the first moment someone needs something) and where it ends (the moment they have it, or give up). Everything inside those boundaries that shapes the outcome belongs on the map.

Step 2: List the actors, then place them

Run a stakeholder map first, because it is fast and gets names on the wall. Include:

• The people the outcome is for, split into the two or three groups who experience it differently.
• Every internal unit that touches a request, including the ones that only approve or check.
• Outside parties: regulators, suppliers, partner entities, banks, platforms.
• The quiet actors: the shared inbox, the legacy system, the committee that meets monthly. Treat a system or a meeting as an actor if work waits for it.

Then move to a system map and place the actors on one surface. Where several organisations share the outcome, an ecosystem map is the better canvas, because it shows value exchanged between entities rather than steps inside one.

Step 3: Draw the flows

Connect the actors with arrows and label every arrow with what moves: information, money, documents, approvals, people, data. Four kinds of flow are worth marking separately, in different colours:

1. Work flows. The request, file or case as it moves.
2. Information flows. Who tells whom what, and how late.
3. Money and resource flows. Budgets, fees, staff time.
4. Authority flows. Who can say yes, who can say no, who must be asked.

Where the flow is a sequence inside one team, a process flowchart captures it better than arrows on a big map. Where it involves the customer's experience and the back office together, a service blueprint shows both layers.

Do not draw flows from documents alone. Walk the journey yourself. A service safari, where the team goes through the service as a customer would, regularly reveals steps the official process does not mention.

Step 4: Mark the rules and the loops

This is the step most teams skip, and it is where the useful insight lives.

Rules. Next to each actor and flow, write the rules that shape behaviour: written policies, performance targets, approval thresholds, and the unwritten rules ("nobody signs before the director has seen it"). Ask people directly: "What would get you into trouble here?" The answers are the real rules.

Loops. Look for chains that feed back on themselves. A common one: complaints rise, so a review step is added, so processing slows, so complaints rise further. Another: a unit is measured on speed, so it rejects incomplete files quickly, so customers resubmit, so volume rises, so the unit looks busy and asks for more staff. Draw these as closed circles. A loop that keeps the current state stable is the reason previous change efforts faded.

Use five whys on any delay or failure point to follow it back to the rule or loop behind it.

Step 5: Find where change will be resisted and where it will hold

Now read the map as a whole. Three questions help:

• Where does work wait? Waiting points usually sit at authority flows, not work flows.
• Which rule, if changed, would change several flows at once? That is a candidate leverage point.
• Who benefits from the current state? Not as villains. Most resistance comes from people whose targets, workload or status depend on the present design.

For each candidate place to act, run a quick force field analysis (Kurt Lewin's tool): list the forces that will push the change forward and those that will hold it back. Choose the two or three places where the driving forces are real and the restraining forces can be addressed. These become the starting points for the roadmap, which is covered in Running a transformation roadmap that teams own.

Step 6: Validate the map with the people in it

Before anyone decides anything, take the map back to the people who appear on it, in small groups, and ask: "What is wrong or missing?" Expect corrections. Each correction makes those people co-authors of the diagnosis rather than its subject. A map that front-line staff recognise is the strongest argument a transformation team can carry into a leadership meeting.

Illustrative example

Illustrative. A mid-sized city council in Northern Europe wanted to halve the time to approve small building works. The original plan was a new online portal. The team mapped the system first, starting from the outcome "a householder gets permission to build an extension".

The map showed eleven actors, including two outside agencies and a monthly planning committee. The work flow looked reasonable; the authority flow did not. Any application touching a listed street went to the committee, regardless of size, and the committee met once a month. A loop sat behind it. Past complaints about one controversial extension had led to a rule that "all heritage cases go to committee", which slowed everything, which led to more applicants calling councillors, which kept the committee nervous and the rule in place.

The portal would have made submission faster and changed nothing about the wait. The council instead delegated small heritage cases to senior officers with clear criteria, kept the committee for large ones, and only then built the online form. The portal went live into a system that could use it.

Do's and don'ts

Do

• Start from an outcome the customer would recognise.
• Include outside parties and non-human actors such as systems and committees.
• Write the unwritten rules. Ask what gets people into trouble.
• Draw loops as circles so nobody mistakes them for straight lines.
• Take the map back to the people on it before acting.

Don't

• Map from policy documents and process manuals alone.
• Map a department when the outcome crosses five.
• Aim for completeness. A map is finished when it changes a decision, not when every box is drawn.
• Present the map as a finding about people rather than structure.
• Let mapping become the project. Two to four weeks is usually enough for one outcome.

Questions people ask

What is the difference between a system map and a process map? A process map shows the steps one piece of work goes through, usually inside one team. A system map shows all the actors, flows, rules and loops that together produce an outcome, including those outside your organisation. Use a process map to zoom in on one part of the system map.

How detailed should a system map be? Detailed enough to show where work waits and why. If a box or arrow would not change where you choose to act, leave it out. Most useful maps fit on one wall.

Who should be in the room when you map a system? People who do the work at each stage, at least one person who experiences the outcome as a customer, someone who knows the rules (policy, legal or finance), and the person who will sponsor the change. Keep the core group to six to ten, and validate with others afterwards.

Where to go next

Start with the system map and stakeholder map guides, zoom in with a service blueprint, and test your chosen points with force field analysis. If your last programme mapped nothing and still produced a thick report, Why transformation programmes produce reports and nobody changes how they work explains the pattern.