Service Value System and Value Chain

A service value system (SVS) describes how an organization's components and activities work together to enable value creation. ITIL 4 uses this name; ITIL Version 5 calls it the ITIL value system. Version 5 was introduced in January 2026, with its Foundation syllabus dated February 2026.

Inputs and output

Demand is consumers' need or desire for products and services. Staff asking for secure remote access express demand. An opportunity is a possibility to add value or improve the organization, such as an unused cloud feature that could reduce costs. The organization decides which opportunities to pursue.

The system's output is value: the benefits, usefulness and importance stakeholders perceive. A completed expense app is a product of work. Managers approving claims in two minutes instead of two days is an outcome that makes the app useful. Finishing the software alone does not establish that people benefit from it.

Value is co-created. The provider contributes technology and support; consumers contribute knowledge, decisions and use. A clear fault report with a screenshot can help an agent restore service sooner.

Five components working together

Version 5 uses value chain and management practices for the corresponding components. These components work together while an activity happens. They are not five stages to complete in order.

The seven guiding principles remain: focus on value; start where you are; progress iteratively with feedback; collaborate and promote visibility; think and work holistically; keep it simple and practical; optimize and automate. They shape choices throughout the system. For example, “start where you are” means checking an existing reset process before replacing it.

Follow a password reset improvement

A bank with 40 branches receives reports of 20-minute phone waits for password resets. That is demand. Its identity platform has an unused self-service reset feature: an opportunity.

Governance checks the idea against security policy. Value chain activities gather staff needs, design and build the reset flow, and put it into use. Service desk, information security management and change enablement practices supply people, knowledge and tools. Continual improvement later checks whether waiting fell. Staff returning to work within a few minutes is the value they experience.

See the whole system

A silo forms when teams work in isolation and share little information. Separate team targets can hide duplicated work or lost information at handovers. A shared view of the path to value helps teams coordinate, and the system allows different routes as demand changes.

The four dimensions are perspectives for examining the whole system: organizations and people, information and technology, partners and suppliers, and value streams and processes. They are different from its five components. The SVS can describe a whole organization or one part of it, in any sector or at any size.

Governance directs and controls an organization. It keeps work aligned with the organization's purpose, strategy and policies. A governing body is the person or group with the highest accountability for performance and compliance: a board, trustees or the owner of a small firm. A committee can prepare a decision, but the governing body retains accountability.

Evaluate, direct and monitor

To classify an action, ask what the decision achieves. Assessing a possible direction is evaluate; establishing direction and responsibility is direct; reviewing performance against it is monitor. The document's name alone is not enough: a report could inform an evaluation or a monitoring decision.

Turn direction into daily decisions

A policy formally records expectations and intentions that guide decisions and activities. For example: “Customer personal data must be stored in approved data centers within the customer's region.” Management then selects and configures centers that meet the policy. The policy provides a shared rule without specifying every technical action.

Governance and management have different jobs. Governance sets direction, approves policies and oversees results. Management plans, organizes and runs the work within that direction, then reports back.

Suppose a board directs that an online store must achieve 99.9% availability. IT management decides how to design, maintain and support the store. It measures availability and reports results to the board. The board monitors those results against its direction; it need not choose each server setting.

Controls can enable quicker work

Clear risk limits let teams make routine decisions confidently. A policy can allow low-risk standard changes to be pre-authorized, while higher-risk changes receive a separate assessment. Teams then know when they can act and when to involve a change authority.

A change authority decides on individual changes as part of management. It is not the governing body simply because it approves work. Adding a committee approval to every change can slow value delivery without improving control. Review whether each control has a useful purpose, applying “keep it simple and practical.”

Apply the same logic to AI

AI governance provides oversight, policies and accountability for safe, lawful, transparent AI use that supports organizational goals. A governing body evaluates a proposed AI service and its risks, directs who is accountable and what policies apply, and monitors performance and compliance. Management implements and runs it within those limits.

Governance also needs continual improvement. The governing body reviews whether its controls remain useful as the organization, technology and risks change. A policy that once supported good decisions may need revision when it starts delaying work without addressing a current risk.

The service value chain is an operating model for creating, delivering and continually improving services. An operating model describes how an organization co-creates value and runs itself. ITIL 4 names six interconnected activities. Each transforms inputs into outputs, and those outputs can become inputs to other activities.

What each activity contributes

Identify work by its purpose

Deciding to fund cloud email next year is plan. Receiving a user's complaint or discussing next year's business needs is engage, the main contact with consumers and other external parties. Analyzing falling satisfaction and agreeing an improvement is improve.

For an online booking service, design and transition defines quality and user requirements and arranges the move into live use. Obtain/build creates and tests software or obtains components from a supplier. Running the service each day and restoring it after an outage is deliver and support.

A useful classification follows what the work achieves. Buying 200 laptops makes components available, so it belongs to obtain/build. Gathering staff feedback about those laptops serves engage. The same people might help with both activities.

Outputs connect the activities

A request captured through engage can become an input to design and transition. A component supplied through obtain/build can move into live use through design and transition. Performance information from deliver and support can show improve where results are weak and help plan set priorities.

These links do not impose one order. A small request can use only the activities it needs. A new service can revisit design and transition after feedback reveals a missing requirement. Improve can work on an existing service while obtain/build develops a new component.

Activities are broader than practices or teams

Each activity draws on several practices, and a practice can support several activities. Service level management helps engage agree customer targets, helps deliver and support assess results, and helps improve identify missed targets. Deliver and support therefore cannot be equated with the service desk.

Reading the six activities as a fixed project sequence hides this flexibility. The model supplies connected kinds of work; a value stream chooses a route through them for the demand being handled.

A value stream is a series of steps for creating and delivering products and services to consumers. It is a practical route through value chain activities. Each step also relies on practices that supply skills, information, tools and processes.

Keep three levels separate

A process often operates inside a practice and contributes to part of a stream. A list of departments tells you who participates, but it does not explain what happens between the trigger and the useful result.

Build a value stream map

1. Name the trigger: the demand or opportunity that starts work.
2. List the actual steps until the consumer receives value.
3. Assign each step to the value chain activity it performs.
4. Add the main practices it needs.
5. Check the ending with the consumer and feed results into improvement.

Trace a restoration

A user reports an error in the sales app. The service desk logs and assesses it: engage, supported by service desk and incident management. Support applies a known workaround so selling can resume: deliver and support, using incident management and knowledge about the workaround.

Developers investigate the cause and write and test a permanent fix: obtain/build, drawing on problem management and software development. Assessing, authorizing and moving the fix into use contributes to design and transition, using change enablement and deployment management.

The team tells the user and checks that the app works: engage, followed by confirmation of deliver and support. Reviewing the trend of similar incidents is improve. The consumer's value is the ability to sell again. Restoration can deliver that value before the permanent fix is finished.

Routes can repeat activities

A mobile expense-approval feature follows another route: engage captures the need; plan sets priority and budget; design and transition defines requirements; obtain/build creates the feature; design and transition moves it into use; deliver and support provides it; engage gathers feedback; improve plans changes. Repeating engage or design and transition is normal. The route follows the work's needs.

Core and enabling streams

In Version 5, a core value stream delivers value to external consumers in the way the operating model intends, such as fulfilling customer orders. An enabling value stream serves internal consumers and supports core streams, such as onboarding employees or suppliers. Both use the same activities. “Enabling” describes whom the stream serves and what it supports; it does not mean the work lacks value.

Mapping makes the value streams and processes dimension visible. It applies “think and work holistically” by showing the whole route, including handovers between teams that may each see only one part.

Value stream mapping examines and shows how work flows so teams can see how value is created and where to improve. Value stream management is the continuing work of managing and improving that flow.

Make delays visible

A current-state map records how work actually happens. Include steps, people, information and artifacts passed between them, active work and waiting. A future-state map shows the improved flow the team aims to achieve. Recording only the official procedure can miss the queues and repeated data entry that explain a consumer's wait.

Lead time is elapsed time from the trigger to delivered value. Active time, or touch time, is time spent working on the item. For a sequential stream with non-overlapping active and waiting periods:

Use the same time unit in numerator and denominator.

Work through a laptop request

Active time is 4 h. Waiting is 48 h, giving a 52 h lead time. Flow efficiency is about 7.7% because only 4 of the 52 elapsed hours involve work on the item.

Pre-approving the standard laptop reduces approval waiting from 16 h to 1 h. Active time stays 4 h; waiting becomes 33 h. Lead time is now 37 h and flow efficiency about 10.8%. The remaining 24 h build-team queue is the next candidate to investigate.

Halving the 2 h configuration task saves only 1 h from the original 52 h: about 1.9%. Reducing the approval wait saved 15 h. Check the whole stream after a change; sending work faster into another queue may leave total lead time unchanged.

Match improvement to the kind of work

Complexity thinking helps choose a way of working.

• Ordered work is predictable. Standard laptop requests can use agreed steps and automation.
• Complex work has cause and effect that become clear afterward. Developing an unfamiliar digital product calls for small experiments and quick feedback.
• Chaotic situations need stabilization first. During a major outage with an unknown cause, restore enough control for useful analysis afterward.

Treating uncertain work as a fully known procedure can lock in a poor solution. Treating every routine request as an experiment wastes effort. Choose an approach that fits the situation, then use observed results to adapt it.

Value stream management uses the map and measures to improve the practices behind the flow, remove unneeded approvals and repeated entry, and reassess the route when demand changes. Each proposed change can use the continual improvement model to establish a baseline, act and check results.

Digital product and service management manages products and services that depend on digital technology, from an idea through retirement. A digital product is built mainly from software, data and digital infrastructure, such as a mobile banking app. A digital service gives consumers access to what products can do, such as online payments.

The Version 5 lifecycle

The ITIL product and service lifecycle names eight activities: discover, design, acquire, build, transition, operate, deliver and support. The first four mainly create and change products; the last four mainly run products and provide services from them. Transition introduces new or changed products into live use.

From an organizational perspective, these activities form the Version 5 value chain. A value stream combines them with management practices for a particular kind of demand. The lifecycle describes work needed over a product's life; a stream describes a particular route through that work.

The value system remains the wider system with its five components. The lifecycle does not replace governance, guiding principles, practices or continual improvement.

Use activities together

The lifecycle is not a single linear sequence. Discovery can continue while developers build a release. Support feedback can lead directly to design. A product released every two weeks can revisit design, build and transition while the existing service continues to operate and serve users.

A city council launches an app for reporting broken streetlights. Support notices reports arriving without locations. Discover investigates why, design adds an automatic map pin, and build and transition implement and introduce it. Operate and deliver keep the existing app available during this work. The product is involved in several activities at the same time.

Relate Version 5 to ITIL 4

The following is a broad comparison of the work, not an exact equivalence of activities.

The versions group work differently, so a real stream needs its activities considered on their own purposes. Operate keeps technology healthy; deliver provides the service and handles ordinary user needs. They contribute to the same result through different work.

Measure activity results

Useful example measures include tested consumer need behind roadmap items for discover, automated test pass rates for build, and changes deployed without incidents for transition. Operate can track availability, deliver can track request fulfillment time and user satisfaction, and support can track restoration time.

These measures help locate weak points in a stream. A high build test pass rate can coexist with slow request fulfillment: success in one activity does not show whether the consumer receives a useful service on time.

Creating a useful digital product means understanding a need, shaping a solution, obtaining resources and making the solution work. Version 5 names this work discover, design, acquire and build. Feedback can move work between these activities before a full product exists.

Discover a need worth serving

Discover explores consumer needs, technology and market opportunities, and organizational strategy. It helps decide which products and services to offer or change and keeps the roadmap aligned with those needs and opportunities. A roadmap gives direction for planned product development; it needs revision when evidence changes.

For a clinic, research shows patients want to book appointments online. The clinic adds online booking to its roadmap. The useful discovery is the patient's need and the service it could support, not simply that a new application can be built.

Design the whole solution

Design turns needs into specifications and prototypes. A product specification describes required features, quality levels and constraints. A prototype is an early simplified version used to test an idea with users before full construction.

The clinic's specification requires patients to book, move or cancel an appointment within three screens, use the system outside office hours, and receive reminders 24 hours before a visit. Each requirement describes behavior or quality the eventual solution can be checked against.

Ten patients try a clickable prototype. Four cannot find the cancel button. The team changes the design before writing the full software. A prototype is for learning; it may be discarded after it answers its question. Treating it as nearly finished software can cause a team to keep a weak design simply because something already exists.

Design also covers how the product will be operated and supported. Monitoring, backups and help for users need a place in the solution. Discovering those needs after launch can require more costly changes. This applies “think and work holistically” to the product's whole life.

Acquire resources

Acquire obtains or allocates the resources the solution needs. It includes cloud capacity, licenses, devices, data and people with suitable skills. Resources may come from suppliers or from inside the organization. Reusing an existing component or assigning an internal specialist is acquisition work too.

The clinic contracts with a text-message provider for reminders. It also allocates internal staff to support the booking system. Buying is one way to acquire resources; it is not the full meaning of the activity.

Build and check the working solution

Build develops, integrates and tests components to turn the design into a working solution. A test checks whether a component or product meets requirements and behaves as expected. Testing the reminder feature includes checking the specified timing, not merely confirming that a message can be sent.

With continuous integration, developers merge changes into a shared code base frequently, and automated builds and tests check those changes. This gives early feedback on integration failures and defects that the tests can detect. Passing those tests does not establish that every defect has been found; the result depends on what was tested.

The clinic can revise its design after a prototype test, acquire a different resource after a build test, or discover a new need while the product is being built.

A working digital product needs to enter live use, stay healthy and provide a useful service. Users also need help when service fails. Version 5 separates this work into transition, operate, deliver and support.

Transition into live use

Transition introduces new or changed products and services, including release, deployment and supplier onboarding or offboarding. Deployment moves components into an environment. Release makes a version or set of components available for use. Software can be installed in production with a feature switched off, so deployment and release need not happen together.

Continuous delivery keeps tested changes ready to deploy, with a person deciding when. Continuous deployment moves every change that passes automated tests into the live environment without a manual decision. Neither term means that users necessarily receive a new feature every time components move.

Operate reliable technology

Operate runs, maintains and monitors products to agreed performance and reliability. Reliability is the ability to perform required functions as expected over time. Observability means understanding internal system state from outputs such as logs, metrics and traces. Site reliability engineering (SRE) applies software engineering to operations, including automation and measurable reliability targets.

An event is a change of state significant to managing a service or configuration item. A backup completing is an event; so is disk use reaching 90%. Many events need recording only. Others warn that intervention could prevent an incident.

For a booking service available 99.9% of a whole 30-day month, total time is 43,200 minutes. Allowed downtime is 0.1% of that: 43.2 minutes. With 43 minutes down, availability is about 99.90%, just meeting the target. Compare unrounded values before deciding whether a close result meets a target.

Deliver ordinary service actions

Deliver provides services day to day, onboards and offboards users, fulfills requests and gathers feedback. A service request asks for an agreed normal service action, such as access to a shared folder or a new laptop. The authorized user or representative initiates the request.

Support when service goes wrong

Support restores normal operation and reduces future failures through incident resolution, disaster recovery and problem management. An incident is an unplanned interruption or quality reduction. A disaster causes serious loss or damage, such as a fire destroying a data center.

A problem is an actual or potential cause of incidents. An error is a flaw or vulnerability that may cause them. A known error is an analyzed problem that remains unresolved.

Suppose 30 people cannot print after a faulty driver update. Their service failures are incidents. The faulty update is the problem; once analyzed but still unfixed, the problem is a known error. Rolling the driver back can restore printing while the permanent fix is pending. Restoration therefore does not mean that the cause has been removed.

“I need access to the sales folder” is a request. “The sales folder will not open” reports an incident. Identify whether the user seeks a normal action or the restoration of something that has failed.

A practice is a set of organizational resources designed to perform work or achieve an objective. Version 5 calls it a management practice. A practice spans all four dimensions, including people and skills, information and technology, partners and suppliers, and value streams and processes.

A practice is broader than a process or department. Incident management may contain logging and diagnosis processes, a knowledge base, monitoring tools and people from a service desk, network team and supplier. Those resources together create the capability to restore service.

Two ways to group the 34 practices

Version 5 keeps the 34 practice names. Deployment management, infrastructure and platform management, and software development and management move from the technical group into product and service management. Information security management and service financial management also join that group, moving from general management.

Version 5 general management practices

The 12 practices are architecture management; continual improvement; knowledge management; measurement and reporting; organizational change management; portfolio management; project management; relationship management; risk management; strategy management; supplier management; and workforce and talent management.

These capabilities support how the organization is managed. For example, measurement and reporting supplies reliable information for improvement decisions. Continual improvement helps keep practices and services aligned with changing needs.

Version 5 product and service management practices

The 22 are availability management; business analysis; capacity and performance management; change enablement; deployment management; incident management; information security management; infrastructure and platform management; IT asset management; monitoring and event management; problem management; release management; service catalog management; service configuration management; service continuity management; service design; service desk; service financial management; service level management; service request management; service validation and testing; and software development and management.

Connect capabilities to a stream

A laptop request draws on service request management to handle the agreed action, IT asset management to track the device, deployment management to install software, and the service desk to contact the user. One value chain activity can need all these practices. The service desk can also contribute to several activities by receiving demand, updating users and gathering feedback.

Do not turn each practice into a separate team by default. Organizations adopt and adapt what they need, combine resources where useful and build capabilities gradually. A small organization may rely on the same people for several practices while keeping each purpose clear.

Use practice guides as a starting point

Official practice guides describe the practices. ITIL 4 guides cover purpose, key terms, scope, success factors and the four dimensions, including contributing processes and value streams. They provide shared language and a starting point to adapt. Following “start where you are” and “keep it simple and practical” means fitting that guidance to the organization's actual work.

When users contact a provider, several practices may contribute. Their purposes help separate contact, ordinary requests, restoration, investigation and agreement about service quality.

Contact, restoration and causes

The service desk can use phone, chat, a portal, email or walk-in contact. It is the contact point, while incident management is the capability for restoration. Other technical teams and suppliers may perform much of that restoration.

Incident management can restore service through a workaround before the cause is known. Problem management can continue after restoration, or investigate a weakness before any incident occurs. Repeated incidents are useful evidence, but repetition is not required for a problem to exist.

A predefined password reset through a portal is a service request. A user's unexpected inability to access a working service can be an incident. Look at the need and the agreed service action, not only the word “password.”

Agree quality and maintain relationships

Service level management establishes clear business-based service targets and assesses, monitors and manages delivery against them. A service level agreement (SLA) documents the required services and expected service level agreed between provider and customer. A response-time target is useful when it reflects what the customer's work needs.

Relationship management develops relationships with stakeholders at strategic and tactical levels. It helps understand needs and business impact beyond one contact about one fault. Discussing the effect of a poor service with a department director can inform future priorities.

Monitoring and event management observes services and components and records and reports selected significant state changes. A threshold alert supplies information that can trigger investigation or action; the practice does not replace the work of restoring a failed service.

Follow a payroll slowdown

On payday, monitoring raises an alert that payroll response time has crossed its threshold. The service desk receives users' calls. Incident management adds server capacity to restore normal speed. Problem management later identifies a faulty database index as the cause.

Service level management reports the response-time target breach to the customer. Relationship management discusses its business impact with the finance director. Each contribution has a different purpose even if the same manager attends several of the discussions.

If users can work again after capacity is added, the incident can end while the problem remains open. Keeping that distinction visible stops a successful restoration from hiding unresolved causes that could affect the next payday.

A new service feature needs more than installation. Risks must be assessed, users need access at the right time, and the organization needs reliable information about components, costs and suppliers. These contributions come from different practices.

Introduce successful changes

Change enablement aims to maximize successful product and service changes through risk assessment, authorization and management of the change schedule. A change adds, modifies or removes anything that could affect services directly or indirectly. The original ITIL 4 Foundation book called this practice change control.

The aim is successful change, not the largest possible number of approval meetings. Low-risk standard changes can be pre-authorized. The authority and assessment fit the change's risk and context.

A feature can be deployed with its switch off. Releasing it later makes it available to users. This distinction explains why “installed successfully” does not always mean “users can use it.”

Know the components and their value

Service configuration management provides accurate, reliable information about services and the configuration items that support them, where and when it is needed. A configuration item (CI) is a component that needs management to deliver an IT service. Configuration information includes settings and relationships, such as which application depends on which database.

IT asset management plans and manages the full lifecycle of financially valuable IT components. It supports value, costs, risks, purchasing, reuse, retirement and regulatory or contractual requirements. An IT asset can be a laptop or a software license.

One laptop can be both an asset and a CI. The asset view asks about value and lifecycle; the configuration view asks how it is set up and connected to deliver service. Keeping one record accurate does not remove the need for the other view.

Protect information and supplier performance

Information security management protects the information needed for business. Confidentiality limits access to authorized people; integrity keeps information accurate and complete; availability keeps it usable when needed.

Supplier management manages suppliers and their performance so they support smooth provision of quality products and services. Continual improvement aligns products, services, practices and other management elements with changing business needs through ongoing improvement.

Roll out a remote-access client

For 1,500 staff, change enablement assesses risk and schedules the rollout. Deployment management installs the client on test devices and then staff laptops. Release management enables use in waves.

Service configuration management records device versions and relationships. IT asset management tracks licenses. Information security management checks encryption settings, and supplier management holds the vendor to its support contract. Continual improvement can use rollout results to improve the next change. The stream succeeds through these combined capabilities; no single practice supplies every contribution.

Continual improvement is recurring work at every level to keep performance meeting stakeholder expectations. It is a component of the value system, an ITIL 4 value chain activity called improve, and a practice. Everyone shares responsibility for identifying and supporting improvement.

The continual improvement model provides seven connected steps. It can guide a small team change, one value stream or an organization-wide transformation. A large change usually needs several smaller iterations.

What to do at each step

Version 5 keeps seven steps but calls step 6 “Are we getting there?” and step 7 “How do we keep the improvements relevant?” The wording emphasizes ongoing progress and continued usefulness.

Follow a service desk improvement

Vision: staff should be able to work without long interruptions. Current position: the desk resolves 1,392 of 2,400 monthly contacts at first contact. Dividing resolutions by contacts gives a baseline of 58%.

Desired position: reach 70% within six months. At the baseline volume this would mean 1,680 contacts resolved at first contact. The target is the proportion, so the required count will change if volume changes.

Plan: build a knowledge base for the 20 most common fixes in monthly iterations. Action: publish the articles and train agents to use them.

Check: after six months, 1,620 of 2,500 contacts are resolved at first contact. The result is 64.8%: above 58%, below 70%. The desk has improved but has not met the target. At the new volume, 70% would require 1,750 first-contact resolutions.

Continue: share the results, keep the articles current and investigate the remaining gap. Feedback can send the team back to step 4 to change the plan, or to step 3 if the target needs revision. A target missed is information for the next decision.

Keep the starting point visible

Skipping the baseline removes the comparison needed to judge change. A result of 64.8% shows progress here because the team measured 58% before acting. Starting with “buy a new tool” also jumps ahead: it selects a solution before agreeing the outcome and target.

The guiding principles support the steps. “Focus on value” guides the vision; “start where you are” guides the baseline; “progress iteratively with feedback” guides planning, action and checking. “Collaborate and promote visibility” involves affected people and makes progress visible throughout.

A metric is a measurement or calculation monitored or reported for management and improvement. A key performance indicator (KPI) is an important metric used to judge progress toward an objective. A critical success factor (CSF) states something that must be true to achieve the intended results.

Connect the objective to evidence

Start with the objective, identify the CSFs needed to achieve it, then choose two or three reliable KPIs for each. Record a baseline before acting, set each target and date, and report results to the people who decide what to do next.

For the CSF “users can solve common problems without waiting for an agent,” useful KPIs include the share of common issues resolved through self-service and the share of password resets completed through self-service. First-contact resolution does not measure the same thing: an agent can resolve a contact, so it does not show independent user resolution.

A metric becomes a KPI through its link to the objective. Not every available count deserves equal attention. Measurement and reporting, a general management practice, provides reliable data to support these decisions.

Choose the right denominator

The service desk's first-contact resolutions rose from 1,392 to 1,620, an increase of 228. However, contacts also rose from 2,400 to 2,500. The proportions are:

The change is 6.8 percentage points. Reporting both count and percentage separates the workload from the share successfully handled at first contact. To reach 70% at the new volume requires 1,750 resolutions.

Use a percentage when the objective is about a share. Counts, durations and costs are also valid KPI forms when the objective concerns them. For example, an objective to shorten a wait needs a time measure.

Measure outcomes and unintended effects

“Number of knowledge articles published” measures an output. The share of contacts resolved at first contact and user satisfaction are closer to the outcome people value. Publishing 200 articles that nobody uses would meet a production count without helping users.

Combine outcome or value measures with speed and cost measures. A single target can encourage behavior that improves the number while harming service. If agents are judged only on first-contact resolution, they may close contacts too early. Tracking the share of incidents reopened within seven days helps expose that effect.

Keep ideas and ownership visible

A continual improvement register (CIR) is a structured document or database that tracks improvement ideas until completion or rejection. Entries include a description, owner, priority, expected benefit and status. A shared register avoids duplicated effort and helps compare potential benefits when deciding what to do first.

Governance monitors performance against strategy. Managers own improvements to practices and value streams. Every team member can raise an idea in the register. Assigning an owner keeps responsibility clear while allowing ideas to come from anywhere in the organization.