Process Decomposition Done Right: L0 to L5 Levels Explained

Process decomposition is the most under-appreciated technique in process documentation and the one whose mishandling causes the most downstream pain. Teams produce process maps at a single level, usually whichever level they are most comfortable with, and then struggle when the artefact does not answer the questions it needs to answer. A Level 1 map cannot answer a control testing question. A Level 5 map cannot support a strategic conversation. Each level has its job, and the decomposition discipline is what makes the hierarchy coherent.

This post covers the Level 0 to Level 5 decomposition hierarchy as it applies to financial services and other regulated industries. It describes what each level is for, what a good map at each level contains, and the failure modes that recur when decomposition is skipped or confused.

The hierarchy at a glance

• Level 0: Enterprise value streams. 6 to 12 top-level groupings.
• Level 1: Capability families. 4 to 10 per L0.
• Level 2: End-to-end processes. Named processes that a business stakeholder would recognise.
• Level 3: Sub-processes. The major stages of an L2 process.
• Level 4: Activities. The specific work steps within a sub-process.
• Level 5: Tasks and procedures. The step-by-step operating detail.

The hierarchy is not sacrosanct. Some firms stop at L3, some go to L6 for operational runbooks. What matters is that each level has a consistent meaning within the firm and each decomposition step explains the next level with conservation of scope.

Level 0: enterprise value streams

Level 0 is the top-level taxonomy of what the firm does for its customers and stakeholders. It is the same artefact as a high-level capability taxonomy (see capability maps for operating model) expressed in process terms.

In banking, Level 0 typically includes: Customer Management, Product Management, Operations, Risk and Compliance Management, Finance, Technology, Enabling Functions. In insurance: Customer Management, Underwriting, Policy Administration, Claims, Finance, Enabling Functions. In asset management: Investment Management, Sales and Client Service, Operations, Finance, Enabling Functions.

Level 0 maps are diagrams, not lists. They show the top-level groupings and their relationships: which ones feed which others, which ones are customer-facing, which ones are internal enablers. Level 0 is a one-page artefact that senior leadership and external stakeholders can engage with.

Level 1: capability families

Each Level 0 grouping decomposes into 4 to 10 Level 1 capability families. Continuing the banking example, Customer Management at L1 might include: Customer Acquisition, Customer Onboarding, Customer Servicing, Customer Analytics, Customer Relationship Management.

Level 1 maps are useful for:

• Target operating model design, where capability families are the units of redesign
• Organisational structure alignment, where the L1 families map to organisational ownership
• Portfolio prioritisation, where transformation initiatives are allocated to L1 families

Level 1 is the level at which the target operating model framework typically operates.

Level 2: end-to-end processes

Level 2 is the level at which most business stakeholders talk. "The mortgage application process". "The claims settlement process". "The trade settlement process". "The customer onboarding process". Each L2 process has a defined trigger, a defined output, and a defined set of actors.

Level 2 maps are what most business users mean when they ask for "a process map". The diagrams show the major phases from trigger to output and identify the main actors. Level 2 is where end-to-end thinking lives and where value stream maps typically sit.

A well-drawn L2 map reveals handoffs between teams, major decision points, and systemic bottlenecks. It does not show every individual task; that is L4 or L5 territory. An L2 map that tries to show everything becomes unreadable.

Level 3: sub-processes

Each L2 process decomposes into L3 sub-processes. For a mortgage application L2, L3 sub-processes might be: Application Intake, Affordability Assessment, Property Valuation, Credit Decision, Offer Production, Completion.

Level 3 is the level at which process redesign happens. When a team says "we are redesigning the affordability assessment sub-process", they are operating at L3. The L3 map shows the flow, the major decision points, the system touchpoints, and the data flows within the sub-process.

Level 3 maps are often where BPMN modelling is first applied seriously, because BPMN's expressiveness pays off at the sub-process level where flows become non-trivial.

Level 4: activities

Each L3 sub-process decomposes into L4 activities. Continuing the example, the Affordability Assessment sub-process at L4 might include: Gather Income Evidence, Calculate Disposable Income, Apply Stress Test, Apply Policy Overrides, Generate Affordability Outcome.

Level 4 is the level of operational work. Each activity is a named, discrete piece of work performed by a specific role using specific systems. Level 4 maps support:

• Work allocation and scheduling
• System requirements (FRDs reference L4 activities)
• Operational metrics and KPIs (volumes, cycle times, quality measured at L4)
• Detailed automation decisions (which activities are candidates for RPA, AI, or redesign)

Level 5: tasks and procedures

Each L4 activity decomposes into L5 tasks. Gather Income Evidence at L5 might include: Request Payslips, Validate Payslip Authenticity, Extract Income Data, Record Income in Application, Request Bank Statements, Validate Bank Statement Completeness, Reconcile Income Sources.

Level 5 is the level of procedural detail. The format at L5 is often a procedure document rather than a diagram, because the fidelity required is step-by-step instruction. L5 is the level at which:

• Training materials are written
• Operational procedures (SOPs) live
• Control execution is specified
• Manual work is timed for operational metrics

Matching fidelity to purpose

The failure mode most teams make is producing the wrong level for their purpose. A strategic conversation at a steering committee requires L0 or L1. An operating model redesign requires L1 or L2. Process improvement requires L3 or L4. SOP documentation requires L5. Producing an L3 map when L1 was needed produces overwhelm. Producing an L1 map when L4 was needed produces shallow analysis.

The right answer is to produce the level appropriate to the purpose, and to maintain the decomposition between levels so that any conversation can move up or down as needed.

Conservation of scope across levels

The discipline that keeps the hierarchy coherent is conservation of scope. An L3 sub-process cannot include activities that are not in the L2 process. An L4 activity cannot include tasks that are not in the L3 sub-process. When the decomposition is done correctly, L5 tasks roll up cleanly to L4 activities, which roll up cleanly to L3 sub-processes, and so on.

When conservation breaks, the hierarchy is incoherent. The L1 map and the L4 map describe different worlds. Audit questions that go "from the strategic view to the operational detail" lose their thread partway down. Fix: decomposition is reviewed at each level before the next level is produced, and changes at any level are propagated up and down.

Governance and ownership by level

Different levels need different owners.

L0 and L1: owned by enterprise architecture or business architecture

The enterprise-level taxonomy is stable and high-visibility. It belongs with the function that owns the firm's overall map of itself.

L2: owned by business process owners

Each L2 process has a named business process owner who is accountable for the end-to-end process. This ownership is often where business process management discipline starts.

L3 and L4: owned by operational leaders

The sub-processes and activities belong with the operations leader who runs them. Ownership here is practical: the owner is accountable for the performance, the metrics, and the continuous improvement.

L5: owned by operational teams

Procedural detail belongs with the teams doing the work. Maintaining L5 procedures is a shared responsibility between the team and the process owner.

Common failure modes

Failure: single-level maps

The firm produces process maps at one level only, typically L3. Strategic conversations lack high-level framing. Operational conversations lack detail. The maps are criticised at both ends for being at the wrong level. Fix: produce maps at each level that the firm actually uses, with clear decomposition from level to level.

Failure: incoherent decomposition

Level 1 and Level 3 maps describe the same territory differently. The Level 3 map uses terms that do not appear in the Level 1 map. The decomposition was done by different teams without coordination. Fix: decomposition is a single coordinated exercise with explicit conservation of scope.

Failure: every map is L5

Teams produce highly detailed process documentation at the task level for every process. The detail is fine-grained but the oversight level is missing. Fix: not every process needs L5 documentation. Focus L5 effort on processes that genuinely require it (processes with procedural operational risk, regulated controls, or safety implications).

Failure: L5 as dead document

L5 procedures are produced, filed, and not referenced by the teams doing the work. The procedures drift from operational reality. Fix: L5 procedures are linked to training, to operational handover, and to control testing. If a procedure is not being used, either the procedure is wrong or the work should be following the procedure. Diagnose and correct.

Failure: no L0 or L1

The firm has L2 process maps but no enterprise-level process taxonomy. Strategic conversations have no anchor. New initiatives are positioned in ad hoc ways. Fix: produce L0 and L1 maps as an enterprise exercise, anchored to the capability map.

Connection to the broader artefact stack

Process decomposition connects to:

• The capability map: the L0 and L1 levels align to the capability hierarchy.
• The value stream map: typically at L2 or L3.
• The service blueprint: typically at L3 with backstage detail at L4.
• The use cases: use cases often correspond to L3 sub-processes.
• The context diagram: enterprise context sits at L0; system context at L2 or L3.
• The BPMN process mapping resource: provides notation reference across levels.

External references

The APQC process classification framework provides an industry reference for process decomposition. The eTOM framework provides a telecom-specific example that generalises. The OMG BPMN specification is the canonical notation reference for process modelling at L2 through L4.

The short version

Process decomposition is a hierarchy, not a single level. Each level serves a purpose. Conservation of scope across levels is the discipline that keeps the hierarchy coherent. Ownership differs by level. Governance follows the ownership.

Firms that maintain a coherent decomposition can move up and down the hierarchy as conversations demand. Firms that have only one level find every conversation lands at the wrong altitude.

Our process mapping and documentation service, target operating model design service and business analysis service support clients in establishing and maintaining the decomposition hierarchy at the level of rigour their regulatory and operating context demands.