Both fields say they struggle with awareness, data, expertise, trust and adoption. This page checks whether ML really got further than OR, why, what the OR world could copy from the ML ecosystem, and whether one company or only a crowd can pull that off.
The common impression is right on breadth, and the evidence is clear enough to act on. Every proxy that can be measured puts the ML ecosystem roughly an order of magnitude ahead of OR: employment, paper volume, open-source stars and downloads, course enrolments, platform users. Enterprise AI use is surveyed at 78 to 88 percent of organisations. OR adoption has no comparable breadth survey at all, and the fact that nobody measures it is itself part of the awareness problem.
Two things complicate it. First, the AI figures count "regular use in at least one function", a bar that a ChatGPT licence clears; McKinsey's own report has only about 39 percent seeing any profit impact. Second, OR is embedded and invisible: SAP IBP has shipped Gurobi since 2015, Kinaxis runs an optimiser, UPS and Amazon run OR at scale. Counted as "a solver runs somewhere in the stack", OR adoption is far higher than OR-branded adoption. So the honest statement is: ML is adopted far more widely and visibly, while OR is adopted deeply but narrowly, and in both cases the headline rate flatters the depth.
The five challenges share names, not mechanisms. That is the most useful finding here. ML's expertise problem was eased by a reusable artifact (a pretrained model, 3 million of them on Hugging Face); OR has no reusable artifact because each problem is a bespoke model. ML's trust problem is softer because a prediction can stay advisory; an optimisation output is a decision that displaces a person's plan, so trust has to be won by every planner, every day. ML's data problem tolerates approximately right data; OR needs complete and current data or the plan is infeasible. The field report already shows OR stalling exactly there: at data, daily use and ownership, never at the solver.
What to learn. The copyable parts of the ML playbook are the ecosystem mechanics: vendor-neutral open tooling with big-company money behind it, public benchmarks that face the user rather than the solver, managed cloud services, mass education, and a transferable artifact. The last one is the hard one, and the honest answer is that OR's transferable artifact is not a model but a productised vertical (rostering, routing, scheduling) with a configurable API, which is what Timefold, nextmv and the vertical APS vendors are each trying from a different angle. The LLM-to-formulation work (OptiMUS, Gurobi's assistant) is the first thing in years that attacks awareness and expertise directly, but so far its evidence is benchmarks and self-reports from existing users.
One company cannot do it. ML's spread was multi-actor by the record: two competing frameworks from two companies, then a six-member foundation; three hyperscalers; a competition platform; a model hub run by a startup; MOOCs; and academia supplying the benchmark. OR's single-company equivalents exist (Google OR-Tools, Gurobi's surveys and education) and remain small precisely because they are single-company. What is missing is the neutral layer: a foundation, a user-facing benchmark, a shared corpus of real formulations, and a cloud service a non-OR engineer can call. Which actors could plausibly form that is in section 6.
Verticals. The need for ML is horizontal: every function has something to predict, so the market is wide and shallow. The need for OR is vertical and deep: a few domains (logistics, scheduling, supply chain, energy, airlines, finance) carry most of the value, and in each the decision is operationally central. That shape explains both the depth of OR in UPS and the airlines and its absence in the SME mid-market, and it means an OR ecosystem will look like several vertical ecosystems sharing a thin common layer, not one horizontal platform.
There is no survey that asks general enterprises "do you use mathematical optimisation". The only recurring OR survey, Gurobi's State of Mathematical Optimization, samples existing optimisation users, so it measures depth among adopters, not share of enterprises. Every comparison below is therefore a proxy, and the proxies all point the same way.
| Measure | ML / AI | OR / optimisation | Reads as |
|---|---|---|---|
| Share of organisations using it | 88% "regular AI use in at least one business function" (McKinsey State of AI, Nov 2025, n=1,993); 78% (Stanford AI Index 2025, for 2024) | No breadth survey exists. The only recurring survey (Gurobi) samples people who already use optimisation | The gap is real but the AI bar is low: only about 39% report any EBIT impact and about 6% are "high performers" |
| Depth among those who use it | About one third scaling enterprise-wide (McKinsey) | Among Gurobi's 2026 respondents (n=382, existing users): 45% run optimisation automatically in production, 90% combine it with ML | Among adopters, OR is at least as operationalised as AI. The problem is the size of the adopter set |
| Proxies in the field report | German logistics: 51% use some AI; GCC: 84% adopted AI somewhere, two thirds stuck in pilots | About 10% complete APS deployments vs >92% owning one (second-hand); 81% of S&OP in Excel; 2% APS in Poland (2016); 3 to 4% intelligent APS in China | Same pattern: AI "adopted" everywhere, OR present but not running |
| Proxy (retrieved 2026-11-03) | ML | OR | Ratio | Caveat |
|---|---|---|---|---|
| US employment 2025 (BLS) | 275,600 data scientists | 113,100 OR analysts | 2.4x | Many optimisation people are titled data scientist or engineer; directional only |
| BLS projected growth 2025 to 2035 | 35% | 12% | 2.9x | |
| arXiv listings 2025 | 46,101 cs.LG | 6,738 math.OC | 6.8x | Includes cross-lists. In 2015 the two were almost equal: 2,491 vs 2,246 |
| GitHub stars, flagship framework | 105,103 PyTorch | 14,320 OR-Tools | 7.3x | TensorFlow 201k, transformers 168k, scikit-learn 68k; HiGHS 1.9k, SCIP mirror 674 |
| PyPI downloads, last month | 184.3M scikit-learn / 59.0M torch | 6.8M highspy / 6.2M ortools | 10x to 30x | Downloads on both sides include automated and dependency installs, so they measure footprint, not users |
| Flagship MOOC enrolment | 856,232 ML Specialization (Ng); about 8M across his courses by 2023 | no published figure found | n/a | Coursera Discrete Optimization exists; its enrolment page did not load |
| Reusable artifacts | 3,011,630 models on Hugging Face (Aug 2026) | none | n/a | No OR equivalent exists; see section 4 |
The arXiv row is the one worth staring at. In 2015 machine learning and optimisation produced the same volume of papers. Ten years later one is seven times the other. The divergence is recent and it happened during exactly the decade when the ML ecosystem mechanisms in section 3 came online.
So the fair statement is: ML is adopted widely and visibly, OR is adopted deeply and narrowly, and the invisible embedded layer means OR's true footprint is unmeasured. Neither headline number tells you about depth. The question that matters here is why the OR footprint stops at large firms and embedded suites and does not reach the mid-market, and that is a question about the five challenges.
The same five words appear in every adoption talk in both fields. Put the mechanisms next to each other and they stop looking like the same problem.
| Challenge | How it shows up in ML | How it shows up in OR | Who has it harder, and why |
|---|---|---|---|
| Awareness | Solved by hype. "AI" is a board-level word; the buyer knows the category exists even when they cannot name a use case. | The buyer cannot name the category. "¿Y eso qué es?" (SEIO 2024); "Operations Research is an anti-marketing term, unlike AI just not very exciting" (stage 1). The incumbent is a person's judgement, not a competing tool. | OR, by a wide margin. ML's awareness problem became "too much awareness" (pilots that never scale); OR's is still "what is it". |
| Data | Needs volume and labels; tolerates noise, gaps and approximate truth. A model trained on 90%-correct data still predicts usefully. | Needs completeness and currency. One wrong capacity or missing constraint makes the plan infeasible or wrong-but-confident. "The first stall, in every language"; data is relative, tacit or stale, not absent; data cleaning is 40 to 60% of an APS project (stage 3, 4.2). | OR. Same word, different failure mode: ML degrades gracefully with bad data, OR fails sharply. And the data OR needs (the rules in the planner's head) is the kind no system records. |
| Expertise | Was scarce, then was commoditised: pretrained models, AutoML, scikit-learn defaults, 8 million MOOC learners. A software engineer can ship a useful classifier without a PhD. | Still scarce and still bespoke. "You have to translate the business problem into a mathematical model" (Hexaly CEO, 2025); modelling languages "worked for trained OR people and failed for everyone else" (4A); "once the problem is solved there is nothing to do" so in-house groups dissolve (stage 7). | OR. The ML expertise problem was solved by making expertise reusable (an artifact); OR expertise is consumed per project and does not leave a reusable trace. |
| Trust | A prediction can stay advisory. The human still decides, so a wrong prediction costs little and trust grows gradually. Explainability is a research topic, not a blocker, for most uses. | The output is the decision. It displaces the planner's plan, so it is tested against that plan every day: parallel running, override for constraints only the planner knows, silent return to Excel ("the system is for the boss to look at") (stage 5). "A wrong formulation runs fine and returns a confident optimum to the wrong problem" (landscape, section 6). Opacity hands works councils and GDPR a lever. | OR. Not because the maths is less trustworthy (it is more: there is a certificate) but because the artifact being trusted is a decision, and decisions have owners who are being replaced. |
| Adoption and integration | Deployment is a solved engineering pattern: MLOps pipelines, managed services (SageMaker 2017, Vertex 2021), model registries. "Machine learning has clear pipelines" (nextmv, 2026). | "Decision systems have remained very bespoke and ad hoc" (same source). ERP/APS numbering mismatches, IT refusing to maintain, "driver adoption is the quiet killer", value credited to the wrong layer (stage 4, 4.7). Never adopted "without some consulting, a customised solution, and some integration work" (solver vendor founder). | OR. The ML side industrialised its last mile; OR's last mile is still consulting. Chinese rule of thumb in the field report: 30% software, 70% implementation team. |
Read down the right-hand column and one pattern repeats: in each case ML turned the challenge into something that could be solved once, centrally (a pretrained model, a pipeline template, a managed service, a hype cycle), and OR has to solve it again, locally, at every customer. That is not a maturity gap that time closes on its own. It follows from what the two fields produce: a prediction is a reusable function of data, a decision is a bespoke function of one organisation's constraints. Section 4 takes this apart.
Each row is one mechanism with a verifiable origin on the ML side. The OR column asks whether the same thing exists and at what scale.
| Mechanism | ML version (verified) | OR version | Gap |
|---|---|---|---|
| Public benchmark that faces the user | ImageNet / ILSVRC, annual 2010 onward, 50+ institutions competing on a task anyone can understand (is this a cat). Kaggle: 29M users, 68 competitions in 2025, 3.67M dollars in prizes. | MIPLIB 2017 (1,065 instances, 240 for benchmarking), DIMACS challenges (12th on vehicle routing 2020 to 2022), MiniZinc Challenge. All solver-facing: they rank solvers for OR people, they do not show a logistics manager what optimisation does to their problem. | The OR benchmarks are good science and bad marketing. There is nothing a non-expert can enter, watch or understand. The landscape report adds that 26 to 54% of items in the new LLM-for-OR benchmarks are flawed, so even the research-facing layer is shaky. |
| Vendor-neutral open framework with big-company money | TensorFlow open-sourced 2015 by Google; PyTorch by Meta 2016, moved to the Linux Foundation 2022 with AMD, AWS, Google Cloud, Meta, Microsoft, NVIDIA as founding members; 2,400+ contributors, 18,000 organisations. | Google OR-Tools (Apache 2.0, since 2010, one company, 14k stars). HiGHS and SCIP are academic (Edinburgh, ZIB). No multi-vendor foundation; the commercial leaders (Gurobi, FICO, Hexaly, COPT) are closed and compete on the solver itself. | ML's framework layer was deliberately neutralised so that no one vendor owned the on-ramp. OR's on-ramp is either one company's project or an academic one with no commercial backing. The solver, the field report says, is the commodity layer, yet it is the only layer the industry has organised around. |
| Managed cloud service | SageMaker (Nov 2017, "build, train and deploy at any scale"), Vertex AI (May 2021, pitched at "very few models making it into production"), Azure ML. | Gurobi Instant Cloud, nextmv's platform, cuOpt as an NVIDIA service. No hyperscaler offers "optimisation as a managed service" the way all three offer ML. | A software engineer at a mid-size firm can call a managed ML endpoint today. There is no equivalent call for "solve my rostering problem" that does not begin with a sales conversation. |
| Mass education | Andrew Ng's courses: about 8M learners by 2023; ML Specialization 856k enrolled. Fast.ai, every university's intro course. | Discrete Optimization on Coursera (Van Hentenryck and Coffrin). Gurobi and INFORMS run education programmes. | No OR course publishes enrolment at anything like this scale, and an OR course is harder to start because it assumes the learner already has a formulated problem. |
| Transferable artifact | Pretrained models: 1M on Hugging Face Sept 2024, 2M Aug 2025, 3M Aug 2026. Fine-tune or call, do not build. | None. A routing model for one depot does not transfer to another firm's depot without re-modelling. Nearest things: productised vertical APIs (Timefold "has productised the domain into standardised, configurable APIs"), and vertical APS/routing products. | This is the mechanism with no OR analogue and it is upstream of the expertise, trust and integration gaps. Section 5 argues the productised vertical is the OR artifact. |
| Hype and capital | US private AI investment 109.1bn dollars in 2024 (Stanford). Gartner: about 1.5 trillion dollars AI spend in 2025 (includes hardware and consumer devices, not comparable to software). | Venture rounds in the tens of millions: Timefold Series A 13M dollars (2026), nextmv Series A 8M (2021). "Prescriptive analytics market size" figures exist only from market-report firms with inconsistent definitions, so none is used here. | Three to four orders of magnitude in capital. Hype solved ML's awareness problem for free; OR has to pay for awareness one sales call at a time. |
Four structural differences explain most of the table in section 2. None of them is about maturity, so none of them goes away with time alone.
One consequence worth saying plainly: OR's awareness and expertise problems are partly downstream of the other three. If the artifact were reusable, awareness would spread with it (people learned what ML was by using products that contained it) and expertise would be needed once per vertical rather than once per customer. That is why the "what to learn" list in the next section is mostly about the artifact and the neutral layer, not about marketing.
Taking the mechanisms of section 3 one by one.
| From ML | Transfers? | What it would look like in OR |
|---|---|---|
| A transferable artifact | Not as a model. Yes as a productised vertical. | The OR "pretrained model" is a vertical product with the common 90% of constraints built in and a configurable API for the rest: rostering, vehicle routing, production scheduling, cutting. Timefold, nextmv and the vertical APS vendors are each attempting this. The regional report's 250-euro cutting tool that "pays back on one order" is the existence proof that it works when the problem is narrow enough. |
| Vendor-neutral open layer with commercial backing | Yes, but not at the solver. | The solver is the commodity; neutralising it (HiGHS is already there) changes little. The layer worth neutralising is the one above: a shared, open modelling and data-contract layer for the common verticals (what a shift, a vehicle, an order, a capacity look like), so that products and consultancies compete on the last 10% instead of rebuilding the first 90%. Nobody owns this today. The field report notes an independent vendor in a robotised world survives "via an open control standard or by owning the business-rules layer"; the same two options apply here. |
| User-facing benchmarks | Yes. | Public, realistic, anonymised instances per vertical with a baseline that is "the planner's Excel plan", so the metric a buyer sees is "percent better than what you do now", not "seconds to optimality". The ORTEC EURO-meets-NeurIPS challenge was a step in this direction and is the kind of thing a neutral body should run every year. |
| Managed service | Yes, for the productised verticals. | An endpoint a software engineer can call for a rostering or routing problem, priced per solve, with the data contract above. Not "solver in the cloud" (exists, serves OR people) but "decision in the cloud" (does not exist, would serve everyone else). |
| Mass education | Partly. | Not more Discrete Optimization MOOCs. Education aimed at the buyer and the planner: what an optimisation project needs from you, how to read a plan, what an override costs. The field report found skills and time ranked above money as the blocker almost everywhere (Germany 73% know-how vs 48% money), so the education gap is on the customer side, not the OR side. |
| Hype | Borrowable, not reproducible. | OR cannot generate a hype cycle. It can ride one: "decision intelligence" (Gartner's word) and "AI agents that act" are the current vehicles. The landscape report's finding that every production system "kept a classical engine and its certificate" is the sales argument: the LLM is the interface, the solver is what makes the action safe. |
| LLM as the formulation bridge | Promising, unproven in the field. | OptiMUS, Chain-of-Experts and Gurobi's AI Modeling attack awareness and expertise directly by letting a non-expert describe the problem. The evidence so far is benchmarks (with 26 to 54% flawed items) and Gurobi's survey of existing users (79% now use LLMs in their optimisation work, 2026). The landscape report's conclusion stands: "no source shows a non-expert business user getting a production model from natural language at a paying customer with a measured outcome". Verification, not generation, is the bottleneck. |
The ML record says: not one company. Academia supplied the benchmark (ImageNet, Princeton and Stanford). Two companies open-sourced competing frameworks and the winner was then handed to a six-member foundation so no vendor owned the on-ramp. Three hyperscalers built managed services. A startup built the model hub. MOOCs came from a professor. No actor controlled the whole chain and the parts reinforced one another: the benchmark created the talent, the framework made the talent portable, the cloud made the talent deployable, the hub made the output reusable.
OR's single-company attempts show the limit. OR-Tools is excellent and has 14k stars after fifteen years, because it is one company's project with no foundation, no benchmark competition and no managed service around it. Gurobi runs the only recurring survey and a good education programme, and it samples its own users. Each vertical startup (Timefold, nextmv, Hexaly, the 35 German routing vendors at 5 to 20k euro) is productising alone and competing on the first 90% as well as the last 10%.
Can one company still do it? One company can own a vertical. Timefold can plausibly become "the rostering artifact", the way one vendor became the standard tool in cutting and packing. One company cannot build the horizontal layer, because the horizontal layer only has value if competitors adopt it, and competitors do not adopt a rival's standard. That is precisely why PyTorch had to leave Meta.
Can open source alone do it? Not by itself. HiGHS and SCIP are open and good and sit at 1.9k and 0.7k stars. The ML frameworks spread not because they were open but because they were open and funded by companies with a commercial reason to want the ecosystem (Google wanted cloud customers, Meta wanted researchers). Open source is a necessary piece, not the engine.
So who are the stakeholders, realistically?
What this is not: it is not a plea for an "INFORMS for industry". The ML foundation came after the frameworks had already won, to protect them. The OR sequence would need to be: one or two productised verticals win real mid-market share first, then the shared layer is extracted from them and handed to a neutral body with hyperscaler money. Which means the first move is still a company, and the test of whether it is the right company is whether it would give the layer away afterwards.
flowchart LR
subgraph ML["ML ecosystem, as it happened"]
a1[Academia: benchmark
ImageNet 2010] --> a2[Big tech: open frameworks
TF 2015, PyTorch 2016]
a2 --> a3[Foundation: neutral on-ramp
Linux Foundation 2022]
a2 --> a4[Hyperscalers: managed service
SageMaker 2017, Vertex 2021]
a4 --> a5[Startup: model hub
Hugging Face, 3M models]
a1 --> a6[MOOCs: millions of learners]
end
subgraph OR["OR today"]
b1[Academia: solver benchmark
MIPLIB, DIMACS] --> b2[One company: OR-Tools
14k stars, no foundation]
b3[Closed solvers compete
Gurobi, FICO, Hexaly, COPT]
b4[Vertical startups productise alone
Timefold, nextmv, routing vendors]
b5[Suites embed invisibly
SAP, Kinaxis, Blue Yonder]
b6[No managed decision service
No shared data contract
No user-facing benchmark]
end
The general need for ML is horizontal: anything with history can be predicted, so every department has a use case and the market is wide and shallow. The general need for OR is for a combinatorial decision with money on it, which is concentrated. The table marks how central each kind of need is to running the business in each vertical, drawing on the readiness ranking in the regional report (section 7, section 8). "Central" means the business cannot run without someone doing it daily; "useful" means it improves a function; "marginal" means it is nice to have.
| Vertical | Need for prediction (ML) | Need for decision (OR) | Where OR actually stands (from the field report) |
|---|---|---|---|
| Airlines, rail | Useful: demand, delay, maintenance | Central: crew, fleet, timetable, pricing, recovery | Mature, in-house, the OR heartland. Readiness rank 1. |
| Parcel and platform logistics | Useful: ETA, demand, dynamic part of routing (where ML beat OR at ORTEC 2022) | Central: routing, dispatch, network design | Mature at UPS, Meituan, Cainiao, Amazon; in-house, "not a market". Stalls at small operators. |
| Road freight SMEs, dispatch | Useful: ETA, demand | Central but done by a dispatcher in their head | 35 German vendors at 5 to 20k euro; 53% of firms lack dispatchers; "driver adoption is the quiet killer". Rank 3, pulled by labour shortage. |
| Manufacturing scheduling | Useful: demand, quality, predictive maintenance | Central at the plant level; master data is the stall | Head firms mature, SMEs stall at master data; >92% own APS, about 10% complete. 30% software, 70% implementation. |
| Supply chain planning, S&OP | Central: demand forecasting is the core input | Central: inventory, allocation, network | Embedded in SAP IBP, Kinaxis, o9; 81% of S&OP still in Excel. This is where ML and OR need each other most, and where OR is most invisible. |
| Energy, grids | Useful: load and renewables forecasting | Central: unit commitment, dispatch, network expansion | Mature at incumbents (EDF, Chinese grid solver across five provinces); sovereignty argument in Europe. Rank 1. |
| Healthcare rostering, hospital logistics | Useful: admissions, length of stay | Central: rostering, OR scheduling, beds | "Clearest problem, weakest use": ready to buy, not to use; no people in house. Rank 4, pulled by regulation (NHS mandate). |
| Finance | Central: risk, fraud, credit, pricing | Useful to central: portfolio optimisation, ALM, trading | Mature, in-house, mostly invisible as "quant" rather than OR. |
| Retail and e-commerce | Central: demand, recommendation, pricing | Useful: assortment, replenishment, markdown, fulfilment | Embedded in Relex, Blue Yonder; large firms in-house. |
| Marketing, sales, HR, customer service | Central to useful: churn, scoring, text, LLM assistants | Marginal: some scheduling and budget allocation | Effectively no OR. This is where the ML breadth number comes from. |
| Mining, agriculture, construction | Useful: yield, failure, grade | Central: fleet dispatch (Komatsu/Modular DISPATCH since 1996), blending, scheduling | Mature in mining at the equipment vendor; the robots piece's precedent for "the optimisation layer follows the control interface". |
Three things fall out of the table. First, the ML breadth number is largely the bottom rows: functions every company has and where OR has nothing to say. Second, in the rows where OR is central, it is already adopted, in-house or embedded, at firms large enough to afford a team; the unserved market is the same rows one size down, which is exactly the mid-market the regional report found stuck in Excel. Third, the one row where the two needs are both central, supply chain planning, is where OR is most invisible and most dependent on ML's forecast as input; the landscape report's "ML predicts the uncertain part, the engine still does the combinatorics" is the architecture of that row.
So an OR ecosystem would not be one horizontal platform like the ML stack. It would be four or five vertical ecosystems (routing, rostering, production scheduling, supply chain planning, energy) sharing a thin common layer: data contracts, a solver, a benchmark method and an LLM front end. That is a smaller, more fragmented thing than the ML ecosystem, and it is also why it has not self-assembled.
Web retrieval happened on 2026-11-03. Only figures whose source page was read appear on this page. Figures from the earlier reports are cited to the section of the report they live in and carry that report's own caveats (second-hand, vendor-commissioned, Claude's inference).
Margin sits where a layer owns a standard, a control interface or a record, not where the intelligence is. ERP, control software, data platforms and simulation earn high and stable margins. The two layers that hold the actual decision intelligence, prediction and the solver, are the most commoditised. Consulting is the largest pool of OR work and earns labour margins.
FICO is the clearest single number on this tab. The same company, selling to the same banks, earns about 88% segment margin on a score that became an industry standard and about 30% on decision software. The value is not in the algorithm. It is in becoming the thing a process cannot run without.
The OR that has already won is the invisible kind. Advanced process control in cement and chemicals is optimisation running inside the control system. It is sold by the control vendor, measured on the energy bill, and nobody calls it OR. Embedded solvers in SAP and Kinaxis are the same pattern one layer up.
Verticals differ mainly in what the money is made of. In cement it is energy and carbon. In precision manufacturing it is yield and throughput, the largest money per site. In food it is raw material, waste and changeovers. In road it is labour and fuel, against margins so thin that 1% fewer miles is the same order as the whole profit.
Dimensions worth adding to yours: who owns the control interface, who gets credit for the saving, who carries the blame when a decision is wrong, how fast a decision must be taken, and whether the user is the buyer. Section 5 has these with reasons.
Data flows up the stack and decisions flow down. Read it bottom to top. The highlighted rows are the layers usually called OR (blue edge) and ML (amber edge). The columns are a scan; each cell links to the full card.
| Layer, top to bottom | Seller margins | Commoditised? | Usually delivered as | Mostly made of |
|---|---|---|---|---|
| 11 · The human planner | none, a cost line | scarce | in-house labour | human |
| 10 · Integration and consulting | 13 to 15% operating | labour-priced | consulting | human |
| 9 · Simulation and digital twin | 84 to 89% gross | low | product plus modellers | software plus expert |
| 8 · Advanced process control and real-time optimisation | about 33% unit EBITA | low | product plus vendor engineers | software plus engineers |
| 7 · Planning and scheduling applications | 15 to 29% operating | low to medium | product plus heavy implementation | software plus consultants |
| 6 · Optimisation engine (solver) | not disclosed; FICO software 30% | rising | product, mostly embedded | software |
| 5 · Prediction and analytics (BI and ML) | losses common | high | in-house or platform | software plus data scientists |
| 4 · Data platform and historian | 67 to 82% gross | storage yes, semantics no | product plus data team | software plus cloud |
| 3 · System of record (ERP) | 27 to 31% operating | low | product plus integrators | software plus integrators |
| 2 · Control and execution | 15 to 33% segment | low | product plus implementation | software, hardware, engineers |
| 1 · Sensing and instrumentation | 3 to 51% operating | varies | product | hardware |
Margin bands summarise the companies in each card: operating margin unless marked gross. Simulation and ERP are high because they are standards inside workflows. Prediction tools lose money because the method is free and the value is booked elsewhere.
Click a layer to open it. Each card gives the layer in one abstract sentence, then a concrete example, then the same sixteen dimensions in the same order. Open all · Close all
Abstract. Turns the physical world into numbers. Every layer above it is blind without it.
Concrete. Gas analysers and an X-ray analyser on raw meal in a cement plant. Metrology tools and cameras in a fab. Checkweighers, metal detectors and temperature loggers on a food line. A telematics box in every truck.
Abstract. Carries out the plan: tells machines, workers and trucks what to do now, and records that it was done.
Concrete. The DCS that runs a cement kiln. The MES that tracks each lot through a precision plant. The WMS that picks the pallet with the earliest expiry date in a food warehouse. The TMS that dispatches loads.
Abstract. The official truth about orders, materials, stock, money and master data.
Concrete. SAP S/4HANA at a cement group. The bills of material and routings a production scheduler needs, which the regional report found missing "8 years after ERP" in a German plant.
Abstract. Collects and joins data across systems so it can be analysed or fed into a model.
Concrete. A process historian storing every kiln tag for ten years. A cloud lake joining ERP orders, telematics and weather.
Abstract. Says what is happening or what will happen: dashboards, forecasts, quality estimates, failure warnings.
Concrete. A soft sensor that estimates free lime in clinker before the lab result arrives. A demand forecast for fresh dairy. Yield prediction and defect classification in a fab. A delivery-time estimate.
Abstract. Given a model of the choices and constraints, finds the best feasible combination and proves how far from optimal it might be.
Concrete. Gurobi inside SAP planning. OR-Tools inside a routing startup. A MIP solver inside a fab scheduler. cuOpt running vehicle routing on a GPU.
Abstract. Turns a business planning problem into a model, solves it, and puts the plan in front of a planner.
Concrete. S&OP and supply planning in Kinaxis, SAP IBP or o9. Route planning in a TMS or a routing product. Nurse rostering. Lot dispatching in a fab. A food production schedule that respects changeovers and allergen order.
Abstract. Optimisation inside the control loop: adjusts setpoints every few seconds or minutes to keep a process at its best operating point.
Concrete. An expert optimiser on a cement kiln trimming fuel and fan speed. Model predictive control on a mill, a dryer or an evaporator.
Abstract. Lets you test a design or a plan before doing it for real.
Concrete. A model of a new warehouse to check throughput. A fab capacity model before buying tools. A process model of a new kiln line.
Abstract. People who connect the layers and make one company's problem fit a product.
Concrete. A large integrator rolling out SAP. A boutique OR firm (ORTEC, DecisionBrain, Eurodécision in the field report) building a custom planner.
Abstract. The person who makes the decision today, in their head or in Excel, and quietly absorbs every gap between plan and reality.
Concrete. The dispatcher, the shift scheduler, the kiln operator, the production planner.
The same content as section 2, turned sideways: pick a dimension to read it down the stack.
| Layer | Value it creates |
|---|---|
| 1 · Sensing | Visibility, and the back-channel that tells a plan what actually happened. The regional report found this missing almost everywhere: in DACH only 44% capture machine feedback (matrix 2). |
| 2 · Control | Execution and traceability. It is the control interface, and the robots piece in the field report argues that the optimisation layer ends up owned by whoever owns this layer (field report, tab 3). |
| 3 · ERP | One record that everyone plans from. It is the main input to planning and the main source of the data problem. |
| 4 · Data | Integration. The regional report calls data "the first stall, in every language"; this layer is where that stall is fought (stage 3). |
| 5 · Prediction | Less uncertainty. It is advisory: the human still decides, which is why it is easier to adopt (tab 1, section 4). |
| 6 · Solver | The mathematical engine, with a certificate. The field report's central finding is that this is never where projects fail: it is the commodity layer. |
| 7 · Planning app | Better plans and faster replanning: less inventory, fewer miles, fewer changeovers, more throughput. |
| 8 · APC | Energy, throughput and steady quality. It is the most invisible form of OR, because it is called control. |
| 9 · Simulation | Fewer expensive mistakes, mainly in capital spending and policy changes. The regional report found it almost absent from the adoption evidence (4.4). |
| 10 · Consulting | Fit, integration and change management. In OR it is usually where the project actually happens. |
| 11 · Human | Tacit rules, flexibility, and accountability. The field report names this as the one cause behind all three stalls. |
| Layer | What it predicts or decides |
|---|---|
| 1 · Sensing | Mostly nothing. Machine vision is the exception: it rejects a part, which is the first automated decision in the stack. |
| 2 · Control | Low-level control loops and sequences. WMS slotting and pick order. A TMS often embeds simple routing. |
| 3 · ERP | Rule-based MRP, not optimisation. Optimisers are embedded in its planning modules: Gurobi has been inside SAP supply chain products since 2015. |
| 4 · Data | Nothing. |
| 5 · Prediction | Predicts. On its own it decides nothing; it supplies inputs to a decision. |
| 6 · Solver | Computes the decision another layer asked for. |
| 7 · Planning app | What to make, when and where; which truck takes which stop; who works which shift. |
| 8 · APC | Setpoints: fuel rate, feed rate, fan speed, mill load. |
| 9 · Simulation | Nothing directly. It supports decisions about capacity, layout and rules. |
| 10 · Consulting | Designs the decision process. |
| 11 · Human | Everything that is not automated, and overrides most of what is. |
| Layer | Data it needs collected |
|---|---|
| 1 · Sensing | Raw signals: temperature, pressure, flow, composition, images, position, weight. |
| 2 · Control | Setpoints and states, lot genealogy, order status, proof of delivery. |
| 3 · ERP | Orders, bills of material, routings, prices, stock, customer and supplier master data. |
| 4 · Data | Everything below it, as time series joined to master data. |
| 5 · Prediction | History with outcomes: lab results, failures, sales, defects, arrival times. |
| 6 · Solver | None of its own: a model and its parameters. |
| 7 · Planning app | Master data, demand, capacities, and the rules, many of which are only in the planner's head. |
| 8 · APC | DCS tags, analysers, and lab quality results. |
| 9 · Simulation | Layouts, process times, failure and demand distributions. |
| 10 · Consulting | Whatever the project needs, often collected by hand. |
| 11 · Human | In their head: which customer is difficult, which machine runs slow, which driver knows which street. |
| Layer | How often it acts |
|---|---|
| 1 · Sensing | Continuous. |
| 2 · Control | Milliseconds (control loops) to minutes (dispatch). |
| 3 · ERP | Transactional; planning runs nightly. |
| 4 · Data | Continuous ingestion; batch joins. |
| 5 · Prediction | Daily forecasts to real-time estimates. |
| 6 · Solver | Per solve, seconds to hours. |
| 7 · Planning app | Daily or weekly plans, replanned within the day. |
| 8 · APC | Seconds to minutes. |
| 9 · Simulation | Project-based. |
| 10 · Consulting | Project-based. |
| 11 · Human | All the time. |
| Layer | Usual tech stack and vendors |
|---|---|
| 1 · Sensing | Field instruments and analysers (Endress+Hauser, SICK), vision (Cognex, Keyence), fieldbus and OPC UA gateways, telematics (Samsara and others). |
| 2 · Control | DCS and PLC from Siemens, Rockwell, ABB, Emerson, Honeywell, Yokogawa. MES. WMS from Manhattan, Blue Yonder, SAP. TMS from Descartes, Oracle, SAP. |
| 3 · ERP | SAP, Oracle, Microsoft Dynamics, Infor, and regional players. |
| 4 · Data | AVEVA PI and other historians on the plant side. Snowflake, Databricks, the hyperscaler clouds, Palantir Foundry, ETL tools on the IT side. |
| 5 · Prediction | Power BI, Tableau; Python with scikit-learn, XGBoost, PyTorch; SageMaker, Vertex AI, Azure ML, Databricks; vertical vendors for process plants. |
| 6 · Solver | Commercial: Gurobi, FICO Xpress, IBM CPLEX, Hexaly, COPT. Open: OR-Tools, HiGHS, SCIP, cuOpt. Modelling: Pyomo, JuMP, AMPL, GAMS. |
| 7 · Planning app | Vendor apps with an embedded solver; in-house Python plus a solver at large firms. |
| 8 · APC | Model predictive control, rule-based expert systems, increasingly hybrid with ML. ABB, FLSmidth, Siemens, Honeywell, AspenTech, Yokogawa. |
| 9 · Simulation | Engineering simulation from Ansys, Dassault, PTC; process simulation; operations simulation from AnyLogic, Siemens Plant Simulation, FlexSim. |
| 10 · Consulting | Everything above. |
| 11 · Human | Excel, phone, WhatsApp, ERP screens. |
| Layer | Who in the company it talks to |
|---|---|
| 1 · Sensing | Plant engineering, maintenance, quality. For telematics, the fleet or transport manager. |
| 2 · Control | Plant manager, automation engineer, operations or logistics director, with IT. |
| 3 · ERP | CFO and CIO. |
| 4 · Data | CIO, chief data officer, data team. The historian is bought by plant engineering. |
| 5 · Prediction | Data science or BI team, and function heads: demand planning, quality, maintenance. |
| 6 · Solver | OR teams and software vendors that embed it. Almost never the business. |
| 7 · Planning app | Supply chain director, head of planning, transport director. The daily user is the planner, who is often not the buyer. |
| 8 · APC | Plant manager, process engineer, the group's technical or energy and decarbonisation team. |
| 9 · Simulation | Engineering, industrial engineering, capital project teams, and consultants. |
| 10 · Consulting | CIO, COO, sometimes the board. |
| 11 · Human | Not bought, hired. |
| Layer | Knowledge needed: tech vs vertical |
|---|---|
| 1 · Sensing | Physics of the process and of the instrument. Very vertical: an analyser for clinker is not one for milk. |
| 2 · Control | Strongly vertical and safety-critical. Controls engineering for the plant side, warehouse and transport process for the logistics side. |
| 3 · ERP | Business process and accounting. Moderately vertical. |
| 4 · Data | Mostly technical. Vertical knowledge is needed for the meaning of the data, which is the hard part. |
| 5 · Prediction | The technical skill is widely available (tab 1). Vertical knowledge decides which prediction is worth making. |
| 6 · Solver | Deep mathematics. No vertical knowledge. |
| 7 · Planning app | Both, and deeply. The regional report's Chinese rule: 30% software, 70% implementation team. |
| 8 · APC | Very deep process knowledge plus control theory. |
| 9 · Simulation | Modelling skill plus the vertical. |
| 10 · Consulting | Both, held in people rather than products. |
| 11 · Human | Deep vertical, no OR. |
| Layer | How it is delivered: in-house, human labour, consulting, product |
|---|---|
| 1 · Sensing | Product, installed by the vendor's service teams or an integrator. |
| 2 · Control | Product with heavy implementation. At Manhattan, services are 46.5% of revenue. |
| 3 · ERP | Product, implemented by system integrators. |
| 4 · Data | Product, run by an internal data team, often set up by an integrator. |
| 5 · Prediction | Mostly in-house or as a feature of a platform. Consulting for setup. |
| 6 · Solver | Product (licence), most often sold to another software company to embed. |
| 7 · Planning app | Product plus heavy implementation at large firms; Excel in the mid-market. |
| 8 · APC | Product commissioned by the vendor's engineers on top of the existing DCS. |
| 9 · Simulation | Tool product plus expert modellers, often one-off studies. |
| 10 · Consulting | Consulting. |
| 11 · Human | In-house labour. |
| Layer | How standardisable |
|---|---|
| 1 · Sensing | High for the device and the interface. Low for where to put it and what to measure. |
| 2 · Control | The product is standard. Configuration is per site. |
| 3 · ERP | High at the core, custom at the edges. |
| 4 · Data | Technically high. The semantics (what this tag or field means) are not. |
| 5 · Prediction | The method is highly standard. Features and data cleaning are per site. |
| 6 · Solver | Fully standard. |
| 7 · Planning app | Medium. A common core per vertical, with the last part per customer. |
| 8 · APC | Medium. The product is standard; the model is tuned per plant. |
| 9 · Simulation | The tool is standard. Each model is bespoke. |
| 10 · Consulting | Low. |
| 11 · Human | None. |
| Layer | How commoditised |
|---|---|
| 1 · Sensing | Basic sensors are commodities. Analysers, vision and certified instruments are not. |
| 2 · Control | Low for DCS and MES. WMS and TMS are more competitive. |
| 3 · ERP | Low. |
| 4 · Data | Storage and compute are commodities. A contextualised plant data model is not. |
| 5 · Prediction | High: open-source libraries and pretrained models. |
| 6 · Solver | Rising: HiGHS is open, and NVIDIA publishes cuOpt under Apache 2.0. |
| 7 · Planning app | Low to medium. Vendors differ by vertical fit, not by solver. |
| 8 · APC | Low. |
| 9 · Simulation | Low. |
| 10 · Consulting | Priced by labour. |
| 11 · Human | Scarce: 53% of German logistics firms lack dispatchers (Bitkom 2026, in the regional report). |
| Layer | Profit margins of the sellers |
|---|---|
| 1 · Sensing | The widest spread in the stack. Keyence 51.0% operating margin, SICK 3.0% EBIT, Endress+Hauser 11.9%, Cognex 16.3% on 66.9% gross. Samsara, sold as subscription, 77% gross and -3% operating. |
| 2 · Control | Inside the automation majors this is where margin sits. Rockwell Software and Control 29.7% segment margin vs 18.0% devices and 14.5% lifecycle services. Emerson Control Systems and Software 33.0% adjusted EBITA. Siemens Digital Industries 14.9%. Manhattan 25.9% GAAP operating, Descartes 28.8% on 77% gross. |
| 3 · ERP | SAP 73.2% gross, 26.7% operating, services only 11.6% of revenue. Oracle 31% operating. |
| 4 · Data | Snowflake 67% gross, -31% GAAP operating. Palantir 82.4% gross, 31.6% operating. AVEVA 81.2% gross, 29.5% adjusted EBIT (last public year, to March 2022). |
| 5 · Prediction | Horizontal tools struggle to keep the value. C3.ai 31% gross with an operating loss about twice its revenue. Alteryx 86.5% gross, -17.0% operating in its last public year. |
| 6 · Solver | No one discloses pure solver revenue. Gurobi is private and reports over 1,200 customers through its owner. FICO is the useful contrast: its Scores segment earns 87.8% segment margin, its Software segment 30.1%, selling to the same banks. |
| 7 · Planning app | Kinaxis 64.6% gross, 14.5% operating. Descartes 28.8% and Manhattan 25.9% operating, both with execution in the bundle. Blue Yonder reports 103.8% net revenue retention (trade press, from a company update): customers stay but expand slowly. |
| 8 · APC | AspenTech 66.0% gross in its last public year, with an operating loss caused by acquisition amortisation. Emerson's Control Systems and Software unit, which now includes AspenTech, 33.0% adjusted EBITA. |
| 9 · Simulation | The highest gross margins in the stack: Ansys 89.0% gross, 28.2% operating (last public year); PTC 83.8% gross, 35.9% operating; Dassault about 83.7% gross, 21.7% operating. These are engineering-design tools; the operations-simulation vendors are private. |
| 10 · Consulting | Accenture about 32% gross, 15.4% operating; Capgemini 13.3% operating margin. This is the labour-priced layer. |
| 11 · Human | Not a seller; a cost line. |
| Layer | Edge and pricing leverage |
|---|---|
| 1 · Sensing | Depends on the business model, not the layer: a catalogue product sold direct (Keyence) earns software-like margins, an engineering-heavy one does not. |
| 2 · Control | High. It owns the switch. Replacing a DCS means stopping the plant. |
| 3 · ERP | Very high. SAP is moving licences to cloud with no loss of gross margin (cloud gross margin 74.2%), which is what lock-in looks like. |
| 4 · Data | High through consumption: net revenue retention 125% at Snowflake and above 140% at Databricks, so customers keep spending more. |
| 5 · Prediction | Low as a horizontal tool. Higher when it is sold together with the decision it feeds, for example closed-loop kiln control priced on fuel saved. |
| 6 · Solver | High for performance-critical users, falling for basic solving. The FICO split says the money is in becoming a standard inside a process, not in the algorithm. |
| 7 · Planning app | Medium. The value is large but hard to attribute; the field report found savings counted without baselines and credited to the wrong layer (4.7). |
| 8 · APC | High. The saving shows up directly on the energy bill, and the product is tied to the control system. |
| 9 · Simulation | High inside engineering workflows. Lower for operations studies, which are bought one at a time. |
| 10 · Consulting | Low per hour, high per relationship. |
| 11 · Human | Very high. The planner is the incumbent every OR product competes with, and the one who decides whether it is used. |
| Layer | Switching cost |
|---|---|
| 1 · Sensing | Medium. An instrument lives as long as the line it sits on. |
| 2 · Control | Very high. |
| 3 · ERP | Very high. |
| 4 · Data | High. |
| 5 · Prediction | Low. |
| 6 · Solver | Medium: models written against one vendor's interface. |
| 7 · Planning app | Medium to high. |
| 8 · APC | High. |
| 9 · Simulation | High for engineering, low for operations studies. |
| 10 · Consulting | The relationship, and the fact that nobody else understands the custom model. |
| 11 · Human | Highest of all: the knowledge leaves when the person does. |
| Layer | Money it moves |
|---|---|
| 1 · Sensing | Enabler. Its value is counted in the layers above, and its absence is where OR projects stall first. |
| 2 · Control | Hard to isolate, because it is the precondition for everything above. |
| 3 · ERP | Indirect. Bad master data here is what makes optimisation above it fail. |
| 4 · Data | Indirect, and the spend grows with use. |
| 5 · Prediction | Only as much as the decision it feeds. One process-AI vendor (Imubit) says lab free-lime results describe the kiln 30 minutes to hours late, and that closing the loop cut process variability by 20 to 30% (vendor claim). |
| 6 · Solver | The smallest pool relative to the value it enables, because the value is booked in the layers above. |
| 7 · Planning app | Descartes says one customer, ArrowXL, cut fleet mileage 13% (vendor claim). On nine historical datasets at a Seagate wafer fab, an optimising scheduler cut total cycle time about 9% and raised throughput 7% (Winter Simulation Conference 2020, partly vendor authors). An earlier Samsung project cut DRAM cycle time 18.5%, put at about $1bn extra revenue over five years. |
| 8 · APC | ABB reports kiln thermal energy down 3% and manual operator actions down about 70% at Tokuyama's Nanyo plant (vendor claim). AspenTech claims 2 to 5% throughput, 3% yield and 10% energy for its MPC product (vendor claim). |
| 9 · Simulation | Capital avoided or better spent. No sourced figure. |
| 10 · Consulting | Revenue scales with headcount; the field report quotes a Chinese solver company whose project business "scales with headcount" (section 5). |
| 11 · Human | The field report: 81% of S&OP still runs in Excel. |
| Layer | Software vs hardware vs human expert |
|---|---|
| 1 · Sensing | Mostly hardware plus installation labour. Telematics shows the move to subscription software. |
| 2 · Control | Software and controller hardware, plus engineering labour. |
| 3 · ERP | Software plus a large integrator workforce. |
| 4 · Data | Software and cloud compute plus data engineers. |
| 5 · Prediction | Software and data scientists. |
| 6 · Solver | Pure software. Increasingly GPU compute. |
| 7 · Planning app | Software, implementation consultants, and the planner who must use it. |
| 8 · APC | Software and process engineers, running on hardware already installed. |
| 9 · Simulation | Software plus expert modellers. |
| 10 · Consulting | Human experts. |
| 11 · Human | Human. |
| Layer | Cement vs precision vs food vs road |
|---|---|
| 1 · Sensing | Cement: few expensive analysers in a harsh environment, and lab results arrive hours late. Precision: extreme density, fabs now sample every tens of milliseconds and collect hundreds of petabytes a year. Food: many cheap washdown-rated sensors, much still recorded on paper. Road: a telematics box per vehicle, and drivers who do not switch on the app. |
| 2 · Control | Cement: a DCS with cement-specific libraries from a handful of vendors. Precision: the MES record is part of the regulated quality record. Food: traceability is law; the US FSMA 204 rule requires records of 7 critical tracking events, handed to FDA within 24 hours, enforced from 2028-07-20. Road: the TMS and the driver app. |
| 3 · ERP | Cement: few products, co-products and recipes. Precision: configurations and serial numbers. Food: batches, expiry dates, variable weights. Road: orders and addresses, often the weakest master data of all. |
| 4 · Data | Cement and process: a long historian culture, data exists but lab data lags. Precision: volume is the problem. Food: much of the floor is paper and spreadsheets. Road: telematics data exists, but service times and real addresses are not recorded. |
| 5 · Prediction | Cement: soft sensors where the lab is slow. Precision: the biggest single number on this page; an Entegris executive put 1% of yield at about $500m a year of profit at an advanced logic fab, $150m at a memory fab. Food: forecasting against waste, which is 3.8% of food handled in UK manufacturing (WRAP). Road: arrival-time and service-time prediction. |
| 6 · Solver | Same engine everywhere, different problem classes: blending and recipes (linear programmes) in cement and food, scheduling (mixed integer and constraint programming) in precision and food, vehicle routing in road. |
| 7 · Planning app | Cement: few products and continuous flow, so the planning value is in distribution and fuel and raw-material buying. Precision: re-entrant flow in fabs is among the hardest scheduling problems, and the most valuable. Food: changeovers, allergens, shelf life and variable raw material. Road: routing, the most productised OR problem. |
| 8 · APC | Cement: core, because energy is the largest controllable cost. Precision: run-to-run control between process steps. Food: ovens, dryers and evaporators, less common. Road: no equivalent. |
| 9 · Simulation | Cement: process and plant design. Precision: fab capacity and tool purchases, where one tool is a large cheque. Food: line design. Road: depot and network design. |
| 10 · Consulting | Same pattern everywhere. A custom model often dies when its author leaves. |
| 11 · Human | Cement: the kiln operator is replaced step by step by APC. Precision: industrial engineers and dispatch rules. Food: the planner who knows the allergen order. Road: the dispatcher, the scarcest of all. |
It differs a lot, and mostly in what the money is made of. Four reference columns: bulk continuous process (cement), high-precision discrete manufacturing (semiconductors, medtech, aerospace), food and beverage, and road logistics as the reference case.
| Cement | Precision manufacturing | Food and beverage | Road logistics | |
|---|---|---|---|---|
| Cost structure | Energy is 20 to 40% of production cost (US EPA ENERGY STAR guide). A kiln uses 3.6 GJ per tonne of clinker (IEA, 2022). | Dominated by capital and yield. Fabs collect hundreds of petabytes a year. | Raw material dominates. UK manufacturers waste 3.8% of the food they handle (WRAP). US manufacturing surplus food is worth $42.7bn, about 7% of manufacturing sales (ReFED, 2024). | US trucking costs $2.336 a mile: driver wages and benefits $1.03, fuel $0.48 (ATRI, 2025). |
| Producer margins | Heidelberg Materials 21.8% operating EBITDA; Holcim 18.3% recurring EBIT (2025). | ASML 34.6% operating (an equipment maker); Jabil 5.4% core operating (a contract manufacturer). | Nestlé 16.1% underlying operating; Tyson 2.0% GAAP operating; Arla about 2.75% net (2025). | US truckload 0.4%, less-than-truckload 11.6% operating (ATRI). DSV Road about 4.8%, Kuehne+Nagel Road about 2.8% (2024). |
| What the money is made of | Energy and carbon. EU carbon allowances averaged about 74 euros a tonne in 2025 (LSEG), and Heidelberg emits 512 kg net CO2 per tonne of cementitious material. | Yield and cycle time, which means capital utilisation. 1% of yield is about $500m a year of profit at an advanced logic fab, said an Entegris executive in October 2025. | Raw material yield, waste and changeover capacity. The Danish Meat Research Institute reports EUR 0.02 to 0.05 more profit per carcass kg from its yield projects (its own brochure). | Driver hours and fuel. |
| Which layers carry the value | APC on kiln and mills, raw mix and fuel mix optimisation, then distribution. | Prediction (yield, virtual metrology, inspection) and fab scheduling. The most ML-heavy and the most valuable OR scheduling. | Forecasting for perishables, production scheduling, cutting and yield optimisation, shelf-life-aware stock rotation. | Routing and dispatch, the most productised OR problem. |
| Where ML vs OR pays | OR first: the physics is known, so optimising control beats predicting. ML mostly as soft sensors feeding the optimiser. | Both, heavily. ML for yield; OR for scheduling. | Both, but the mid-market runs on Excel. | OR for routes, ML for arrival and service times. |
| Data | DCS tags, analysers, lab results that arrive late. | Very high volume: tool sensors sampled every tens of milliseconds, metrology, images. | Batches, expiry dates, checkweighers, much paper on the floor. | Telematics plus orders and addresses that are often wrong. |
| Who decides | Plant manager, process engineer, group decarbonisation. | Yield engineering, fab operations, industrial engineering. | Plant manager, planner, quality, supply chain director. | Transport or operations director; the dispatcher in practice. |
| Cadence | Seconds (control), shift (quality), weekly (fuel and raw mix). | Seconds to minutes (dispatching), per lot (yield). | Shift and daily. | Daily routes, minutes for re-routing. |
| Regulation that shapes it | EU emissions trading, with free allowances phasing out. | Regulated quality records in medtech and aerospace. | Traceability law: EU one-step-back-one-step-forward; US FSMA 204 enforced from 2028-07-20. | Driving-time rules; labour shortage is the stronger pull. |
Where 1% moves the most money relative to margin. Road first: 1% fewer miles saves at least 0.2% of cost in fuel alone, more where drivers are paid by the mile, against truckload margins under 1%. Then low-margin food: cutting waste by one point of sales is a third or more of the net profit of a 3% producer. Then cement: with energy about 30% of cost and EBITDA about 20% of sales, 1% of fuel is roughly 1% of EBITDA, and carbon makes it more. Precision last relative to its high margins, but first in absolute money per site.
That ordering also predicts the selling motion. Where margins are thin (road, food) the buyer is desperate but cannot pay much, so products must be cheap and standard. Where money per site is huge (fabs, cement plants) the buyer pays for bespoke engineering, so consulting-heavy delivery survives. The mid-market in thin-margin verticals is the hardest place to sell OR and the place it is most needed.
| Dimension | Why it matters for getting a feel |
|---|---|
| Who owns the control interface | The layer that can actually press the button (DCS, WMS, TMS, the robot fleet) ends up owning the optimisation above it. APC belongs to the DCS vendors for this reason, and the robots piece in the field report makes the same argument for automated sites. |
| Who gets credit for the saving | A prediction rarely gets credit; an optimiser often gets credit for the wrong thing. The field report found mileage control counted as routing savings. Layers that cannot prove their value get priced as cost. |
| Who carries the blame | A wrong forecast is a bad number; a wrong plan stops a line or strands a truck. The higher the cost of a wrong decision, the slower adoption, the higher the price, and the more the human keeps an override. |
| Is the user the buyer? | The supply chain director buys and the planner uses. When the user is not the buyer, adoption fails at daily use even after a successful sale. This is the "stage 5" stall in the regional report. |
| How fast the decision must be taken | Seconds (APC, dispatching) forces automation and wins; weeks (S&OP) leaves room for a human to redo it in Excel. |
| How much of the problem is the same across customers | This decides product vs consulting more than any other factor. Routing and rostering are similar enough to productise; a cement group's network or a fab's dispatch rules are not. |
| How variable the raw material is | Food and cement work with natural raw material that varies every batch; precision works to a specification. Variable inputs need prediction feeding the optimiser. |
| Recurring or one-off revenue | Simulation studies and consulting projects are one-off; control software and ERP are recurring. Net revenue retention, where published (Snowflake 125%, Blue Yonder 103.8%), shows how much a layer grows inside a customer. |
| Age of the installed base | A brownfield plant with a 20-year-old control system needs integration before optimisation. Greenfield sites, and robotised ones, start with the control interface already digital. |
| Regulation as pull or as brake | Carbon price, traceability law and staffing mandates pull; works councils and data protection brake opaque decisions. The field report found regulation and labour shortage were the only pulls that moved buyers. |
| Labour substitution or augmentation | Where the planner is scarce (dispatchers in Germany), automation is welcomed. Where the planner is secure, the tool is a threat and gets overridden. |
Retrieved 2026-11-03 and 2026-11-04. Margins computed from the lines of a filing are marked "about" in the text. Vendor claims are labelled where used.