Chapter 4 of 4

Value Capture and Continuous Improvement

Learning objectives

  • Build a value-capture plan that converts run-rate savings into reported P&L benefit.
  • Compute the steady-state benefit and the time-to-steady-state of a multi-phase program.
  • Hand the chain a continuous-improvement rhythm that outlasts the transformation office.

Value Capture versus Value Identification

Value capture is the discipline of ensuring that identified savings actually hit the P&L. A common failure is to count savings when a project closes, then lose them because the new process is not enforced. Savings evaporate when expedites return, when safety stock is re-introduced, when the SKU rationalization is undone by sales. Value capture requires three things. First, a savings-tracker that ties each saving to a specific operational metric (e.g., expedite freight per week, fill rate per quarter, E&O inventory per month). Second, an owner for each metric with explicit accountability. Third, a recurring review that asks 'is this metric still trending in the right direction?' The discipline is to treat savings like a product with a lifecycle, not like a one-time event. Many transformations over-claim savings in year 1 and under-report them in year 3 because the value-capture discipline fades. A value-capture plan is the difference between a transformation that delivered and one that delivered-then-drifted.

Time to Steady State

Multi-year transformations rarely hit steady-state savings at go-live. The realistic pattern is a ramp: phase 1 delivers a fraction of plan within 6 months, phase 2 adds more within 12–18 months, and steady state is reached around month 24–36. The reason is that adoption takes time, tooling takes time to tune, and supplier behavior changes take time. Reporting savings as if steady state is reached at go-live overstates the early benefit; reporting only the early benefit understates the eventual benefit. The right discipline is to publish a phased savings curve alongside the steady-state number, and to track actuals against the curve. Investors and boards understand phased curves; they do not understand a number that swings wildly between forecast and actual. A useful template: 30% of plan by month 6, 60% by month 12, 85% by month 18, 100% by month 24, with milestones tied to adoption metrics. This sets expectations honestly and provides an early warning when adoption lags.

Continuous Improvement That Outlasts the Program

A transformation that solves the current pain and stops is a transformation that creates the next pain. The supply chain after the program is not the same as the supply chain before; demand changes, product mix changes, supplier base changes, and the target operating model has to be re-tuned. Continuous improvement is the discipline that absorbs those re-tunings without spinning up a new program every three years. The right structure is a small standing team with a clear mandate to re-baseline the target operating model annually, sponsor incremental improvement projects (forecast accuracy, supplier development, footprint optimization), and publish the metrics. The team should be small and senior; a large team creates the same overhead as the original transformation, which defeats the purpose. Continuous improvement is the steady-state after the program, not a permanent project. The most successful transformations hand the chain a rhythm of improvement, not a one-time fix.

Worked example

Problem

A transformation has planned run-rate savings of $3.0M/year by month 24, with a phased ramp: 30% by month 6, 60% by month 12, 85% by month 18, 100% by month 24. Compute cumulative cash benefit and cumulative program cost by month 24, assuming program cost is $1.5M spread evenly over 24 months ($0.0625M/month) plus a $0.4M one-time at month 18 for re-tuning. Confirm the steady-state monthly run-rate and the payback month.

Step by step

  1. Monthly run-rate savings: month 6 = 30% × $3.0M / 12 = $0.075M/month. Month 12 = 60% × $3.0M / 12 = $0.150M/month. Month 18 = 85% × $3.0M / 12 = $0.2125M/month. Month 24 = 100% × $3.0M / 12 = $0.250M/month.
  2. Cumulative savings (linear interpolation per phase): months 1–6 ≈ $0.075M × 3 (avg) = $0.225M. Months 7–12 ≈ ($0.075 + $0.150)/2 × 6 = $0.675M. Months 13–18 ≈ ($0.150 + $0.2125)/2 × 6 = $1.0875M. Months 19–24 ≈ ($0.2125 + $0.250)/2 × 6 = $1.3875M. Total cumulative at month 24 ≈ $3.375M.
  3. Cumulative program cost at month 24 = ($0.0625M × 24) + $0.4M = $1.5M + $0.4M = $1.9M.
  4. Net benefit at month 24 = $3.375M − $1.9M = $1.475M.
  5. Payback must compare cumulative benefit with cumulative cost as each accrues, not with the final total. Cost accrues at $0.0625M/month and the $0.4M re-tuning lands only at month 18, so cumulative cost is $0.375M at month 6, $0.750M at month 12, and $1.125M just before month 18.
  6. Walk the months where the crossover sits. Monthly savings in months 7 to 12 run $0.0875M, $0.100M, $0.1125M, $0.125M, $0.1375M, $0.150M. Cumulative benefit reaches $0.525M by month 9 against $0.5625M of cost, still short; by month 10 it is $0.650M against $0.625M, ahead. Payback is month 10.
  7. The $0.4M at month 18 pushes cumulative cost to $1.525M against $1.9875M of benefit, so the program stays cash-positive through the re-tuning rather than dipping back below the line.
  8. Steady-state monthly run-rate = $0.250M, or $3.0M annually.

Answer. Cumulative cash benefit at month 24 ≈ $3.375M against ≈ $1.9M of cumulative program cost, for a net of ≈ $1.475M. Payback occurs around month 10, not around month 17 as it appears if the final $1.9M total is compared against the benefit curve; program spend accrues gradually and the $0.4M re-tuning has not been incurred yet at the crossover point. Comparing a running benefit against a final cost is a common way to make a program look worse than it is, just as comparing run-rate against cash makes one look better. Steady-state run-rate is $3.0M/year. Limitation: the linear ramp between milestones is a modelling convenience; adoption in practice is lumpy, so re-plot the curve against actuals each month and treat a missed milestone as a schedule change rather than smoothing it away.

Practice

Work each question before opening the solution.

  1. What is the difference between value identification and value capture?

    Show solution for question 1

    Value identification is finding savings in the diagnostic and design phases. Value capture is ensuring the savings actually show up in the P&L over time, with an owner and a metric per saving. Many transformations over-identify and under-capture.

  2. Why publish a phased savings curve rather than a single steady-state number?

    Show solution for question 2

    Because multi-year transformations ramp; reporting only steady-state overstates early benefit, while reporting only early benefit understates eventual benefit. A phased curve sets realistic expectations and provides an early warning when adoption lags.

  3. What is the right size and structure of a continuous-improvement team after the transformation ends?

    Show solution for question 3

    Small and senior, with a clear mandate to re-baseline the operating model annually and sponsor incremental projects. A large team recreates the overhead of the original program and defeats the purpose of transitioning to steady-state.