Mapping the current process

Why it matters

Interview notes are a pile of stories. A process map turns them into one picture that everyone can check. It shows who does what, in what order, where decisions happen and where the work goes wrong. The as-is map shows the process as it really runs today, workarounds included. You cannot design a better process until people agree on the current one.

The building blocks

Most process maps today use a simplified form of BPMN (Business Process Model and Notation), an open standard maintained by the Object Management Group. You only need a handful of shapes:

Lanes are what make a map useful. Each lane is a role (member, librarian, system), so a glance shows every hand-off. Hand-offs are where delays and mistakes hide.

Worked example: Riverside Library today

From the interviews, the booking process looks like this, written as text before you draw it:

Lane: Member
  (start) Member wants a room
  Phone the front desk
Lane: Librarian
  Check paper diary
  <gateway> Room free at that time?
     no  -> Offer another time -> back to Member: accept? (yes -> continue, no -> end: no booking)
     yes -> Pencil booking in diary
  Ring member back to confirm        [PAIN: often forgotten, ~1 per week]
Lane: Member
  Arrive for meeting
Lane: Librarian
  <gateway> Room actually free?      [PAIN: double bookings, two people write in one diary]
     yes -> (end) Meeting happens
     no  -> Find another room or apologise -> (end)

Drawn as a diagram, the member and librarian lanes run across the page and the arrows zig-zag between them. Even before you finish, two things stand out: the member cannot see availability without a phone call, and nothing stops two librarians from booking the same slot.

How to build an as-is map

1. Name the process and its boundaries. "Meeting-room booking, from a member wanting a room to the meeting starting." Boundaries stop the map from growing forever.
2. List the roles and draw a lane for each.
3. Write the happy path first: the steps when everything goes right, as verb-noun tasks ("Check diary", not "Diary").
4. Add decisions and exceptions with gateways: what happens when the room is not free, when the member does not answer.
5. Mark pain points with a note or a red marker: delays, rework, errors, frustration. Add numbers if you have them.
6. Walk it through with the people who do the work. Ask "is this what really happens?" Expect corrections.

Sticky notes on a wall are perfect for a first draft. Free tools such as draw.io (diagrams.net) or the free tiers of online whiteboards work for a clean version.

Map what is, not what should be

The most common trap is drawing the official procedure. If the policy says librarians ring back within an hour but they actually forget once a week, the as-is map shows "ring back (often forgotten)". The point is to make the real problems visible. Resist fixing things while you map them; that is the to-be design later in this course.

Level of detail

Pick one level and stay there. A high-level map has 5 to 15 tasks and fits on one page. If a task hides a lot of work ("Process invoice"), give it its own detailed map rather than squeezing 40 boxes into one diagram.

Common mistakes

• No lanes, so hand-offs are invisible.
• Mixing levels: "Run the library" next to "Click Save".
• Only the happy path, when exceptions cause most of the pain.
• Mapping alone and never validating with the people who do the work.
• Vague task names such as "Booking" instead of "Pencil booking in diary".

Quick recap

• An as-is map shows the current process honestly, workarounds and pain points included.
• Use a few BPMN shapes: start, task, gateway, flow, end, and lanes for roles.
• Build the happy path, add exceptions, mark pain points, then validate.
• Keep one level of detail per map.

Try it

Open the Do tab and map a real process from your interview, or from your own daily life.