Supply chain optimisation in practice: when you need a solver, and when Excel is enough
About the panellists
Johan Pols has thirty years in supply planning and supply chain management at Eastman Chemical, Unilever, Le Duc Fine Food, Wilmar and others. Cristina Radu, PhD in mathematics, has implemented more than 35 optimisation solutions. Andreas Feldmann is a researcher and professor in operations research at Charles University and the University of Sheffield. Watch the webinar.
Supply chain optimisation is sold as the step after planning: once the plan exists, a solver finds the best one. In practice the step is rarely taken, and when it is, the planner often walks back to Excel within months. In a Horizon roundtable, three people who see this from different sides, Johan Pols from thirty years in industry, Cristina Radu from more than 35 implementations, and Andreas Feldmann from research and teaching in operations research, agreed on why it happens and on what to do instead. This article sets out their reasoning as a decision guide: what optimisation is for, why it fails, how to tell whether your problem needs a solver, and how to get planners to trust and use the result. The replay is on the webinar page.
What optimisation does, and what it does not
Supply planning translates demand into inventory positions and production quantities. Optimisation makes that plan the best one for a stated objective, minimising cost or maximising service, say, within the constraints of the business, either with a mathematical solver working on equations or with a heuristic that encodes the rules. A plan can be made without it; it just may not be the best plan. Two distinctions from the roundtable frame everything else. Feldmann’s: AI in the sense of large language models is predictive, optimisation is planning, and the two should be kept apart. Radu’s: a solver returns the mathematical solution, and the business solution is what the planner makes of it with industry knowledge. Neither takes the planner’s place; both change what the planner does.
Why planners go back to Excel
Pols sees the same picture in company after company: a system is implemented, and planners revert to Excel. The reasons are flexibility, data they do not trust, and above all that they cannot explain what the system is telling them. When the plan goes to management, the question is rarely about the model. “Nine out of ten times they are questioning why do I need to make this decision, because there is money on the table.” A planner who cannot answer is sent back to do their homework, so they recompute the answer in Excel, where they understand it, and present that. Underneath sits a skill gap: many planners are trained at vocational level, and reading an optimiser’s output asks for a different skill set.
Radu’s diagnosis of the implementation projects themselves is the missing common language. The vendor’s seniors who sold the project understand both business and technology; the juniors who build it understand the technology and not the business processes, who does what and in what order. An implementation partner comes from the other side, with business experience but without ever having cleaned data and built a system from scratch. The fix she has watched companies adopt in the last two years is an in-house expert, someone with ten or fifteen years in industry who has used two or three systems and who can challenge the technical requirements and the business requirements, with no stake in the vendor’s outcome. Pols calls the same role the middleman: the person who takes planners along, translates business requirements into technical ones, and keeps understanding intact from planner to technical expert. When that person exists, he says, the planners’ enthusiasm appears as soon as they begin to understand the system.
There is a third reason, which Radu raises because it is so often dismissed: the system is not pleasant to use. A planning system with a hundred buttons and forty clicks to see the demand loses planners in testing and validation, which they do on top of their day job, and it loses them afterwards. Her advice when choosing software is a clean thing that does three things well.
Optimisation is not a black box
Explainability has three layers, in Feldmann’s framing. The first is the model: which constraints are in it and why the solution respects them. Teaching people to model helps, and a language model can plausibly read the rules and render them in plain words. The second is the computed solution, which is harder, though explainable algorithms are an active research area. The third is what-if analysis: fix the part of the plan your intuition disagrees with, recompute the rest, and compare, so that the reason for the original choice becomes visible.
Radu rejects the black box label outright. Mathematics is precise: with a given equation and given data, the output is determined, and any surprise traces back to a data error or to a constraint. The practical problem is that finding it can take an expert two days. She has seen software, ten years ago and without AI, that solved this with a decision tree: did you do this, did you see that, and in a few minutes the planner alone found the problem, which 99% of the time was data, and typically the same kind of data, such as a capacity entered wrongly. If one vendor could build that, any vendor can; it is a matter of asking for it. One attendee suggested the same idea from the other end, a score analysis of which constraints are binding or broken, which exposes a wrongly defined rule as fast as a wrong number.
Can every planner learn it
Radu’s answer is yes, and her argument is the one that most changes how to run a project. Every supply chain is a material flow, and the planner already keeps its constraints as equations in Excel. Moving them into an optimiser changes no logic and no constraint. What the software adds is integration, automation, end-to-end visibility across a network that Excel cannot hold, and a better plan. So a planner who understands planning in Excel can understand it in the system, provided someone explains it in plain English rather than in technical terms and allows for a learning curve. In projects run that way she has watched planners become the masters of the system: enhancing it, proposing what-ifs, unintimidated because they can see that the formulation is what they were already doing.
Pols adds the honest corollary. Roles change; thirty-five years ago planning was filling a spreadsheet with tomorrow’s production, and today it looks two years ahead with more complexity and more variability. Some people will make the step to working with an optimiser and some will not, as with every change of role before AI, and a company has to find a solution for the second group inside or outside the business. Feldmann’s point for universities is that modelling is barely taught, even in computer science, so the education has to happen in the company.
Do you need a solver at all
The tipping point is the complexity of the decision, not the size of the company. Pols gives two examples from practice. One raw material bought from only five suppliers, where price, quality and availability over time made the best long-term buying pattern impossible to compute by hand, so a linear programme replaced the manual Excel approach as the material became scarce. And a shop floor with 2,000 orders and 20,000 released order lines, which no human can sequence, so a custom heuristic with the real constraints built in did what Excel could not.
Radu gives the counter-example. A global company installed a large planning system to plan globally and discovered that its regions did not connect: one person who planned France in Excel now planned France in the system, with no flow to any other region, and the two requirements that mattered most were ones the system could not meet, so new products and workarounds followed. What they needed was Excel with a little optimisation on the side. Her test is simple: twenty plans in one optimiser, go for it; one plan, start in Excel, and if that is not good enough, add an open-source or inexpensive commercial solver.
That leads to the route she wants more companies to see. The common practice is to implement a planning system for automation, integration and visibility, and to treat optimisation as a module on top, reached after a one- to three-year implementation. The other route is to keep planning and data where they are, in the ERP or in Excel, and attach an optimisation model, with free open-source tools if the company is small. An optimisation model, she says, is implemented in two or three months and costs far less. Her caveat is about power rather than sophistication: in supply chain the fight is with size, not complexity, and the same two simple constraints that run in twenty hours on an open-source solver can run in half an hour on a commercial one, which matters when you want to run scenarios. Feldmann’s answer to how much of the world’s planning is actually solved with solvers is “essentially none”, because planning is everywhere, down to loading a dishwasher, and only the very few complex problems deserve an algorithm. Radu adds the middle step: do not jump from Excel to mathematical optimisation; a custom heuristic written to the company’s own rules teaches planners the relation between input and output, because they wrote the rules.
What LLMs can do here
Feldmann’s warning is that AI is a buzzword that some expect to solve everything, and it cannot, for a fundamental reason: a language model predicts from what it was trained on, which is roughly what humans have already written down. It can produce solutions to problems that have been solved before and will struggle to be innovative, which is where experts earn their place. For a simple problem he can imagine a tool that generates a model from a prompt; the more complex the problem, the more an expert has to check it. Radu points out that most of this was possible before LLMs. Because every supply chain shares a structure, demand, rates, inventory, flows in and out of each node, one vendor a decade ago offered an Excel template that generated the model and its constraints at the press of a button, covering 80% of what any supply chain solver needs, with an expert building the rest. What LLMs add is the interface: write “it is not allowed to go from Berlin to Hamburg, it has to go through Paris”, and the constraint changes and the result appears, which is useful when the solver answers in seconds and less so when it runs for two hours.
Gathering the real constraints
Two pieces of advice close the roundtable. Radu’s is to ask specific questions before choosing software, because users describe what they want in vague terms (“a view to put demand in”) while the constraints that decide whether a system fits sit almost at shop-floor level. Her example is lot size: at product level, at product group level, or for a group defined by flavour rather than SKU. Some systems can do that and some cannot, and it is fundamental to how the company plans. Her list of about twenty such questions is going on the Optimization for All site. Pols’ is to map the real supply chain first and separate the real constraints from the imaginary ones, because some constraints are not constraints at all, and even a complex assembly plant can be chopped into smaller parts once the physical flow is understood. Radu adds the planning levels: a strategic decision has to travel through tactical planning to the shop floor, and with the wrong systems in between it is lost on the way. The system supports the planning process; it does not fix one that nobody has defined. Pols’ last word is where to start: not the whole supply chain in one go, but the decision that earns the most money or causes the biggest headache, and simply.
How Horizon reads this
The roundtable describes the conditions Horizon’s supply modules are built to meet. The methods are the ones the panellists name: distribution, procurement and production planning use linear and mixed-integer programming, production scheduling combines finite capacity scheduling and mixed-integer programming with minute-by-minute sequences per line, and inventory optimisation gives the optimal stock policy per item and location, or applies the customer’s own stock rules. The route is the second one Radu describes: Horizon connects to all major ERPs, including SAP, Oracle and Microsoft Dynamics 365, or works from Excel or CSV, on one data model for every module, and approved decisions flow straight into the plan and the ERP, with owner and reasoning logged. The planner stays the one who turns the mathematical solution into the business one. Watch the full replay.
