L1 to L5: what process levels actually mean — and which one you need
Spend any time around process work and you'll hear people talk about "Level 3" or "mapping at L5" as if the meaning is obvious. It isn't. Used loosely, levels create the illusion of shared understanding while everyone pictures something different.
Here's the plain-English version — and why getting the altitude right matters more than the labels.
The levels, without the jargon
- L1 — the enterprise view. The handful of top-level capabilities that describe what the organisation does. Useful for orientation; useless for doing the work.
- L2 — major process groups. A breakdown of each capability into its main areas.
- L3 — the end-to-end process. This is where most transformation actually happens: a recognisable journey ("update plan details", "onboard a customer") with a clear start, end and owner.
- L4 — the activity flow. The steps within an L3, modelled in BPMN with decisions, handoffs and roles. This is where you see how the work really moves.
- L5 — the procedure. The detailed, do-this-then-that level that ties to SOPs and work instructions.
Pick the altitude for the decision
The mistake I see most often is mapping at the wrong level for the question being asked. Map an L3 journey when the board wants strategy, and you'll drown them in detail. Map at L2 when an operations team needs to fix a handoff, and you've given them nothing they can act on.
A simple rule: map at the level where the decision lives. Governance and prioritisation sit at L2–L3. Process improvement and automation analysis sit at L4. SOP rationalisation and training sit at L5.
Levels are a hierarchy, not a pile
The real value isn't any single level — it's the traceability between them. When an L5 procedure is anchored to an L4 step, which rolls up to an L3 journey, which belongs to an L2 group, you can answer questions that cut across the whole estate: which procedures does this regulation touch? what breaks if we automate this step? where do two teams document the same thing differently?
That connected structure — a taxonomy — is what turns a stack of diagrams into something you can reason about, and increasingly, something an AI tool can reason about too.
The takeaway
Don't argue about labels. Agree what each level means for your organisation, map at the altitude your decision needs, and keep the levels linked. That's the difference between pretty diagrams and a process architecture that earns its keep.