Why models matter
A model is a shared language. A BPMN diagram means the same thing to the developer, the operations manager, and the auditor — because BPMN is a standard, not a personal notation. Models reduce the ambiguity that causes misaligned solutions.
Before models exist, process knowledge lives in people's heads. It leaves with them. The business analyst's job is to externalise that knowledge in a form that can be questioned, improved, agreed, and handed over.
By the end of this unit- Explain why formal notation matters in process and decision documentation.
- Distinguish between BPMN, DMN, and CMMN and know when each applies.
- Read and produce a level-1 BPMN process diagram.
- Construct a basic DMN decision table for a business rule set.
- Use value stream mapping to surface lead-time waste across a process.
Three types of work — three types of model
Not all work behaves the same way, and no single notation captures everything. The Object Management Group (OMG) recognised this and produced three complementary standards that together cover how organisations get things done.
BPMN — sequential processes
Business Process Model and Notation. For work that follows a defined sequence of activities, with branches, gateways, and handoffs between roles. The right tool for "how does this process work?"
DMN — decisions and business rules
Decision Model and Notation. For the logic inside a decision: what information goes in, what rules apply, what output comes out. Designed to interlock with BPMN.
CMMN — case-based work
Case Management Model and Notation. For knowledge-intensive work where the next step depends on what was discovered in the previous one — legal cases, clinical care, complex investigations. Less structured than BPMN.
BPMN — modelling processes
BPMN 2.0 is an ISO standard (ISO/IEC 19510:2013). It provides a graphical notation for specifying business processes in a business process diagram. Every major modelling tool supports it. Every serious BA uses it.
The five element types
BPMN has a defined vocabulary. Using it consistently is what makes diagrams readable across organisations and roles.
Flow objects — events, activities, gateways
Activities are units of work: tasks (atomic) and sub-processes (expandable). Shown as rounded rectangles.
Gateways control how flow diverges and converges. Exclusive (XOR): one path is taken. Parallel (AND): all paths are taken. Inclusive (OR): one or more paths are taken. Shown as diamonds with symbols inside.
Connecting objects — sequence flow and message flow
Message flow shows communication between two separate pools (separate organisations or systems). Dashed arrow. You cannot use sequence flow to cross a pool boundary — that distinction matters in regulated processes.
Swim lanes — pools and lanes
The critical rule: swim lanes show who is responsible for an activity, not where the work physically happens. A customer service agent in Manchester and one in Glasgow belong in the same lane.
Artefacts — data objects and annotations
Text annotations add explanatory notes. They are connected with a dotted line and do not affect process logic.
Three levels of BPMN
BPMN diagrams are not all the same depth. The level you use depends on who will read the diagram and what it needs to do.
Level 1 — Descriptive
Level 2 — Analytical
Level 3 — Executable
Most BA process work sits at L1 and L2. Produce L1 for stakeholder workshops and business sign-off. Produce L2 when the process will inform system design, testing, or simulation. Never produce L3 unless you are also the solution architect.
Think of a process you have recently documented or discussed. Was it captured formally? If you were to draw it in BPMN now, would L1 or L2 be more appropriate — and for which audience?
DMN — modelling decisions
Decision Model and Notation (DMN) is the OMG standard for business rules and decision logic. It was designed specifically to interlock with BPMN: where a BPMN diagram shows that a decision is made at a gateway, a linked DMN decision table shows exactly what rules drive that decision.
DMN is the right tool when decisions are complex, repeatable, and currently inconsistent because they live in people's heads or undocumented spreadsheets. Eligibility assessments, pricing engines, fraud scoring, lending decisions — these are all DMN territory.
Anatomy of a decision table
A decision table has three parts:
Inputs (conditions)
The information the decision depends on. Each input is a column. Values can be ranges, categories, or boolean. Example: credit score (band), annual income (range), existing debt (yes/no).
Outputs (actions)
What the decision produces. Often a single output column (approve/refer/decline), but complex decisions may have multiple output columns (outcome + reason code + maximum loan amount).
Rules (rows)
Each row is one combination of conditions and the output it produces. The hit policy (U, A, F, etc.) defines how many rows can fire for a given input set. U (Unique) is the most common: exactly one row matches.
Worked example: loan eligibility
The question to ask when building any decision table: "What information do you need to make this decision, and what are the possible outcomes?" For loan eligibility the answer looks like this:
Inputs identified
Annual income: £40k+, £25k–£39k, <£25k
Existing debt-to-income ratio: <30%, 30–49%, 50%+
Output defined
A refer outcome means the automated rules cannot determine the outcome with confidence — a human underwriter reviews the case.
Selected rules (sample rows)
| Credit band | Income | DTI | Outcome |
|---|---|---|---|
| Excellent | £40k+ | <30% | Approve |
| Good | £40k+ | <30% | Approve |
| Good | £25k–£39k | 30–49% | Refer |
| Fair | Any | Any | Refer |
| Poor | Any | Any | Decline |
| Any | Any | 50%+ | Decline |
When working with subject matter experts who struggle to articulate rules, ask: "Walk me through the last three decisions you made. What made you choose that outcome each time?" The inputs and thresholds will emerge from the examples faster than from abstract discussion.
Value stream mapping and Lean
BPMN shows how a process works. A value stream map (VSM) shows whether the process is worth running as it currently stands — by making lead time, wait time, and waste visible at a glance.
VSM originated in the Toyota Production System and was formalised in Lean manufacturing. It has been widely adopted in service and knowledge work because the insights transfer directly: wherever there are handoffs, there is waiting; wherever there is waiting, there is waste.
What a VSM shows
Material and information flow
The end-to-end sequence of steps from supplier to customer. Unlike BPMN, VSM shows the total journey, not the internal logic of each step. The emphasis is on the gaps between steps — where queues form and time disappears.
Lead time vs processing time
Processing time is how long a step actually takes when someone is working on it. Lead time is how long the item sits in the queue before work starts. In most service processes, 70–90% of total lead time is wait time, not work time. The VSM makes this ratio visible.
VSM → BPMN drill-down
The VSM gives the big picture. Once a high-waste step is identified, BPMN goes deeper: what exactly happens inside that step, who is involved, where do exceptions arise? VSM locates the problem; BPMN diagnoses it.
The 7 wastes (TIMWOOD)
Lean identifies seven categories of non-value-adding activity. Memorising the acronym TIMWOOD is useful in any process review because it gives you a checklist of what to look for.
T — Transportation
I — Inventory
M — Motion
W — Waiting
O — Overproduction
O — Over-processing
D — Defects
DMAIC: the improvement cycle
When the VSM has identified waste and BPMN has diagnosed the process, DMAIC provides the structure for improvement.
Define the problem, the scope, and the success criteria. Identify the process owner and the customer. Produce the current-state VSM. This is where the BA's scoping skills are most directly applicable.
Measure current performance with data: cycle times, error rates, rework volumes, queue depths. Without measurement, improvement is guesswork. The BA works with operations to identify the right metrics and extract the data.
Analyse the data to find root causes. Tools: fishbone diagrams, 5 Whys, process capability analysis. The output is a list of root causes ranked by impact — not a list of symptoms.
Design and test the future-state process. Produce the future-state BPMN. Pilot changes before full rollout. Measure the impact against the baseline established in Measure.
Embed the improvements so gains are not lost. Update standard operating procedures, train staff, put monitoring in place, and define the handover to the process owner. Control is the stage most often skipped — and the reason improvements erode.
Think of a process in your current organisation. If you drew a rough timeline showing lead time vs processing time, where do you suspect most of the time goes? Which of the 7 wastes is most likely responsible?
Unit review
What does DMN stand for, and what is it used for?
Think of a business decision that currently lives in someone's head — a pricing judgement, an eligibility check, an approval threshold. What information goes into that decision? What are the possible outcomes? Could you sketch the inputs and outputs of a decision table for it, even without the full rule set?
End of Course 04
You should now be able to:
- Explain why formal notation produces better shared understanding than informal diagrams.
- Read and produce a Level 1 or Level 2 BPMN process diagram.
- Build a DMN decision table from a business rules elicitation session.
- Use a value stream map to surface lead time waste, and use DMAIC to structure the improvement response.
Continue to Course 05: Requirements and Deliverables.