Modeling an As-Is Process

Modeling an As-Is Process

The BPMN notation you have learned in the previous six lessons is a tool. In this lesson you learn how to aim that tool at reality. An as-is model (also called the current-state model) is a BPMN diagram that captures a business process exactly as it runs today — warts, workarounds, and all. It is deliberately not an improvement plan. Its job is to hold up a mirror.

Getting the as-is right is arguably the most important analytical act in the entire engagement. Every later step — gap analysis, redesign, requirements writing, testing — stands on the accuracy of this model. Analysts who skip or rush the as-is phase routinely discover, after months of development, that the new system does not match how people actually work.

What the As-Is Model Must Capture

A complete as-is BPMN model captures:

• Participants — every person, role, or system that touches the process (mapped to pools and lanes).
• Actual sequence — what really happens, not what the procedure manual says should happen. Interview the people who do the work, not just their managers.
• Decision points — every branch where different outcomes lead to different paths (exclusive or inclusive gateways).
• Handoffs — moments when work passes from one lane or pool to another; these are prime locations for delays and information loss.
• Exceptions and workarounds — the informal fixes people have invented to cope with a broken process. These are gold: each workaround signals a pain point.
• Wait states — intermediate events where the process simply stops and waits (for an approval email, a delivery, a scheduled batch run).

Elicitation Techniques for As-Is Capture

You already know requirements-elicitation techniques from Tutorial 3. For as-is process capture, the most effective approaches are:

1. Shadowing (observation) — sit beside the worker and watch. Ask clarifying questions after, not during. You will see steps that nobody thinks to mention because they feel automatic.
2. Process walkthrough interview — ask the worker to walk you through the last three or four real cases, not a generic description. "What did you do specifically the last time you got an urgent repair request?" surfaces the exceptions that generic descriptions omit.
3. Happy-path-plus-exceptions workshop — start by sketching the normal flow on a whiteboard with the team, then ask: "When does this step not work? What do you do then?" Each exception becomes an alternative path or a boundary event.
4. Document analysis — collect every form, template, and email thread associated with the process. A routing slip or a three-column spreadsheet tells you about steps and data flows that participants may take for granted.

Annotating Pain Points

As-is diagrams become analytical documents when you annotate them. Standard conventions include:

• Red border or fill on tasks or gateways that are known bottlenecks — where queues build or where errors are frequently introduced.
• BPMN text annotations (<?> association arrows) attached to flow elements, noting observed wait times, error rates, or volumes.
• Intermediate error events on the boundary of a task to show where exceptions are currently handled (even informally).
• Dashed swimlane borders to highlight where a lane boundary is crossed without a formal handoff document — a common source of information loss.

Worked Example: Clinic Appointment Booking (As-Is)

Consider a private medical clinic that handles appointment requests by phone, email, and walk-in. No appointment software exists. The process involves a receptionist, a doctor's assistant, and the doctor. Patient calls arrive on a shared landline; emails land in a single shared Gmail inbox checked intermittently.

From three shadowing sessions and a walkthrough workshop, the analyst documents the following as-is steps:

1. Patient contacts clinic (phone, email, or walk-in).
2. Receptionist checks the paper diary for free slots.
3. If a slot exists: receptionist writes patient name and complain in the diary, verbally confirms with patient, and the process ends for now.
4. If no slot exists: receptionist writes the patient's name on a sticky-note waiting list pinned to the diary. Pain point: sticky notes fall off; the waiting list is lost at least once per month.
5. When the doctor's schedule is updated (manually, by the assistant, once per week on Mondays), the assistant scans the waiting list. If the sticky note is still there, the assistant phones the patient to offer the new slot. Pain point: patients often cannot be reached; there is no callback protocol; the slot is sometimes given to the next walk-in instead.
6. On appointment day, the receptionist looks up the patient name in the diary and marks attendance. No system confirmation is sent in advance. Pain point: no-show rate is approximately 28% because patients forget.

This description translates directly into the annotated as-is BPMN model below. Notice how the bottleneck tasks are highlighted and the wait state between scheduling and appointment day is captured as an intermediate timer event.

Reading the Diagram as an Analyst

With the as-is model in front of you, three categories of finding emerge naturally:

1. Bottlenecks — tasks or gateways where work piles up. The "Scan Sticky Note List" step is a weekly batch activity; any patient who contacts the clinic on Tuesday must wait until the following Monday at the earliest. That is a five-day minimum wait introduced by a process design choice, not by clinical necessity.
2. Single points of failure — the sticky-note waiting list is a single physical artefact with no backup. Its loss directly causes service failure.
3. Missing feedback loops — there is no mechanism to notify patients of their confirmed appointment, no reminder, and no escalation path if the assistant cannot reach the patient by phone. Each absence is a requirement waiting to be written.

Validating the As-Is Model

Before you present the as-is model as a baseline, validate it with a structured walkthrough. Gather at least one representative from each swimlane and walk through the diagram token by token: "A patient calls — the token enters here. The receptionist checks the diary — does the token move here next?" Participants will correct sequencing errors, add missing exceptions, and confirm pain points. A validated as-is model carries the team's consensus; a solo analyst's sketch does not.

Record the validation meeting date and attendees at the foot of the diagram. This is the reference baseline against which every to-be design decision will be justified.