Smart Factory Business Case on SAP: Where to Start and How to Prove It

Benchmarks are ceilings. Your baseline decides.

Altivate | Published 5 November 2026

Contents

1. Executive summary: what to decide this quarter
2. Why programmes stall at “where first”
3. What counts as a use case
4. Scoring: which use case, plant and line first
5. Baseline: what to measure before claiming anything
6. The business case: payback and NPV from your own numbers
7. Full cost: technology, process debt, adoption and run cost
8. Worked examples: a Gulf process plant and a discrete line
9. Roadmap: pilot, prove and scale on SAP, with gates
10. Gulf considerations
11. Run the model
12. Sources and verification status

1. Executive summary: what to decide this quarter

The question: What do I have to decide this quarter, and what will I have at the end of it?

You do not need a smart-factory vision this quarter. You need one decision: which use case, on which plant or line, goes first, and what result would fund the next step.

The best-documented transformations do not spend most of their money on technology. In the World Economic Forum’s Global Lighthouse Network paper of January 2025, for every $2 spent on tech innovation, Lighthouses spend $3 on process debt reduction and $5 on scale and adoption. These are self-reported, best-in-class sites: read the ratio as a warning, not a forecast.

What to decide, in order:

• Pick the first pairing by score, not by enthusiasm. A pairing is one use case on one plant or line. The first pick by score is not always the first to fund.
• Prove it in your own numbers. Build the payback and NPV from a baseline that operations and finance both sign. Use benchmarks only to bound the range.
• Price the whole cost. Technology, process debt, adoption and run cost, each on its own line.
• Fund the scale-up only through gates agreed before the pilot starts: stop, extend or scale.

You leave with a ranked shortlist, a first-pass case you can rebuild in the free model, and a gated roadmap on SAP.

2. Why programmes stall at “where first”

The question: Why do smart-factory programmes stall, and what does that tell me about where to start?

Most plants do not stall because the technology fails. They stall because nobody can say which problem the first project is meant to solve, on which line, in which number, and what the number has to reach before more money follows.

The published evidence is consistent with that pattern without proving its cause. In Rockwell Automation’s eleventh State of Smart Manufacturing report, a vendor survey of more than 1,500 manufacturers in 17 countries published in May 2026, 59% of manufacturers report actively using smart-manufacturing technologies to support operations, while 18% remain in pilot mode. It is a vendor-run survey, and we do not combine it with any other survey. Staying in pilot mode is common enough to plan against.

The WEF network paper draws on 189 Lighthouses in 33 countries and 35 subsectors, and more than 1,000 use cases. Lighthouse sites report that those following the network’s playbook achieve ROI of 2-3x over three years and 4-5x over five years. The paper does not define the ROI basis, and the population is self-selected for success: evidence that scaling is possible, never the return to expect.

Three causes of the stall each have a fix in this paper. The first use case was chosen by enthusiasm; the fix is scoring. The benefit was never in a number finance accepts; the fix is a measured baseline and a case built from it. The next step was never priced: process debt and adoption appear only at scale-up; the fix is full cost and gates that test for them before the money moves.

3. What counts as a use case

The question: Which kinds of use case should be on my candidate list, and how do I compare unlike things?

For a business case, a use case is a change in how a line or asset is run that moves a number you already track. Six families cover almost every candidate a Gulf process plant or discrete line will put forward. AI is one of them, used inside a family, not a family of its own.

Read the right-hand column carefully, because each range is labelled with exactly what it is:

• Maintenance. The Deloitte Analytics Institute’s 2017 position paper on predictive maintenance says internal Deloitte analyses found overall maintenance costs are reduced by 5 to 10%, with equipment uptime up 10 to 20% and maintenance planning time down 20 to 50%. No sample is disclosed and the figures are from 2017. We use only the maintenance-cost range, and the base case uses its low end. We do not stack the uptime figure on top of the cost figure for the same use case, which would count one improvement twice.
• Energy. Researchers at Lawrence Berkeley National Laboratory, using verified data on 83 manufacturing facilities, found that ISO 50001-certified facilities achieve annual energy performance improvement rates of around 4.1% in the initial year and maintain around 3.4% twelve years after implementation. That is the result of an energy management system, not of any smart-factory technology and not of SAP. It is a fair check on an energy case: if your projected gain is far above it, ask what you are doing that a well-run management system does not.
• Changeover. One peer-reviewed study in three garment factories found a 50% to 64% reduction in changeover time with SMED (single-minute exchange of die), a lean method. It is one study, in labour-intensive discrete plants, and it measures a method rather than a digital tool. It applies to discrete lines only, and a shorter changeover is worth money only where the line is capacity-constrained. If the line has spare hours, the saved minutes are not cash.

Process plants. Advanced process control and setpoint optimisation are not a seventh family here; they sit inside two of the six:

• Inside quality: throughput and yield against rated output, and soft sensors such as clinker free lime.
• Inside energy: specific heat and power (kcal/kg clinker, kWh/t) and the alternative-fuel substitution rate.

There is no verified range for either; size it from your baseline. Typical first candidates differ by sector: kiln and mill drives in cement, rotating-equipment maintenance and yield in chemicals, pot-life and anode monitoring in aluminium.

For OEE and downtime, quality and material flow there is no independent benchmark we could verify; size it from your own baseline. That is not a gap in this paper; it is the honest state of the published evidence, and it is why the model asks for your numbers rather than offering defaults.

Several figures are often quoted for these families and we do not use them as ranges. WEF Lighthouse sites report an average reduction of 30% in material waste and 25% in energy and water consumption, and a 25-50% reduction in inventory with 15-30% improvements to on-time delivery. For the top AI-enabled use cases of the 2024 cohorts, Lighthouse sites report improvements of more than 50% in conversion costs, cycle times and defect rates. These are best-in-class ceilings, the inventory figure is a supply-chain result rather than shop-floor material flow, and the AI figure is a floor across three different metrics, not a range for any one of them. One Lighthouse site, Unilever Tinsukia in India, reports average changeover time reduced by 85%; one site is a proof of possibility, not a range.

Where does AI sit? Inside the maintenance and quality families, mostly: a model that predicts a failure or a defect, or classifies an image as good or bad. Score it like any other candidate. If an AI pairing wins on value but loses on data readiness, it should not go first, however interesting it is. For the control and safety questions that come with AI close to the process, see AI on the Factory Floor; this paper deals only with whether it earns its place in the queue.

If your team needs a shared definition before it starts, our article on what a smart factory is and how it works covers the vocabulary. The rest of this paper assumes it and moves on to the choice.

4. Scoring: which use case, plant and line first

The question: How do I choose the first pairing in a way my team can defend and my CFO can check?

Score pairings, not use cases. “Predictive maintenance” is not a candidate; “predictive maintenance on kiln line 1” is. The same use case can be right on one line and wrong on another, because the data, the systems and the people differ. List up to twelve pairings and score every one on the same five criteria. This scoring is Altivate’s method, not research: a structured way to make a choice explicit, not a validated predictor of success.

Pre-screen first. Before scoring, screen each pairing pass or fail on safety and process safety, including any management-of-change impact. A fail is not scored, so a high value score can never trade safety away. Then check three things that decide timing and effort: whether the work needs a planned shutdown and when the next one is, whether OT security will approve the connection, and whether the site has the capacity, with no turnaround or ERP cutover inside the pilot window and a named sponsor.

The five criteria. Every score runs from 1 to 5, and 5 is always the good end.

• Value (5 = most value). From this pairing’s own baseline: how much cost or lost margin it addresses on this line, at a conservative rate. Never from a benchmark headline.
• Data readiness (5 = the data exists and can be trusted today). Per site. A sensor whose readings nobody trusts scores low.
• SAP fit (5 = best fit with your SAP landscape). Per site. Does the pairing use records SAP already holds, such as production or process orders, confirmations, maintenance history or inspection results, and can the result post back where finance will see it?
• Effort (5 = least effort). Per pairing: integration, process change, training and equipment work before the first measured result.
• Risk (5 = lowest risk). Per pairing: product quality, disruption during the pilot, and the risk that the benefit cannot be measured cleanly.

The default weights are value 30, data readiness 25, SAP fit 15, effort 15 and risk 15. A valuable pairing whose data you cannot trust will not produce a result you can prove. Change the weights before you score, not after you see the ranking. The tie-break is data readiness. Note which pairings would replicate across sister lines or sites; a COO’s programme value depends on it.

How to run it. Put operations, maintenance or reliability, quality, HSE, the finance controller who will sign the baseline and the site’s SAP landscape owner in the room. Score independently, then compare; where scores differ by two points or more, ask for the evidence.

What scoring cannot do. It cannot size the benefit, only choose which pairing to size first. The first pick by score still has to fund: the worked examples show one that does not. The Value score rates the size of the prize before scoping; the business case tests whether the first pilot can capture it. That is why the top-scoring pick is not always the first to fund.

5. Baseline: what to measure before claiming anything

The question: What do I need to measure before anyone claims a benefit, and where does the data come from?

The baseline is the current value of each number the pairing is meant to move, measured the same way it will be measured after the pilot. Operations and finance should both sign it. If they cannot agree on the baseline, they will not agree on the benefit. Measure only what the top pairing needs:

OEE inputs (discrete and batch lines). Record availability, performance and quality separately. Before baselining, write down three definitions: planned production time, which planned stops are excluded, and the ideal rate (nameplate or demonstrated). Changing any of them later moves OEE without the line changing. SAP Digital Manufacturing calculates OEE as Availability x Performance x Quality, and SAP documents caveats that matter: with no shift configured the shift duration is taken as 24 hours, only one shift interval is considered, hold and resume and sign-off are not considered, SFCs on hold are treated as active until the operation completes, which affects Performance, and day overrides and shift-calendar rules are ignored; SAP recommends a continuous shift without gaps or overlaps. For how those inputs travel between the shop floor and SAP S/4HANA, see SAP Digital Manufacturing and S/4HANA: A Plant Leader’s Guide to the Shop-Floor Data Loop.

Process measures (continuous plants). Continuous plants do not run on OEE. Use run factor or kiln operating hours, MTBF and MTTR, output against rated (t/h), specific heat (kcal/kg clinker) and specific power (kWh/t).

Downtime cost. On a capacity-constrained line, an hour lost is worth the margin not earned. Otherwise lost hours can often be recovered, and a stop costs what it consumes: on a continuous process, restart fuel, refractory or wear damage, off-spec product on heat-up and call-out premiums. Say which case applies, and why.

Scrap and rework cost. Scrap and its cost where it occurs, plus rework labour and capacity. If scrap is confirmed in SAP against orders, reconcile that record with the shift reports once, before the pilot.

Maintenance cost. Spend on the pairing’s assets only, split into planned, corrective, contractor and wear or refractory work. Exclude the wear and refractory line from a condition monitoring case: it follows campaigns and tonnage, not condition. Under fixed-price maintenance contracts, a saving is bankable only at renewal.

Energy. Energy cost and consumption for the pairing’s scope, normalised for production volume and mix and for seasonal ambient temperature, so that a quiet or cool month does not look like a saving.

Labour. Hours on the activity the pairing changes: inspection, setup, data collection.

Three rules keep the baseline honest: the same scope before and after; enough history to see normal variation in mix, demand and season; and one named owner who measures the pilot result the same way. If a number cannot be measured from data you hold, the pairing’s data readiness score was too high.

6. The business case: payback and NPV from your own numbers

The question: How do I turn the baseline into a payback, NPV and IRR that a CFO will accept, and how much should I trust benchmarks?

The model builds the case in the order a CFO will check it: benefit drivers, costs, cash flow, then the results. Each step is a live formula.

Benefit drivers. Each driver is one baseline number times one percentage change. Keep drivers separate, and name each one’s asset and loss mechanism: two drivers that share one, such as “fewer stops” and “higher uptime” on the same asset, count it twice and must be reconciled. Each driver has three percentages:

• Base. Where a verified benchmark exists, its low end; otherwise your own stated assumption. The low end of a published range is itself a ceiling for a first pilot, which is why the model discloses breakeven.
• Low. Half of the base for every driver: a downside case, not a benchmark.
• High. The top of the verified range, or your own stated upside.

Costs. One-off costs fall in year 0: technology, process debt, adoption, internal staff time and a contingency percentage on all four. Run cost, including every subscription, applies every year from year 1.

Timing. The model applies a year-1 benefit realisation percentage, by default half of the full annual benefit; set it lower for a pilot that must run a full maintenance cycle. From year 2 the full benefit applies.

The basis, stated once. Cash flows are pre-tax and in today’s prices; payback is simple (undiscounted). The 10% default discount rate is a placeholder: replace it with your company’s pre-tax real hurdle. The model does not model tax, inflation or residual value.

The results.

• NPV discounts each year’s net cash flow at the hurdle rate and adds the year-0 cost.
• Payback is the point where cumulative cash flow turns non-negative, interpolated within that year; otherwise “Not within horizon”.
• IRR is the rate at which NPV is zero; the model shows n/a when the cash flows never add up to a gain.
• Breakeven (% of base benefit) is the share of the Base benefit at which NPV is zero at the hurdle. It is the number the pilot gate tests.

How far to trust a benchmark. Each number stands on a rung of a ladder:

1. Your own measured baseline and pilot result. The only number that proves anything.
2. Peer-reviewed, multi-site research, such as the ISO 50001 energy study. Bounds a range.
3. A single study, such as the SMED changeover study. Shows a method can work.
4. Dated consultancy analyses without a disclosed sample, such as the Deloitte 2017 maintenance figures. Low end, if at all.
5. Self-reported results from best-in-class sites, such as WEF Lighthouses. Ceilings, not expectations.
6. Vendor surveys. Adoption context, never a source of benefit.

A case resting mostly on rungs five and six is a hope. A case built on rung one, with rungs two to four as checks, is one a CFO can approve.

Sensitivity. The model shows NPV with each driver, the upfront cost and the run cost 20% lower and higher, then with year-1 realisation at 0%, the discount rate 5 points lower and higher, and a horizon one year shorter. The largest 20% swing names the most sensitive driver: measure it first. If NPV turns negative on a 20% change in one assumption you cannot yet measure, the case is fragile.

For the broader capital-case discipline, see The SAP Implementation Business Case. For an AI-specific case built on workflow economics, see The AI Agent Business Case.

7. Full cost: technology, process debt, adoption and run cost

The question: What does the first pairing really cost, including the parts that are not technology?

The ratio in the executive summary is the reason this section exists. For every $2 spent on tech innovation, Lighthouses spend $3 on process debt reduction and $5 on scale and adoption, so technology is two parts in ten. Use that ratio as a check, not a target. If technology is most of your one-off cost, ask which process and adoption work has been left out.

Technology (one-off). Sensors and edge hardware where needed, integration build and testing for the pairing’s own loop, and implementation services. Subscriptions are not here: all of them, including the pilot’s, sit in run cost from year 1, so year 1 is not charged twice. If the use case relies on premium AI features in SAP Digital Manufacturing, note that they require an additional entitlement and authorisation, and SAP directs customers to their account executive; price that line explicitly.

Process debt (one-off). Cleaning master data such as routings, bills of material, work centres and equipment records; rewriting work instructions and maintenance plans; agreeing loss-reason codes; fixing the confirmation practice so that SAP records what the line did. This is usually the line left out of the first estimate.

Adoption and scale (one-off). Training by shift, coaching, changes to shift routines and daily meetings, named owners, and extending the change across the site. Budget it as a project line, not as goodwill.

Internal staff time (one-off). Operators, engineers and planners on the pilot, training backfill and overtime, and finance time to sign the baseline. Cost it as person-weeks at a loaded rate for the pilot window.

Contingency. A percentage of the four one-off lines, visible in the case, not hidden in them.

Run cost (every year). Subscriptions, infrastructure, integration monitoring, data and model upkeep, and the hours of the people who own the new routine. If the scale phase uses SAP Digital Manufacturing for edge computing, SAP requires an external, dedicated database (PostgreSQL or Microsoft SQL Server); the embedded PostgreSQL is for proof of concept or test only and lacks high availability and backup and restore. Productive use also needs an external Kafka cluster (Strimzi Kafka, installed manually); the embedded Kafka is for proof of concept only, and switching clusters later causes downtime. Price both from the start, not after the pilot.

SAP ME and SAP MII. If your plants run SAP Manufacturing Execution or SAP Manufacturing Integration and Intelligence, a move to SAP Digital Manufacturing belongs in the case only if you decide to make it. We could not verify the end-of-maintenance dates for either product on an SAP primary source, so we do not use them as a timing driver. Check the current dates for your release in SAP’s Product Availability Matrix.

What not to include. Do not put a wider ERP programme into the first pairing’s case, or the pairing’s benefit into the ERP case.

Two cost tests before the case goes to finance: the ratio test (is technology the largest of the first three lines, and why?) and the run-cost test (run cost times the horizon against the one-off total: cheap to start and expensive to keep can look good on payback and poor on NPV).

8. Worked examples: a Gulf process plant and a discrete line

The question: What does the method look like end to end, on a plant like mine?

The two examples are illustrative. Every number is a stated assumption, labelled as one, or a model result computed from those assumptions; none is a benchmark, a result from a real plant or a forecast for yours. Both reproduce in the free model’s example tabs, where each runs twice. Pass 1 prices the top pick at the scope first proposed. Pass 2 re-scopes the pilot to a stated subset: the benefit rates, year-1 realisation, valuation basis, hurdle and horizon stay the same, the addressable base shrinks by a stated ratio, and the costs are rebuilt bottom-up for the pilot. Both use a 10% discount rate, a five-year horizon, the Base scenario, a 15% contingency and internal staff time at an assumed USD 1,500 a person-week, half-time, for the pilot window. The Low scenario is 50% of base for every driver: a downside case, not a benchmark.

(a) A Gulf process plant: cement

The plant. One kiln line, a packing plant and a dispatch yard. The kiln is assumed not capacity-constrained, so an avoided stop is valued at what it costs, not at lost margin. Five pairings passed the safety pre-screen and were scored with the default weights:

The ranking. Predictive maintenance: kiln and raw mill ranks first, energy management second and the free-lime soft sensor a close third: on a modern kiln with hourly lab samples and a historian, its data is ready and an advisory sensor is low-risk. The dispatch yard is well integrated with SAP but small in value.

Pass 1, the kiln line and raw mill. Two drivers, on different loss mechanisms (spend on rotating equipment, and the cost of a stop), so they do not double count:

• Maintenance cost reduction. Assumed baseline: USD 3,200,000 a year, the addressable 40% of the line’s maintenance spend (rotating equipment and drive trains; refractory, grinding media and wear parts excluded). The base case takes 5%, the low end of the dated Deloitte 2017 range, giving USD 160,000 a year. Low is 2.5%; high is 10%.
• Avoided unplanned kiln stops. Assumed baseline: 15 stops a year at USD 50,000 each in restart fuel, refractory damage, off-spec clinker and call-out premiums, USD 750,000 a year. The base case avoids 10%, giving USD 75,000 a year; low is 5% and high is 15%. An illustrative assumption, not a benchmark.

That is USD 235,000 a year of gross benefit. After a run cost of USD 150,000, the annual net benefit is USD 85,000. Assumed one-off costs are USD 400,000 for technology, USD 500,000 for process debt, USD 700,000 for adoption and USD 156,000 of staff time (four people for a 52-week pilot, one maintenance cycle), plus contingency: an upfront cost of USD 2,019,000. With 25% of the full annual benefit in year 1, because the pilot starts at a planned shutdown and runs a full cycle, the NPV is minus USD 1,857,000 and breakeven is 354.2% of base benefit. The verdict: “Do not fund at this scope; re-scope and re-run.”

What was re-scoped, and why. One-off cost was more than twenty times the net benefit. Pass 2 keeps the same rates and proves them on three drive trains: the kiln main drive, the kiln ID fan and the raw mill main drive. Assumed: the three carry 50% of the addressable spend (USD 1,600,000, so USD 80,000 a year). The raw mill is buffered by the raw-meal silo, so its drive affects mill availability, not kiln stops. Assumed: the kiln main drive and the kiln ID fan cause 60% of the kiln stops (USD 450,000, so USD 45,000 a year). Costs rebuilt for that pilot: USD 140,000 for technology (sensors on three drive trains and the alert-to-maintenance-notification loop only), USD 60,000 for process debt, USD 40,000 for adoption, USD 117,000 of staff time and a USD 50,000 run cost.

Pass 2 result. Upfront cost USD 411,000; annual net benefit USD 75,000. NPV minus USD 211,000; payback Not within horizon; IRR n/a; breakeven 154.4% of base benefit; Low-case NPV minus USD 406,000. The most sensitive driver is the upfront one-off cost. The verdict is unchanged: “Do not fund at this scope; re-scope and re-run.”

What would have to be true. Even with no run cost at all, this pilot would not pay. It could pay in two cases: on a sold-out kiln, where an avoided stop is worth lost margin rather than restart cost, or if the monitoring avoids a major drive-train failure (a gearbox, girth gear or fan rotor), which this case does not value. Both are facts to establish, the first from order books and clinker purchases and the second from the plant’s own failure history, not to assume. Without either, the method has done its job: it stopped the plant spending on the first pick by score. The next step is the second pairing on the list, energy management on the grinding and kiln fans, taken to its own baseline and business case.

What it does not include. The predictive-maintenance application layer is priced as a technology line, not tied to a named SAP product; we did not verify SAP’s current product scope for predictive maintenance on a primary source. Replace the assumed cost with a quote.

(b) A discrete batch line

The line. One multi-SKU filling and packaging line run in batches, with frequent changeovers between SKUs. The line is assumed capacity-constrained: demand exceeds what it can make, so a recovered changeover hour becomes sold output. Five pairings were scored:

The ranking. Changeover reduction: SMED with digital work instructions ranks first, ahead of downtime and OEE visibility. Vision quality inspection is held back by effort and SAP fit. SAP Digital Manufacturing documents manual and machine-learning-based visual inspection, and the same page carries SAP’s caution that the capability will be deprecated in a future release, with no date and no successor named. SAP also notes on that page that premium AI features need an additional entitlement; confirm whether the inspection you plan falls under it.

Pass 1, the whole line.

• Margin recovered from shorter changeovers. Assumed baseline: USD 500,000 a year of margin lost during changeovers. The base case takes 50%, the low end of the one SMED study in garment factories, which holds only because the line is assumed capacity-constrained. That gives USD 250,000 a year. Low is 25%; high is 64%.
• First-off scrap after changeovers. Assumed baseline: USD 200,000 a year. The base case avoids 20%, giving USD 40,000 a year; low is 10% and high is 30%. An illustrative assumption.

That is USD 290,000 a year of gross benefit; after a run cost of USD 60,000, the annual net benefit is USD 230,000. Assumed one-off costs are USD 150,000 for technology, USD 200,000 for process debt, USD 250,000 for adoption and USD 58,500 of staff time (three people for 26 weeks), plus contingency: an upfront cost of USD 757,000. With 50% of the full annual benefit in year 1, the NPV is minus USD 17,000 and breakeven is 101.8% of base benefit. The verdict: “Do not fund at this scope; re-scope and re-run.”

What was re-scoped, and why. On a capacity-constrained line only the constraint cell’s hours become sold output. Pass 2 takes the filler’s changeovers only, with digital work instructions for that cell. Assumed: filler changeovers carry 70% of the changeover margin (USD 350,000, so USD 175,000 a year) and 70% of first-off scrap (USD 140,000, so USD 28,000 a year). Costs rebuilt: USD 60,000 for technology, USD 70,000 for process debt, USD 50,000 for adoption, USD 29,250 of staff time (three people for a 13-week pilot, one full SKU rotation) and a USD 30,000 run cost.

Pass 2 result. Upfront cost USD 241,000; annual net benefit USD 173,000. NPV USD 323,000; payback 2.0 years; IRR 48.1%; breakeven 52.3% of base benefit; Low-case NPV minus USD 16,000. The most sensitive driver is the margin recovered from shorter changeovers. The verdict: “Fund the pilot. Continue it only if the measured run-rate reaches at least 53% of base benefit (the pilot’s breakeven). Scale only on a new business case for the wider scope, built on the pilot’s measured rates and the incremental cost of scaling.”

Continuing is not scaling. The whole-line case in Pass 1 needs about 102% of base benefit (breakeven 101.8%), so even a pilot that proves its full base rate would not, on its own, justify rolling out today’s wide scope. The scale case has to be cheaper per unit of benefit than Pass 1: for example, an incremental scope that extends the filler’s proven method and instructions to the next constrained cell, costed on what the pilot has already paid for.

How to read it. Everything rests on the capacity constraint: prove it from order backlog and lost-sales records before the pilot. SMED is a lean method; run the case twice, method alone and method plus the digital work instructions, and fund the digital line on the difference. Some plants take the gain as smaller, more frequent batches instead of output: that is an inventory and service-level benefit, valued differently.

What the two examples teach together

• The first pick by score is not always the first to fund. Scoring chose where to look; the business case decided whether to spend.
• Re-scoping is the method, not a rescue. Neither Pass 1 funded. The same rates on a pilot sized to the loss funded one and stopped the other, before the money moved.
• The gate number comes from the case. The pilot’s breakeven percentage is the test to continue the pilot, not the Low scenario, and not a licence to scale: scaling is a new business case on the pilot’s measured rates and the incremental cost of scaling.

9. Roadmap: pilot, prove and scale on SAP, with gates

The question: How do I sequence the work on SAP so that each step is funded only by the result of the one before?

The roadmap has four phases, each with a gate agreed before the phase starts, and three outcomes at each gate: stop, extend or go. At the pilot gate, go means continue the pilot; scaling is its own business case at Phase 2. Stopping at a gate is a success of the method: the money was not spent on a case that would not have paid.

Phase 0. Baseline. Measure the chosen pairing’s baseline from SAP and plant data, with written definitions. Scale to the pilot when the pairing has passed the safety pre-screen and the baseline is agreed by operations and finance with one named owner. Extend while the data exists but the definitions are not agreed. Stop when the baseline cannot be measured from data you hold. No new system is needed to measure a baseline; if one seems to be, that is a finding about data readiness.

Phase 1. Pilot one pairing. The window is at least one full production or maintenance cycle, never a fixed number of weeks, and it is scheduled around planned shutdowns, because sensors on kiln drives, fans and mill gearboxes usually need a stop. Continue the pilot only while its measured run-rate is at or above the pilot’s breakeven % of base benefit. That is not a scale test: scaling needs its own business case (Phase 2). Extend when leading indicators are on track but too few events have occurred: for rare, lumpy drivers such as kiln stops, judge the leading indicators (condition alerts acted on, preventive-maintenance compliance, the MTBF trend) in the pilot and the lagging stop and cost numbers over a longer window. High-frequency measures such as changeover minutes, scrap rate and kWh per tonne can be judged inside the pilot. Stop when the run-rate is below breakeven after one round of fixes, with enough events to judge.

SAP scope depends on the family. The gate needs the result recorded in SAP where finance can see it, through the loop that family already uses:

• Maintenance: in SAP S/4HANA, the maintenance requests (notifications), maintenance orders and time confirmations the plant already records, and the order costs that the maintenance planner or financial controller analyses and settles. Digital Manufacturing is not a prerequisite. The application layer for predictive maintenance is not verified here; see the process-plant example.
• OEE, quality and changeover, on a line SAP Digital Manufacturing runs: orders are transferred from SAP ERP or SAP S/4HANA to SAP Digital Manufacturing for execution and handled as discrete or process-industry orders by the “Auto complete and confirm” flag on the material in the ERP, and SAP Digital Manufacturing reports yield and scrap confirmations back to the ERP. For SAP ERP and on-premise SAP S/4HANA, the technical integration uses SAP Cloud Integration for data from the ERP and the Cloud Connector calling ERP BAPIs for data coming back; supported direct OData scenarios bypass Cloud Integration but still use the Cloud Connector, and do not apply to SAP ERP. SAP S/4HANA Cloud Public Edition uses communication arrangements and needs neither SAP Cloud Integration nor the Cloud Connector. Check the loop before the pilot starts, as the plant leader’s guide linked in the baseline section describes.
• Energy: the meter and energy data path to cost centres or products.

Phase 2. Scale on the site. Scale only on a new business case for the wider scope, built on the pilot’s measured rates and the incremental cost of scaling: its NPV at the hurdle rate at or above zero, run cost within plan and adoption targets met. Extend while adoption is behind plan but NPV on the measured run-rate is still at or above zero. Stop when NPV on the measured run-rate is below zero, adoption stalls, or run cost exceeds plan by more than 20%. Where the scale phase needs SAP Digital Manufacturing for edge computing, the production database and Kafka requirements from the full-cost section apply, and SAP documents the edge as installed on a Kubernetes cluster through Helm values: infrastructure your team or partner must run, so it belongs in run cost.

Phase 3. Next pairing or site. Re-score the list with the pilot’s actual data and take the next pairing to a business case. Scale when a new pairing tops the re-scored list with data readiness of 3 or more; stop when none does, and invest in data first. Re-score data readiness and SAP fit from the pilot’s own SAP records rather than the first round’s estimates.

Two rules for the whole roadmap. Write the gates down before the pilot starts: a gate written after the result is known is a justification. And measure value after go-live, not just delivery; see SAP Value Realisation Starts Before Go-Live.

For what SAP Digital Manufacturing covers as a product, see our SAP Digital Manufacturing page. For AI use cases, the control questions in the factory-floor AI paper linked in the use-case section come before the pilot, not after it.

10. Gulf considerations

The question: What, if anything, is different about building this case in a Gulf plant?

We include only what a primary source supports, and add method, not statistics.

One example from the region: Emirates Global Aluminium’s Al Taweelah site in the UAE is a WEF Lighthouse. According to the WEF network paper, in three years the site implemented over 80 use cases and upskilled over 20% of its workforce, and it reports operational downtime reduced by 50%, non-productive time by 18% and OEE raised by 12%. It is proof of possibility in the region, not a benchmark: one smelter, self-reported, with deep-learning computer vision and LLM use cases. Upskilling over 20% of the workforce sits beside the use cases in WEF’s account: the adoption line, at regional scale.

What changes in a Gulf plant is the baseline, not the method:

• Size energy baselines against seasonal ambient temperature, because summer heat changes fan, cooler and power demand.
• Schedule pilots around planned shutdowns, and check shift patterns, Ramadan schedules and contractor or crew turnover in the adoption line.
• Check OT-security and data-residency requirements for your jurisdiction before any OT connection to cloud or edge.
• State the capacity case. Where a market runs with spare capacity, an avoided stop is worth its cost, not lost margin.

If your plants span the Gulf and other regions, score pairings per site, not per country.

11. Run the model

The question: What do I do on Monday morning?

The free smart-factory business-case model turns this paper into a working session. It has the tabs in the order you need them: how to use it, your inputs, use-case scoring, benefits, costs, cash flow, sensitivity, roadmap gates, the two worked examples, and sources.

Run it in three sittings:

1. Score. With the plant manager, the maintenance lead, the quality manager and your SAP landscape owner, list up to twelve pairings and score them. Agree the weights first. The top row is where to start.
2. Baseline. For the top pairing only, fill in the input tab from data you hold. Mark any number you could not measure. If too many are marked, go back to the scoring.
3. Case and gates. Enter the benefit drivers with low, base and high percentages, the cost lines, contingency and your discount rate. Read the cash flow, breakeven and sensitivity, then agree the gates on the roadmap tab before anyone spends.

The benefits tab shows a benchmark range only for maintenance, energy and changeover, each labelled with exactly what it is. For the other families it says “No verified benchmark: enter your own”. The two example tabs are filled in and labelled illustrative; overwrite them freely.

Download the smart-factory business-case model (XLSX), with live formulas for scoring, NPV, payback, IRR and sensitivity. Use the CSV version of the inputs, scoring and sources when a portable tabular format is preferable.

The one thing to do after reading: put your top three candidate pairings in front of your plant manager and your SAP landscape owner, and ask each of them to score data readiness on their own. Where they disagree, you have found the first thing to fix.

Next step: Book a free SAP assessment. Altivate can work through the scoring and the business case with your plant and finance teams and help you decide where to start. See also how we approach SAP for manufacturing.

12. Sources and verification status

The question: Where does each figure come from, and how far can I rely on it?

Checked October 2026. Each source is listed with its date and scope. Figures labelled “Lighthouse sites report” are self-reported by a selected, best-in-class population. SAP Help Portal pages carry no publication date; “live” means documented as current when we read the page. The scoring method, the evidence ladder, the gates and the worked examples are Altivate’s method and illustrations, not research.

Benchmarks and research

• World Economic Forum, Global Lighthouse Network: The Mindset Shifts Driving Impact and Scale in Digital Transformation, January 2025. Scope: 189 Lighthouses in 33 countries and 35 subsectors; self-reported site data; best-in-class sites only. Used for the $2:$3:$5 cost ratio, the ROI framing, the Lighthouse ceilings in the use-case section, Unilever Tinsukia and Emirates Global Aluminium Al Taweelah.
• Deloitte Analytics Institute, Predictive Maintenance position paper, Issue 7/2017, July 2017. Scope: predictive maintenance; cross-industry; Deloitte internal analyses; no sample disclosed. Dated. Used for the maintenance-cost range, low end in the base case.
• Fitzgerald, Therkelsen, Sheaffer and Rao, Lawrence Berkeley National Laboratory, Deeper and persistent energy savings and carbon dioxide reductions achieved through ISO 50001 in the manufacturing sector, Sustainable Energy Technologies and Assessments 57, June 2023. Scope: 83 ISO 50001-certified manufacturing facilities; peer-reviewed; an energy-management-system result, not a technology or SAP result.
• Mohammad, Hamja and Hasle, Reduction of changeover time through SMED with RACI integration in garment factories, International Journal of Lean Six Sigma 15(2), 2024. Scope: one peer-reviewed study in three garment factories; a lean method, not a digital use case; discrete lines only.
• Rockwell Automation, eleventh State of Smart Manufacturing report, press release, 19 May 2026. Scope: vendor survey with Sapio Research; more than 1,500 manufacturers in 17 countries. Used for adoption context only, not combined with any other survey.

SAP primary sources (SAP Help Portal, checked October 2026)

• OEE calculations, SAP Digital Manufacturing. Live. The OEE formula and its shift caveats.
• SAP Digital Manufacturing integration with SAP S/4HANA: order and confirmation flow. Live. Orders down, yield and scrap confirmations up.
• Technical integration with SAP S/4HANA or SAP ERP. Live. SAP Cloud Integration, the Cloud Connector and direct OData scenarios.
• Integration with SAP S/4HANA Cloud Public Edition. Live. Communication arrangements; no SAP Cloud Integration or Cloud Connector.
• Prepare Kafka Cluster, SAP Digital Manufacturing for edge computing. Live. External Strimzi Kafka for productive use; embedded Kafka for proof of concept only.
• Edge database, SAP Digital Manufacturing for edge computing. Live. External dedicated database; embedded PostgreSQL for proof of concept or test only; Kubernetes and Helm.
• Visual inspection, SAP Digital Manufacturing. Live, with an announced deprecation in a future release (no date, no successor named) and a premium AI entitlement.

Not confirmed on an SAP primary source as of October 2026: end-of-maintenance dates for SAP ME and SAP MII (the Product Availability Matrix was not retrievable without a login; check the current maintenance dates for your release), and the current SAP product scope for predictive maintenance used in the process-plant example.

Considered and not used. A widely repeated 2017 consulting-firm figure on predictive maintenance and downtime could not be read at source and is not used. The higher Deloitte 2017 cost figure is not used as an upper bound. Vendor payback claims, single-company OEE claims and pilot-purgatory statistics we could not trace to a primary source are not used.