Lesson 1 of 3
The two model types
An As-Is model shows how a process currently works — including its inefficiencies, manual workarounds, unnecessary steps, bottlenecks, and pain points. It is a description of reality, not aspiration.
A To-Be model shows how the process should work after improvement, redesign, or automation. It is the target state.
The gap between the two is where business requirements come from. Every difference between the As-Is and the To-Be is a change that needs to happen. Every change is a requirement.
How to build an As-Is model
- Talk to the people who actually do the work, not just the managers who think they know how it works. The documented process and the actual process are often different — sometimes radically so.
- Map what actually happens, not what should happen. If the official process says invoices are approved within 2 days but in reality they take 10, the As-Is model shows the 10-day reality.
- Annotate pain points directly on the diagram. Use BPMN Text Annotations to flag issues: 'Average wait: 3 days — no notification to Finance Manager', 'Approx. 20% of invoices returned here due to missing PO reference.'
- Note handoff failures. Every Lane-crossing Sequence Flow is a handoff. Ask at each one: does this handoff work reliably?
The gap becomes the specification
The To-Be model is not aspirational decoration — it is the functional specification for what needs to be built or changed. Every difference between As-Is and To-Be is a change. Every change is a requirement.
Example: The As-Is invoice approval model shows that the Finance Clerk manually emails the Finance Manager when an invoice requires escalation. The To-Be model shows a system-generated notification triggered automatically. The gap produces a clear requirement: 'The system must automatically notify the Finance Manager when an invoice requiring their approval is submitted, without relying on manual email from the Finance Clerk.'
As-Is annotation: pain point taxonomy
Use consistent categories when annotating pain points. This makes them easier to analyse and prioritise:
| Pain point type | What to look for in the diagram | Example annotation |
|---|---|---|
| Delay / wait | Tasks without SLA timers; handoffs without notification mechanisms | 'Avg. 5-day wait here — no automatic notification' |
| Rework / loop | Backward sequence flows or explicit rework loops | 'Approx. 30% of cases loop here — missing PO reference' |
| Manual workaround | Tasks that should be automated but are User Tasks | 'Manually re-keyed into SAP — no integration' |
| Unclear ownership | Tasks not in a lane, or ambiguously named lanes | 'Finance team' — which role specifically? |
| Missing information | Handoffs without Data Objects | 'Invoice arrives without PO reference 20% of the time' |
| SLA risk | Tasks with SLA commitments but no Timer Boundary Event | 'Must be completed in 48h — currently unmonitored' |
✓ When to use
- Build an As-Is model at the start of any process improvement engagement — before proposing solutions
- Use it to validate what you've been told — stakeholders often describe the process as it should work, not as it does
- Use the As-Is/To-Be gap to generate the first draft of a requirements list
✗ When not to use
- ✕Don't spend weeks perfecting an As-Is for a process being replaced entirely — a rough sketch is enough
- ✕Don't share the As-Is without context — stakeholders may misread it as the approved target state