The programme ends, but the handovers are still broken
In this educational scenario, which is not a CYTIZEN client result, Élodie leads a commercial and IT programme. CRM is installed, contract management works and SAP interfaces have been delivered. Each team can show acceptance. A new sale still requires repeated exchanges to create the customer, approve the contract and enable invoicing. The problem lies between boundaries: no project owns the complete journey, and each team awaits information another considers already provided.
“Fewer large programmes” does not mean less leadership, architecture or discipline. It means organising some investment around a result crossing applications rather than independent tool delivery. A value stream is useful when it links a request, decisions and a business-recognised output. Renaming projects as products without changing responsibilities would not solve Élodie's problem.
Draw a boundary that retains the outcome
The chosen journey runs from validated sales request to the first correct invoice. It includes customer identity, opportunity qualification, contract, SAP master-data creation and invoicing conditions. The delivery is not “connect CRM to ERP” but “make an order invoiceable with the required data and approvals”. This changes the tests: a successful interface message is insufficient if the created customer lacks the parameters accounting needs.
Élodie records exceptions before mapping the nominal journey. A prospect can sign a confidentiality agreement without becoming an ERP customer. An existing customer may belong to another legal entity. An address change must not overwrite information used in a signed contract. The team decides which data SAP owns, which remain in CRM and which events can modify each reference source. A useful map also shows what must not flow.
Scope stays deliberately limited. The team does not simultaneously redesign customer relationships, pricing, supply chain and procurement. It chooses an observable sales segment, retains dependencies with other journeys and names their owners. A stream spanning the whole company would recreate the large programme under another name. The right boundary supports decisions and verifiable improvement while retaining interface control.
A cross-functional mandate with decision rights
The journey owner needs to arbitrate priorities across applications without owning every system. Their mandate describes purpose, assigned capacity, decisions they can take and those requiring escalation. The SAP owner preserves reference-data integrity, legal retains contract approval and finance retains its controls. The journey owner coordinates their contribution and owns end-to-end acceptance.
The scenario's decision log is completed: problem, duplicate customer creation; options, automatic creation from every opportunity or central validation first; decision, trigger creation only after identity and legal-entity validation; owner, customer data management; expected evidence, no duplication and successful invoicing in segment tests. Date and exceptions are recorded. This is more useful than an organisation chart naming everyone jointly responsible.
Capacity is explicit. Architects, business owners, testers and interface specialists are not available merely because their names appear in governance. The plan states reserved time and conflicts with operational commitments. If capacity is absent, the sponsor narrows scope or defers another commitment. Adding a committee does not create the expertise or time on which the stream depends.
Fund evolution without funding an endless backlog
Persistent funding does not remove accountability. Élodie proposes an envelope for improving the chosen journey, with capacity limits, recurring costs and continuation criteria. Management compares full change costs with observed outcomes: rework avoided, delays reduced and financial errors controlled. It does not reward the number of added features. Removing a business rule can create more value than another screen.
Stream cost includes application changes, interfaces, data, tests, change management and support. It separates journey-specific spending from capabilities benefiting several services, such as shared identity management. A comprehensible allocation prevents a central platform appearing free while business teams bear its costs, and avoids charging its whole cost to the first user team.
Effects are measured on comparable cases. Time from sales approval to first invoice is segmented by contract type and entity. Cases stopped for commercial reasons are counted separately. Customer-data rework signals the quality of the CRM–SAP handover. If delay improves only because difficult cases remain outside the new stream, the committee must see it.
Architecture and tests make boundaries tangible
Each exchange has an interface contract: trigger event, business identifier, mandatory fields, controls, expected outcome and error handling. A positive technical response is not business acceptance. If SAP rejects creation, the information returns to an owner who can correct the case rather than creating silent retry loops. Idempotency allows an event to be replayed without creating another customer or invoice.
Tests follow complete journeys and exceptions: creation, permitted modification, refused modification, duplicate, interruption and recovery. The team checks amounts and identifiers in the terminal systems, not merely screenshots of individual applications. Retesting after configuration changes verifies that local improvement has not broken the journey's output. Evidence responsibilities are distributed, but complete acceptance has a signatory.
Value streams do not make all programmes unnecessary. Major ERP replacement, business separation or regulatory deadlines may require strong temporary central leadership. In such cases the stream provides acceptance criteria and an organisation for life after the project. The programme retains overall dependencies, schedule and transition responsibilities. The issue is choosing an organisation that fits risk, not declaring one method universally superior.
In practice: remove a handover
Élodie observes a case with the teams. Procurement requests evidence already present in the contract; finance later requests the same information in another form. The team could automate three transfers. It first determines which control justifies each one. One transfer is removed, another becomes a source-data control and the last remains manual for exceptions. Simplification precedes technical integration.
The sponsor authorises a segmented pilot, an accountable journey owner and a return to the existing procedure. Pilot exit depends on data quality and error handling rather than an arbitrary date. At the next review, Élodie will present completed cases, exceptions and operating costs. Three separate application acceptances will no longer be presented as proof of a new commercial capability.
Variations that genuinely change delivery
Regulated manufacturing must preserve quality approvals and the relationship between changes, batches and approved documentation. Banking control functions and access rights require segregation of duties that does not disappear inside a product team. International groups can share a core data model while retaining local tax rules. These differences determine exceptions, test scope and centralised decisions.
A pragmatic first step is to choose a costly handover, identify affected cases and bring output producers and consumers together. Removing a wait without removing a necessary control is already a result. The organisation can then extend the mandate while retaining the right to stop if coordination cost exceeds the benefit.
Sources, method and limitations
Sources checked on 4 October 2026. The scenario and decisions are educational. These primary documents offer perspectives on user-focused platforms and service measures; they do not demonstrate that value streams universally replace programmes.