# Value Stream Map: [Value stream name] at [Organisation]

> Business architecture value stream map for one value stream: the
> triggering stakeholder and trigger, the value proposition, the stages
> with their entrance and exit criteria, the value items each stage
> produces, the cross-map from stages to business capabilities, the
> information concepts used, pain points, metrics and the improvement
> opportunities that follow. The concepts follow business architecture
> practice as described in the Business Architecture Guild's BIZBOK
> Guide (v15, April 2026). This is the business architecture value
> stream (how an organisation delivers value to a stakeholder, stage by
> stage), not a Lean manufacturing value stream map of material and
> information flow; section 1.4 explains the difference. Replace every
> `[bracketed]` value and every row marked *Example*.

<!--
Guidance: How to use this template
- Write one document per value stream. A portfolio of value streams is
  listed in section 3.1; each one gets its own map when it needs
  decisions.
- Work in this order: 3 (name the stream, its trigger and its end value)
  -> 4 (agree four to nine stages with business leaders) -> 5 (entrance
  and exit criteria) -> 6 (value items) -> 7 (capability cross-map) ->
  8 to 11 (information, stakeholders, pain points, metrics) -> 12 and 13
  (opportunities and traceability).
- Keep the stream independent of organisation units, processes and
  systems. Stages describe value increments, not departments or steps
  in a workflow tool.
- Reuse capability IDs from the Business Capability Map
  (`architecture/business-capability-map`); never invent a second
  capability list here.
- The worked examples describe a fictional retail insurer and its
  "Settle Claim" value stream. Delete them once your rows exist.
-->

## Document control

<!-- Guidance: Identify the value stream, the business owner who is accountable for the end value, and the planning decision this map supports. A new stage, a split or a merge of stages is a new major version. -->

| Field | Value |
|---|---|
| Document ID | [VSM-001] |
| Value stream ID and name | [VS-02 Settle Claim] |
| Organisation or scope | [Organisation, business unit or line of business] |
| Triggering stakeholder | [Policyholder] |
| Value stream owner (business) | [@business-owner] |
| Author | [@business-architect] |
| Version | [0.1] |
| Status | [Draft / In review / Approved / Superseded] |
| Approvers/reviewers | [@coo], [@chief-architect], [@customer-experience-lead] |
| Last updated | YYYY-MM-DD |
| Next scheduled review | YYYY-MM-DD |
| Classification | [Internal / Confidential] |
| Capability map version used | [BCM-ORG-001 v1.2] |
| Planning cycle supported | [FY YYYY portfolio review] |

### Approvals

| Role | Name | Decision | Date |
|---|---|---|---|
| Value stream owner | [@name] | [Approve / Approve with conditions / Reject] | YYYY-MM-DD |
| Chief architect | [@name] | [Decision] | YYYY-MM-DD |
| Owners of participating business units | [@names] | [Decision] | YYYY-MM-DD |
| Portfolio or strategy office | [@name] | [Decision] | YYYY-MM-DD |

### Revision history

| Version | Date | Author | Change summary |
|---|---|---|---|
| 0.1 | YYYY-MM-DD | [@name] | First draft from discovery workshop |
| 0.2 | YYYY-MM-DD | [@name] | *Example:* Stages agreed with claims, finance and customer service leads |
| 1.0 | YYYY-MM-DD | [@name] | *Example:* Capability cross-map and metrics baseline approved for the FY review |

## Contents

<!-- Guidance: Keep this list aligned with the headings. -->

1. [Purpose and scope](#1-purpose-and-scope)
2. [Modelling conventions](#2-modelling-conventions)
3. [Value stream definition](#3-value-stream-definition)
4. [Value stream stages](#4-value-stream-stages)
5. [Entrance and exit criteria](#5-entrance-and-exit-criteria)
6. [Value items and stakeholder value](#6-value-items-and-stakeholder-value)
7. [Capability cross-map](#7-capability-cross-map)
8. [Information concepts](#8-information-concepts)
9. [Participating stakeholders and organisation](#9-participating-stakeholders-and-organisation)
10. [Pain points and issue assessment](#10-pain-points-and-issue-assessment)
11. [Value stream metrics](#11-value-stream-metrics)
12. [Improvement opportunities](#12-improvement-opportunities)
13. [Traceability matrix](#13-traceability-matrix)
14. [Governance and maintenance](#14-governance-and-maintenance)
15. [Glossary and references](#15-glossary-and-references)

## 1. Purpose and scope

<!-- Guidance: State the decision this map will inform. A value stream drawn "to understand the business" rarely changes anything; one drawn to locate the stage that loses most customers or to scope a programme does. -->

### 1.1 Purpose

This map describes how [Organisation] delivers [end value] to
[triggering stakeholder] in the [value stream name] value stream. It is
used to [locate the stages where value is lost, explain customer-visible
problems in capability terms, prioritise the FY YYYY change portfolio,
scope the target business architecture for programme X].

### 1.2 Scope

- **In scope**: [all channels through which a policyholder can report a
  loss, from first notice to final payment or closure].
- **Out of scope**: [subrogation and recovery from third parties, which
  form a separate value stream VS-07].
- **Time frame**: current state as of YYYY-MM-DD; target state for
  YYYY-MM-DD.
- **Variants covered**: [motor and household claims; commercial claims
  are a variant mapped separately because the stages differ].

### 1.3 Questions this map answers

1. Which stages deliver the value the stakeholder actually cares about,
   and in what order?
2. Where does the stream stall, loop back or lose stakeholders, and which
   capabilities sit behind each problem?
3. Which business units, partners and information concepts are involved
   at each stage?
4. Which improvement opportunities would raise end-to-end value most,
   and which initiatives already address them?

### 1.4 Business architecture value stream versus Lean value stream map

The term "value stream" has two common meanings. Choose deliberately and
say which one you use, because the two maps answer different questions.

| Aspect | Business architecture value stream (this template) | Lean value stream map (VSM) |
|---|---|---|
| Origin | Business architecture practice (BIZBOK Guide, TOGAF business architecture guidance) | Lean production, popularised by Rother and Shook, "Learning to See" (Lean Enterprise Institute) |
| Question answered | What value increments does the organisation deliver to a stakeholder, and which capabilities enable each one? | Where is waste and delay in the flow of material and information for a product family? |
| Level of abstraction | Stable, implementation-free, a few stages | Concrete, process steps with inventory, cycle times and wait times |
| Typical audience | Executives, strategy and portfolio offices, architects | Operations managers, process improvement teams, Lean coaches |
| Changes when | Strategy or business model changes | Process, layout or tooling changes |
| Main output | Stage to capability cross-map, investment priorities | Future-state flow, kaizen bursts, lead time reduction plan |
| Links to | Capabilities, information concepts, organisation, initiatives | Process maps, takt time, pull systems |

Use this template when you need to connect strategy and investment to
the customer outcome and to capabilities. Use a Lean VSM when you need
to cut lead time in a specific, repeatable operational flow. The two
work well together: a business architecture stage that scores badly in
section 10 is a good candidate for a Lean VSM of the processes that
realise it. Software delivery teams often use a third variant (flow
metrics across a delivery pipeline); treat it as a Lean VSM applied to
software.

### 1.5 Related documents

| ID | Document | Relationship |
|---|---|---|
| REF-01 | Business Capability Map (`architecture/business-capability-map`) | Source of every capability ID in section 7 |
| REF-02 | TOGAF Architecture Vision (`architecture/togaf-architecture-vision`) | Uses this map to scope the engagement and state the value proposition |
| REF-03 | Architecture Definition Document (`architecture/architecture-definition-document`) | Baseline and target business architecture reference the stages here |
| REF-04 | Customer Journey Map (`product/journey-map`) | Experience view of the same stakeholder; complements, does not replace |
| REF-05 | Process Document (`business/process-document`) | Processes that realise each stage |
| REF-06 | Zachman Framework Classification (`architecture/zachman-classification`) | Records where this map sits among the enterprise's models |

## 2. Modelling conventions

<!-- Guidance: Agree the rules before the first workshop. Most poor value streams fail on naming: stages named after departments or systems, or a stream that is really a process with forty steps. -->

### 2.1 Naming rules

| Element | Rule | Good *(Example)* | Poor *(Example)* |
|---|---|---|---|
| Value stream | Verb plus noun, from the stakeholder's point of view of the end value | Settle Claim | Claims Department Workflow |
| Stage | Verb plus noun describing a value increment | Assess Claim | Run Fraud Engine |
| Value item | A noun phrase describing something the stakeholder or the organisation has after the stage | Validated claim | Screen 3 completed |
| Entrance criterion | A condition that must be true to start the stage | Loss details recorded | Agent logs in |
| Exit criterion | A condition that is true when the stage has delivered its value item | Liability and amount decided | Ticket closed |

### 2.2 ID conventions

- Value streams: `VS-NN` (for example `VS-02`).
- Stages: `VS-NN.S` (for example `VS-02.3`), numbered in the order of
  normal progression.
- Value items: `VI-NN.S.n`; pain points: `PP-NNN`; metrics: `MET-NNN`;
  opportunities: `OPP-NNN`; information concepts: `INF-NNN`.
- Capabilities: the IDs of the capability map, unchanged (`CAP-NN.NN`).

### 2.3 Granularity and boundaries

- Aim for four to nine stages. Fewer usually hides the stage that
  matters; more usually means you are mapping a process.
- A stage must produce a distinct value item that someone would notice
  if it were missing.
- Stages are sequential in the normal case. Show loops and alternative
  paths in the diagram only when they matter to a decision, and never as
  a stage of their own.
- A value stream ends when the triggering stakeholder has received the
  end value, not when the organisation has finished its internal work.
- Do not put organisation units, roles, applications or channels in a
  stage name; record them as attributes in sections 9 and 7.

## 3. Value stream definition

<!-- Guidance: Define the stream before drawing stages. If people cannot agree who triggers the stream and what value they receive at the end, the stages will be argued forever. -->

### 3.1 Value stream inventory

List the organisation's value streams so the reader can see where this
one sits. Map only the ones that need decisions.

| ID | Value stream | Triggering stakeholder | End value | Mapped in |
|---|---|---|---|---|
| VS-01 *(Example)* | Acquire Insurance Coverage | Prospective customer | Customer is covered on the terms they chose | VSM-002 |
| VS-02 *(Example)* | Settle Claim | Policyholder | Loss is compensated fairly and promptly | This document |
| VS-03 *(Example)* | Renew Policy | Policyholder | Cover continues without a gap | Not yet mapped |
| VS-04 *(Example)* | Onboard Distribution Partner | Broker | Broker can sell and service products | Not yet mapped |
| [VS-NN] | [Name] | [Stakeholder] | [End value] | [Document ID] |

### 3.2 Triggering stakeholder and trigger event

| Attribute | Value |
|---|---|
| Triggering stakeholder | [Policyholder, or a person acting on their behalf] |
| Trigger event | [The stakeholder suffers a loss and asks the insurer to compensate it] |
| Typical frequency | [*Example:* about 140,000 claims a year, peaks after storms (the same fictional insurer as the TOGAF worked example)] |
| Other stakeholders who receive value | [Repairers, the insurer's finance function, the regulator] |
| Stakeholders who contribute but receive no direct value | [Loss adjusters, fraud analytics provider] |

### 3.3 Value proposition

Write the value proposition as one or two sentences the stakeholder
would recognise.

> [*Example:* When I suffer a covered loss, I can report it once, know
> what will happen next, and receive a fair settlement quickly enough
> to restore my situation.]

| Element | Content |
|---|---|
| End value for the triggering stakeholder | [Compensation received, situation restored] |
| Value for the organisation | [Retained customer, controlled claims cost, regulatory compliance] |
| Strategic objective supported | [OBJ-03 Improve retention by settling claims faster] |
| What "good" looks like to the stakeholder | [One report, clear status, fair outcome, prompt payment] |

## 4. Value stream stages

<!-- Guidance: Draw the stages with the business, then fill the catalogue. Read each stage name aloud with the stakeholder in mind: "first we register your loss, then we validate your cover". If it sounds like an internal procedure, rename it. -->

### 4.1 Stage diagram

Draw the normal path left to right, from trigger to end value. Show an
alternative exit only when a decision depends on it.

```mermaid
flowchart LR
  T([Trigger: policyholder reports a loss]) --> S1
  S1["VS-02.1 Register Loss"] --> S2["VS-02.2 Validate Cover"]
  S2 --> S3["VS-02.3 Assess Claim"]
  S3 --> S4["VS-02.4 Agree Settlement"]
  S4 --> S5["VS-02.5 Fulfil Settlement"]
  S5 --> S6["VS-02.6 Close Claim"]
  S6 --> V([End value: loss compensated])
  S2 -. not covered .-> X([Decline explained to policyholder])
```

### 4.2 Stage catalogue

| Stage ID | Stage | Description (original, one line) | Value item produced | Participating stakeholders |
|---|---|---|---|---|
| VS-02.1 *(Example)* | Register Loss | Capture what happened, when and to whom, once, through any channel | Registered claim | Policyholder, contact centre |
| VS-02.2 *(Example)* | Validate Cover | Confirm the policy was in force and the loss type is covered | Covered claim | Claims handler |
| VS-02.3 *(Example)* | Assess Claim | Establish liability, the amount of loss and any fraud indicators | Assessed claim | Loss adjuster, fraud team |
| VS-02.4 *(Example)* | Agree Settlement | Offer a settlement and reach agreement with the policyholder | Agreed settlement | Policyholder, claims handler |
| VS-02.5 *(Example)* | Fulfil Settlement | Pay or arrange repair or replacement | Compensation delivered | Finance, repairer network |
| VS-02.6 *(Example)* | Close Claim | Confirm the outcome, record lessons and release reserves | Closed claim | Claims handler, finance |
| [VS-NN.S] | [Stage] | [Description] | [Value item] | [Stakeholders] |

### 4.3 Variants and alternative paths

| Variant or path | Applies when | Stages affected | Treatment |
|---|---|---|---|
| Fast track *(Example)* | Low value, no fraud indicators | VS-02.3 shortened, VS-02.4 automatic | Same stages, different capability behaviour |
| Decline *(Example)* | Loss not covered | Ends after VS-02.2 | Exit path with explanation and complaint route |
| [Variant] | [Condition] | [Stages] | [Treatment] |

## 5. Entrance and exit criteria

<!-- Guidance: Criteria make stage boundaries testable. Write them as observable states of the business, not as system events or user actions. A stage whose exit criteria cannot be checked will not produce a reliable metric in section 11. -->

| Stage ID | Entrance criteria | Exit criteria | Evidence that the exit criteria are met |
|---|---|---|---|
| VS-02.1 *(Example)* | Policyholder has reported a loss through any channel | Claim has a unique reference, loss facts and contact details are recorded | Claim record exists with mandatory facts |
| VS-02.2 *(Example)* | Registered claim exists | Cover is confirmed or the claim is declined with a reason | Cover decision recorded |
| VS-02.3 *(Example)* | Cover confirmed | Liability, loss amount and fraud risk are decided | Assessment report approved |
| VS-02.4 *(Example)* | Claim assessed | Policyholder has accepted an offer, or a dispute route is opened | Acceptance recorded |
| VS-02.5 *(Example)* | Settlement agreed | Money paid or repair completed | Payment confirmation or repairer sign-off |
| VS-02.6 *(Example)* | Compensation delivered | Policyholder informed, reserves released, file archived | Closure record |
| [VS-NN.S] | [Criteria] | [Criteria] | [Evidence] |

Check every pair against these quality rules:

- The exit criteria of one stage imply the entrance criteria of the next.
- Each criterion is binary: it is either met or not met.
- No criterion names a specific application, screen or team.
- Exit criteria describe the value item being complete, not merely work
  having been done.
- Alternative exits (decline, dispute, withdrawal) are written down, so
  that metrics can count them separately.

## 6. Value items and stakeholder value

<!-- Guidance: A value item is what exists after a stage that did not exist before. List them per stakeholder, because the same stage can create value for one stakeholder and cost for another. -->

### 6.1 Value items by stage

| Value item ID | Stage | Value item | Receiving stakeholder | Tangible or intangible |
|---|---|---|---|---|
| VI-02.1.1 *(Example)* | VS-02.1 | Registered claim with reference | Policyholder | Tangible |
| VI-02.1.2 *(Example)* | VS-02.1 | Reassurance that the loss is being handled | Policyholder | Intangible |
| VI-02.3.1 *(Example)* | VS-02.3 | Reliable assessment of loss | Insurer | Tangible |
| VI-02.5.1 *(Example)* | VS-02.5 | Compensation received | Policyholder | Tangible |
| VI-02.6.1 *(Example)* | VS-02.6 | Released reserve and closed exposure | Insurer finance | Tangible |
| [VI-NN.S.n] | [Stage] | [Value item] | [Stakeholder] | [Type] |

### 6.2 Stakeholder value matrix

Mark for each stakeholder and stage whether the stakeholder receives
value (R), contributes (C) or is unaffected (blank).

| Stakeholder | VS-02.1 | VS-02.2 | VS-02.3 | VS-02.4 | VS-02.5 | VS-02.6 |
|---|---|---|---|---|---|---|
| Policyholder *(Example)* | R, C | R | C | R, C | R | R |
| Claims handler *(Example)* | C | C | C | C | | C |
| Repairer *(Example)* | | | C | | R, C | |
| Insurer finance *(Example)* | | | | C | C | R |
| [Stakeholder] | | | | | | |

## 7. Capability cross-map

<!-- Guidance: The cross-map is the main reason to build a business architecture value stream. It explains customer-visible problems in capability terms and lets the portfolio office fund capabilities rather than projects. Use the capability map IDs and heat scores as they are; if a capability is missing, raise it with the capability map owner. -->

### 7.1 Stage to capability cross-map

| Stage ID | Enabling capabilities (ID and name) | Weakest capability | Heat of weakest (from capability map) |
|---|---|---|---|
| VS-02.1 *(Example)* | CAP-06.01 Claims Intake, CAP-03.03 Customer Service, CAP-03.02 Customer Information Management | CAP-06.01 | Red |
| VS-02.2 *(Example)* | CAP-05.02 Policy Servicing, CAP-06.01 Claims Intake | CAP-06.01 | Red |
| VS-02.3 *(Example)* | CAP-06.02 Claims Assessment (including L3 CAP-06.02.02 Fraud Detection), CAP-05.02 Policy Servicing | CAP-06.02 | Amber |
| VS-02.4 *(Example)* | CAP-06.03 Claims Settlement, CAP-03.03 Customer Service | None red | Green |
| VS-02.5 *(Example)* | CAP-06.03 Claims Settlement, CAP-07.01 Payment Execution | None red | Green |
| VS-02.6 *(Example)* | CAP-06.03 Claims Settlement, CAP-07.03 Reserving | None red | Green |
| [VS-NN.S] | [CAP IDs] | [CAP ID] | [Heat] |

The rows above repeat the VS-02 cross-map of the Business Capability
Map (`architecture/business-capability-map`, section 7) with the same
IDs and heat values; change them there first. A stage is only as strong
as its weakest enabling capability. Use the
third column to explain why a stage underperforms, and section 12 to
decide whether to invest in that capability.

### 7.2 Capability reuse across value streams

Capabilities that enable stages in several value streams are leverage
points: an improvement there pays off more than once. In the *Example*,
VS-01 stages come from its own value stream map (VSM-002) and VS-03.2 is
a provisional stage ID from the inventory in section 3.1, because VS-03
is not yet mapped; confirm both when those maps are approved.

| Capability | Value stream stages enabled | Count | Implication |
|---|---|---|---|
| CAP-03.03 Customer Service *(Example)* | VS-01.3, VS-02.1, VS-02.4, VS-03.2 | 4 | Invest once, benefit three streams |
| CAP-03.02 Customer Information Management *(Example)* | VS-02.1 | 1 | Amber with a risk cross; source of pain point PP-004 |
| CAP-06.01 Claims Intake *(Example)* | VS-02.1, VS-02.2 | 2 | Red on two stages of this stream; highest leverage for VS-02 |
| [CAP ID] | [Stages] | [n] | [Implication] |

## 8. Information concepts

<!-- Guidance: Record the business information each stage creates, reads or changes. This links the business architecture to the data architecture without descending into tables and columns. -->

| Information concept ID | Concept | Stages that create (C), read (R) or update (U) | Owning capability | Authoritative source today |
|---|---|---|---|---|
| INF-001 *(Example)* | Claim | VS-02.1 C, VS-02.2 to VS-02.6 U | CAP-06.01 | [Claims system] |
| INF-002 *(Example)* | Policy | VS-02.2 R | CAP-05.02 | [Policy administration system] |
| INF-003 *(Example)* | Party (policyholder, third party, repairer) | VS-02.1 C or R, VS-02.3 R, VS-02.5 R | CAP-03.02 | [CRM, duplicated in claims] |
| INF-004 *(Example)* | Settlement | VS-02.4 C, VS-02.5 U | CAP-06.03 | [Claims system] |
| INF-005 *(Example)* | Payment | VS-02.5 C | CAP-07.01 | [Finance ledger] |
| [INF-NNN] | [Concept] | [Stages and CRUD] | [CAP ID] | [Source] |

Flag any concept with more than one authoritative source, or none, as a
pain point in section 10. Detailed definitions belong in the Data
Dictionary (`architecture/data-dictionary`).

## 9. Participating stakeholders and organisation

<!-- Guidance: Show who does the work in each stage. Hand-offs between organisation units are where most delay and rework hide; this table makes them visible without putting departments into stage names. -->

| Stage ID | Accountable business unit | Contributing units and partners | Hand-offs out of the unit | Channels |
|---|---|---|---|---|
| VS-02.1 *(Example)* | Customer service | Broker, digital team | 1 (to claims) | Phone, web, app, broker |
| VS-02.2 *(Example)* | Claims operations | Policy administration | 1 | Internal |
| VS-02.3 *(Example)* | Claims operations | Loss adjuster partner, fraud team | 2 | Field visit, internal |
| VS-02.4 *(Example)* | Claims operations | Customer service | 1 | Phone, email, app |
| VS-02.5 *(Example)* | Finance | Repairer network | 2 | Bank transfer, repairer portal |
| VS-02.6 *(Example)* | Claims operations | Finance | 1 | Internal, letter or email |
| [VS-NN.S] | [Unit] | [Units] | [n] | [Channels] |

### 9.1 Accountability (RACI) for maintaining this map

| Activity | Value stream owner | Business architect | Stage leads | Capability owners | Portfolio office |
|---|---|---|---|---|---|
| Define stages and criteria | A | R | C | C | I |
| Maintain capability cross-map | I | A, R | C | C | I |
| Measure stage metrics | A | C | R | I | I |
| Prioritise opportunities | A | R | C | C | C |
| Fund initiatives | C | C | I | C | A, R |

## 10. Pain points and issue assessment

<!-- Guidance: Capture pain points with evidence and attach each to a stage and, where possible, to a capability. A pain point without evidence is an opinion; a pain point without a stage cannot be prioritised. -->

| Pain point ID | Stage | Description | Evidence | Linked capability | Severity (1 to 5) | Affected stakeholders |
|---|---|---|---|---|---|---|
| PP-001 *(Example)* | VS-02.1 | Policyholders repeat loss details when they switch channel | Complaint analysis, 3 months | CAP-06.01, CAP-03.03 | 4 | Policyholder |
| PP-002 *(Example)* | VS-02.3 | Assessment waits for adjuster visits on low-value claims | Workshop, sample of 200 claims | CAP-06.02 | 4 | Policyholder, insurer |
| PP-003 *(Example)* | VS-02.4 | Policyholders do not know the status of their claim | Customer survey | CAP-03.03 | 3 | Policyholder |
| PP-004 *(Example)* | VS-02.1 to VS-02.5 | Party data is duplicated between CRM and claims | Data quality report | CAP-03.02 | 3 | Insurer |
| [PP-NNN] | [Stage] | [Description] | [Evidence] | [CAP ID] | [1 to 5] | [Stakeholders] |

Define the severity scale before scoring: for example 5 means the
stakeholder abandons the stream or a regulatory obligation is at risk,
and 1 means a minor inconvenience with a workaround.

## 11. Value stream metrics

<!-- Guidance: Measure at stage and end-to-end level, using the exit criteria from section 5 as the measurement points. Combine stakeholder-perceived measures with internal ones. Record a baseline before setting a target, and name the data source. -->

| Metric ID | Level | Metric | Definition (measured between) | Baseline | Target | Source | Owner |
|---|---|---|---|---|---|---|---|
| MET-001 *(Example)* | End to end | Time to compensation | Trigger to VS-02.5 exit | [*Example:* 21 days median] | [*Example:* 10 days] | Claims system | [@value-stream-owner] |
| MET-002 *(Example)* | Stage | Registration completeness | Share of VS-02.1 exits with no later data request | [*Example:* 62%] | [*Example:* 90%] | Claims system | [@stage-lead] |
| MET-003 *(Example)* | Stage | Assessment cycle time | VS-02.2 exit to VS-02.3 exit | [*Example:* 9 days] | [*Example:* 4 days] | Claims system | [@stage-lead] |
| MET-004 *(Example)* | Stage | Settlement acceptance rate | Offers accepted at first offer in VS-02.4 | [*Example:* 78%] | [*Example:* 85%] | Claims system | [@stage-lead] |
| MET-005 *(Example)* | End to end | Stakeholder satisfaction | Survey after VS-02.6 exit | [*Example:* 6.8 of 10] | [*Example:* 8 of 10] | Survey tool | [@cx-lead] |
| [MET-NNN] | [Level] | [Metric] | [Definition] | [Baseline] | [Target] | [Source] | [@owner] |

Rules for metrics:

- Every metric names its start and end points using stage exits.
- Report medians and a high percentile for durations, not only averages.
- Count alternative exits (decline, dispute, withdrawal) separately so
  that a rising decline rate does not look like a faster stream.
- Use the metric definitions from the Metric Definition template
  (`ai-data/metric-definition`) when a metric feeds a dashboard.

## 12. Improvement opportunities

<!-- Guidance: Turn pain points and weak capabilities into opportunities, score them, and link each to an existing or proposed initiative. Opportunities stay at the business level; solution design happens in the documents that realise them. -->

### 12.1 Opportunity register

| Opportunity ID | Description | Addresses | Capabilities to change | Expected effect on metrics | Value (1 to 5) | Effort (1 to 5) | Priority |
|---|---|---|---|---|---|---|---|
| OPP-001 *(Example)* | Single loss record shared by all channels | PP-001, PP-004 | CAP-06.01, CAP-03.02 | MET-002 up, MET-001 down | 5 | 3 | High |
| OPP-002 *(Example)* | Desk or photo-based assessment for low-value claims | PP-002 | CAP-06.02 | MET-003 down | 4 | 2 | High |
| OPP-003 *(Example)* | Proactive status updates at each stage exit | PP-003 | CAP-03.03 | MET-005 up | 3 | 2 | Medium |
| [OPP-NNN] | [Description] | [PP IDs] | [CAP IDs] | [MET IDs] | [1 to 5] | [1 to 5] | [Priority] |

Agree the priority rule before scoring, for example "High when value is
at least 4 and effort at most 3".

### 12.2 Opportunity to initiative mapping

| Opportunity | Initiative or programme | Status | Target date | Architecture document |
|---|---|---|---|---|
| OPP-001 *(Example)* | Claims platform consolidation | Approved | YYYY-MM-DD | Architecture Definition Document (`architecture/architecture-definition-document`) |
| OPP-002 *(Example)* | Digital assessment pilot | Proposed | YYYY-MM-DD | Request for Architecture Work (`architecture/request-for-architecture-work`) |
| [OPP-NNN] | [Initiative] | [Status] | YYYY-MM-DD | [Document] |

## 13. Traceability matrix

<!-- Guidance: Trace from strategy to stage, capability, opportunity and initiative. Reviewers use this table to check that every funded initiative improves a stage that matters and that every high-severity pain point has an owner. -->

| Strategic objective | Value stream stage | Pain point | Capability | Opportunity | Initiative | Metric |
|---|---|---|---|---|---|---|
| OBJ-03 Improve retention *(Example)* | VS-02.1 | PP-001 | CAP-06.01 | OPP-001 | Claims platform consolidation | MET-002 |
| OBJ-03 Improve retention *(Example)* | VS-02.3 | PP-002 | CAP-06.02 | OPP-002 | Digital assessment pilot | MET-003 |
| OBJ-03 Improve retention *(Example)* | VS-02.4 | PP-003 | CAP-03.03 | OPP-003 | [Not yet funded] | MET-005 |
| [OBJ-NN] | [VS-NN.S] | [PP-NNN] | [CAP ID] | [OPP-NNN] | [Initiative] | [MET-NNN] |

Check that no row ends in "not yet funded" for a pain point of severity
5 without a recorded decision.

## 14. Governance and maintenance

<!-- Guidance: A value stream map stays useful only if someone owns it and the capability IDs stay in step with the capability map. Tie reviews to the planning cycle. -->

- **Owner**: the value stream owner is accountable for the end value and
  for this map; the business architect maintains it.
- **Review cadence**: at each planning cycle and whenever the
  capability map changes a capability used in section 7.
- **Change triggers**: a new product, channel or regulation that alters a
  stage; a merger; a restructuring of the organisation units in section 9
  (this changes section 9 only, not the stages).
- **Quality checks before approval**:
  - stage names pass the naming rules in section 2.1;
  - every stage has entrance and exit criteria and at least one value
    item;
  - every stage maps to at least one capability from the current
    capability map version;
  - every metric has a baseline and a source;
  - every high-severity pain point appears in the traceability matrix.
- **Repository**: store the map with the capability map in the
  architecture repository and record its location in the Zachman
  Framework Classification (`architecture/zachman-classification`).

## 15. Glossary and references

<!-- Guidance: Define the terms as your organisation uses them, in your own words. Do not paste definitions from bodies of knowledge. -->

### 15.1 Glossary

| Term | Meaning in this document |
|---|---|
| Value stream | End-to-end set of value-adding stages that deliver a result to a triggering stakeholder |
| Stage | One value increment in the stream, with its own entrance and exit criteria |
| Triggering stakeholder | The party whose request or need starts the stream and who receives the end value |
| Value item | Something of worth that exists after a stage, for a stakeholder |
| Entrance criteria | Conditions that must hold before a stage can start |
| Exit criteria | Conditions that hold once a stage has delivered its value item |
| Capability cross-map | Table showing which business capabilities enable each stage |
| Information concept | A business-level category of information, such as claim or policy |
| Lean value stream map | A Lean method that maps material and information flow with times and inventory to find waste |

### 15.2 References

| Reference | Version or date checked | Use |
|---|---|---|
| Business Architecture Guild, A Guide to the Business Architecture Body of Knowledge (BIZBOK Guide), businessarchitectureguild.org | v15, announced 8 April 2026, checked YYYY-MM-DD | Concepts of value stream, stage, value item and capability cross-mapping (no text used) |
| TOGAF Series Guide: Value Streams (G178), The Open Group, opengroup.org | Current edition, checked YYYY-MM-DD | Name only; cross-reference for TOGAF users |
| Mike Rother and John Shook, Learning to See, Lean Enterprise Institute, lean.org | Edition held by your organisation | Lean VSM contrast in section 1.4 only |
| Business Capability Map (`architecture/business-capability-map`) | [Version] | Capability IDs and heat |
| [Internal strategy document] | [Version] | Strategic objectives |

## Standard and licence note

Structure aligned with the value stream concepts of business
architecture practice as described in the Business Architecture Guild's
BIZBOK Guide (v15, April 2026): value stream, triggering stakeholder,
stages, entrance and exit criteria, value items and capability
cross-mapping. The BIZBOK Guide is copyrighted by the Business
Architecture Guild; this template uses only the generic concept names,
reproduces no text, tables, diagrams or reference models from it, and is
original text written for this collection. BIZBOK and Business
Architecture Guild are registered trademarks of the Business
Architecture Guild. TOGAF is a registered trademark of The Open Group;
this template uses only its name. The Lean comparison cites Rother and
Shook for context only. Check the current BIZBOK Guide version at
businessarchitectureguild.org before use. Template licence: MIT.