A planning platform has been live for two or three years. The business case promised lower inventory and better service, and at the review the numbers have moved less than anyone hoped. The explanations on offer tend to be familiar ones: the forecast was wrong, a supplier slipped, a machine broke down. Surveys suggest the shortfall is common. A 2015 Nucleus Research and DC Velocity survey of 215 supply chain professionals found that 48 percent said their software investments had delivered the expected payback, 18 percent said they had not, and 34 percent were unsure. That survey covered supply chain software broadly, not planning platforms alone, but the scene at the review is one I hear described often enough in the conversations BestPractice.Club records with planning leaders that it has started to look like a pattern. So I went back to someone who has watched it up close.
That someone is David Evans. I first connected with him when he was Head of End-to-End Supply Chain Design at Merck, having previously been Global Supply Chain Strategy and Innovation Director at GSK and later Principal Consultant for Unilever, so he has spent a long time on the practitioner side of planning programmes. In a conversation two or three years ago, his point was that most planning parameters are simply ignored, which is something I've since confirmed from speaking with others is a common pattern. David is an original co-founder of Oii (a BestPractice.Club sponsor), where he now advises the business on supply chain innovation. What follows is his reading of the problem and my questions about it, based on what I hear from others trying to balance cost, cash and service in their planning cycles.
The platform plans as it is told to
David's description of the first wave of planning platform deployments is blunt. The business case promised less inventory and better service, but the platform went in with the same parameters as the process it replaced, so it did much the same thing as before. His image for it is buying a Bugatti and being expected to configure the engine yourself: comfortable to sit in, with a concurrent plan and end to end visibility on the screen, but "unless you've actually configured it correctly, it doesn't really do anything much better than what you've got."
The parameters in question are the safety stock, lead time and service settings that tell the platform how much buffer to hold and how hard to protect each item. His example was a single policy applied across a very varied range of products. That policy turns the conversation into whether the business should hold more inventory or less overall, when the more useful question is item by item: which of these protects sales worth protecting, and which is quietly costing margin by holding stock it does not need. In David's view almost every item should have its own setting, with the trade-offs made visible, and in most companies that work falls to planners who, in his words, are not equipped to make those decisions. So they run with what they inherited and fix problems as they surface.
Where the effort goes
The second half of his argument is about noise. The best planners he managed focused on parameters because "if you focus on the parameters, you reduce the noise", which freed time for continuous improvement. The weakest spent their days running between factory and warehouse chasing individual problems, each explained as a breakdown or a late truck rather than as a setting nobody had revisited. His test is simple: how often does that machine break down, and does the buffer reflect it? If it breaks down all the time, that is variability to plan for, and it should not come as a surprise.
He was equally direct about forecasting. A programme that aims to lift forecast accuracy by a few points across the board prompts him to ask what that will actually change, and whether the same effort aimed at the fifty or so items that drive most of the buffer would do more. Separately, a simulation study using retail data from the M5 forecasting competition found that better forecasts generally lowered inventory costs, but that optimising the inventory policy produced larger benefits still (Theodorou and Spiliotis, 2023). It is one simulation on one kind of data, so it points to something worth testing and leaves the question open.
Why the question rarely gets asked
What interested me more than the mechanics was why a diagnosis this simple stays uncommon. David's observation is that when something goes wrong, no one ever says "our parameters are wrong", which suggests the settings are the last place anyone looks.
The timing helps it stay that way. A platform project closes at go-live, and looking after parameters is an ongoing job that belongs to no project. Analysts, consultants and solution providers each have reasons to treat it as the customer's job from that point, and David's experience is that the planning platform market by and large leaves it with the buyer.
The person who does look has a harder job than finding the problem. They have to tell the budget holders that money spent two or three years ago has not done what it was meant to, and then ask for more to make it do so. I put it to David that nobody is champing at the bit to champion that, and he agreed. It sounds like a lot of extra work, and the person raising it risks becoming the colleague who always arrives with another idea or points out limitations. He thinks the people who can get this moving combine good ideas with the ability to sell them, and that there are not many. This is the decision gap in a familiar form: the need to change is visible long before anyone volunteers to say so.
Two ways to give every item its own setting
The obvious objection is scale. Thousands of items cannot each be set and reviewed by hand. David's answer is a tool that simulates the trade-offs between service, cost and inventory so that a planning meeting can interrogate them. He also sees merit in decoupled buffer approaches such as DDMRP. How to give each item its own setting is a separate question from whether anyone owns the setting at all.
A question to take into the review
The most practical idea I took from the conversation is a diagnostic. Before asking for anything new, ask what the platform should be delivering on the parameters it has today: what service level, what inventory, what cost to serve. Then compare that expectation with what actually happened, and see whether the difference points to the forecast, to supply, or to a setting nobody has revisited.
What I hear from supply chain and planning leaders is that the cases which move people tend to promise fewer expedited orders each month or a better answer to give the next time something goes wrong.
In those conversations, the platform business cases that stall tend to leave one thing out: nobody is named as owner of the item-level trade-off between service, cost and cash, or of how often it gets revisited. Until someone is, the benefits the case promises depend on settings nobody has agreed to look after.
If you are trying to work out whether the platform you have is the problem or whether it is doing what it was told, the Test Assumptions Pattern sets out the questions practitioners tend to ask at this point.
Explore the Test Assumptions Pattern
BestPractice.Club is running an online session on cost-to-serve analytics and scenario planning with Oii on 29 October: Are Your Planning Parameters Set for a Business That No Longer Exists? Oii is a sponsor of that session.