IBP rollout, month 18: what we got wrong
The system went live. The forecasts improved marginally. The organisation fought the process for eighteen months. A post-mortem on what an IBP transformation actually costs.
The go-live happened on a Tuesday in October. The programme director sent an email to the steering committee. Green dashboard. All milestones achieved. The system was live in six markets, covering 78% of revenue, with 14 months of historical data loaded and the statistical forecasting engine running nightly.
By the following March, three of the six markets had reverted to maintaining parallel Excel files alongside the system. The demand planner in the largest market had quietly rebuilt her entire planning workbook and was exporting from the system into it each morning. The S&OP process that the IBP tool was supposed to enable was running at approximately the same maturity level it had been running at before the $4.2 million implementation.
This is a post-mortem. Names are changed. The pattern is not unusual.
What IBP is supposed to deliver
Integrated Business Planning is the evolved form of S&OP — the same cross-functional alignment logic, extended to cover the full planning horizon (typically 24–36 months), fully integrated with financial planning, and enabled by a single planning platform rather than the Excel-and-ERP patchwork that most companies run.
The vendors — SAP IBP, o9 Solutions, Kinaxis, OMP, Anaplan — promise versions of the same outcome: one version of truth, scenario planning capability, real-time supply-demand reconciliation, and the elimination of the manual reconciliation overhead that kills productivity in most planning teams.
The Gartner Market Guide for Supply Chain Planning Solutions (2023) estimates that companies with mature IBP capability achieve 15–20% reductions in inventory, 10–15% improvement in forecast accuracy, and 20–30% reduction in planning cycle time. These are real numbers from real implementations. They are also the numbers from the top quartile of implementations. The median story is different.
What the research says about IBP implementation failure
Panorama Consulting's 2023 ERP/Planning Report, covering 271 implementations, found that 58% of supply chain planning implementations exceeded their original budget, with average cost overrun of 24%. Average timeline overrun was 33%. More significantly, only 41% of respondents said their implementation delivered expected business benefits within three years of go-live.
A 2022 Gartner study found that the #1 cause of supply chain planning implementation failure was organisational change management, cited by 67% of respondents — ahead of technology issues (31%), data quality (48%), and process design gaps (44%). Note that data quality was cited by nearly half of respondents but still ranked below change management.
The Boston Consulting Group's 2023 analysis of digital supply chain transformations found that 70% of supply chain digital transformations failed to achieve their stated objectives — a number consistent with the broader digital transformation failure rate, which McKinsey has estimated at 70% across industries.
What the aggregate statistics don't capture is the specific texture of how IBP implementations fail. The system works. The data loads. The statistical models run. The failure is in the adoption — and the adoption failure follows a consistent pattern.
Month 1–3: the honeymoon
The first three months after go-live are genuinely productive. The planning team has been heavily trained. The consultants are still on site. The steering committee is paying attention. Data quality issues that were known but tolerated in the old system are being actively addressed because the new system makes them visible.
Forecast accuracy improves modestly — typically 3–5 percentage points — because the new statistical models are better than the Excel-based ones they replaced, and because the data cleansing that happened during implementation has removed some of the noise in the history.
The team is learning the tool. Every planning cycle is slower than before because the process is unfamiliar. This is expected and communicated. The consultants explain that there is a productivity dip before the curve turns up. The steering committee accepts this. The programme director reports that adoption metrics are on track.
Month 4–6: the first crisis
Something goes wrong with the data. It is always something with the data.
In the case I'm describing, it was the promotional history. The company ran significant trade promotions — BOGOF offers, volume discounts, price promotions coordinated with key accounts — and the historical data loaded into the system did not systematically flag these periods. The statistical forecast was therefore extrapolating from a history that included promotional uplifts without knowing they were promotional uplifts. The result was a baseline forecast that was structurally biased upward for certain SKUs.
The demand planners knew this. They had known it for years. In the old system, they corrected for it manually, using institutional knowledge about which periods were promotional and roughly how much to discount the history. The new system didn't have this knowledge. The correction logic was supposed to be built during implementation. It was partially built — enough to pass UAT — but not robustly enough to handle the full range of promotional mechanics the company used.
The demand planner in market three, who had been in her role for nine years, raised this in week six. The response from the implementation team was that a fix was being scoped. The fix took eleven weeks to fully implement. During those eleven weeks, she maintained her Excel file.
She never fully stopped.
Month 7–12: the consultant departure
The consulting team rolled off in month eight. This is standard. The implementation contract covers go-live and a stabilisation period. By month eight, stabilisation is declared. The consultants transfer knowledge to the internal team, document the process, and leave.
What leaves with them: the institutional knowledge of why certain design decisions were made, the ability to escalate data issues quickly within the vendor's support structure, and the change energy that was keeping the steering committee engaged.
What remains: an internal team that understands the tool at a user level but not at a configuration level, a set of process documents that describe what the process is supposed to look like rather than what it actually looks like, and a vendor support contract that handles bugs but not adoption.
The first S&OP cycle after the consultants left took three days longer than the previous cycle. The demand review meeting ran two hours over schedule because a data issue in the system couldn't be diagnosed in the room. The commercial team, who had been tolerating the slower cycle times in deference to the programme, began to ask openly whether the new system was actually better than the old one.
Month 13–18: the parallel file problem
By month thirteen, the parallel Excel files were visible if you knew where to look.
They were not secret. The planners were not hiding them. They were practical adaptations to specific gaps in the system. The demand planner in market one had a file for managing new product introductions — the system's NPI process was too slow for the speed at which commercial was launching products. The planner in market four had a file for managing customer-specific forecasts — three key accounts required weekly forecast submissions that didn't map to the system's planning buckets. The planner in market three had her promotional history correction file, which had never been fully superseded.
Each file was a reasonable response to a real gap. Each file was also a fracture in the "one version of truth" that the IBP implementation had been sold on.
The problem compounds because the files don't stay contained. Once a planner has a parallel file that she trusts more than the system for one purpose, the boundary of that trust expands. She starts checking the system number against her file before committing to it. When they diverge, she uses her number. The system becomes the input to her process rather than the output.
By month eighteen, the planning director could not tell the steering committee with confidence that the numbers in the IBP system were the numbers the markets were actually planning from.
What actually failed
Not the technology. SAP IBP is a capable system. The forecasting engine works. The scenario planning tools work. The financial integration works.
Not the data. The data quality was genuinely improved by the implementation — master data was cleaner, historical data was more complete, and the promotional history issue, though it took three months, was fixed.
What failed was three things that the implementation methodology did not adequately address:
The process was designed for the organisation that was aspired to, not the organisation that existed. The future-state process assumed that commercial would provide structured promotional volume input on a monthly cadence. In practice, commercial provided promotional information on a deal-by-deal basis, often two weeks before execution, in formats that varied by market and by key account manager. The process design gap between "commercial inputs volume uplifts monthly" and "commercial calls planning the Thursday before a promotion goes live" was never closed.
The incentives didn't change. The demand planners were measured on forecast accuracy. The IBP system's statistical forecast was their baseline — but their bonus was calculated on the accuracy of the consensus forecast, which they were responsible for adjusting from the statistical baseline. When the system's statistical baseline was wrong (as in the promotional history case), adjusting it correctly improved accuracy. But the adjustment took time and required defending the override to the commercial team. The path of least resistance was to maintain the Excel file, use it to produce the right number, and enter that number into the system. The system recorded the outcome. The Excel file contained the reasoning.
The change management programme ended at go-live. The change management workstream in the implementation — communications, training, stakeholder management — was structured around adoption of the tool, not adoption of the process. It measured whether users could operate the system, not whether they trusted it enough to stop using alternatives. After go-live, the change management budget was exhausted and the attention moved on. The organisation's resistance to the process — which had been suppressed during implementation by the programme energy — re-emerged once that energy was withdrawn.
What a real IBP transformation requires that nobody budgets for
Based on the post-mortem, and on what I've seen in other implementations:
Year 2 is the real implementation. The first year is system deployment. The second year is the process actually taking hold — which requires dedicated internal resource, continued executive attention, and a budget for the fixes that emerge from real-world use. Most implementation contracts budget for Year 1. Year 2 is an afterthought.
A process architect who isn't a vendor employee. The vendors' implementation consultants are expert at deploying the tool within the vendor's reference architecture. They are not incentivised to tell you that your organisation's commercial process is structurally incompatible with monthly planning cycles. That judgment requires someone who is accountable to your business outcomes, not to the implementation project.
Incentive alignment before process redesign. If the commercial team's bonus structure rewards in-year revenue without regard for forecast accuracy, no IBP process will produce honest demand signals. The process is downstream of the incentive. Fixing the process without fixing the incentive produces accurate-looking numbers that don't reflect commercial reality.
An honest assessment of the parallel files. At month eighteen, the right response to the parallel file problem was not to mandate that planners stop using them. It was to understand why each file existed, fix the gaps that created them, and earn the trust that would make planners willing to let them go. We did not do this quickly enough.
The number that matters
In the eighteen months from go-live to the point where this post-mortem was commissioned, the IBP implementation had cost the original $4.2 million implementation fee, plus approximately $1.1 million in stabilisation and fixes, plus an estimated 2,400 person-hours of internal planning time spent managing the gap between the system and the parallel files.
Forecast accuracy, the headline metric, had improved by 4 percentage points from baseline. Inventory had reduced by 8% in two markets and increased by 3% in one market where the promotional history issue had caused over-ordering before the fix was deployed. The financial integration was working cleanly in four of six markets.
The programme director called this a partial success. He was probably right. It was also not what was promised, not what was bought, and not what the $5.3 million of total cost justified.
The lesson is not that IBP doesn't work. The lesson is that the implementation contract prices the technology and the go-live. The transformation is priced separately — in executive time, internal resource, process redesign, and incentive adjustment — and that price is rarely quoted upfront.
Sources
- Panorama Consulting Group. (2023). 2023 ERP Report. Panorama Consulting.
- Gartner. (2023). Market Guide for Supply Chain Planning Solutions. Gartner Research.
- Gartner. (2022). "Top Reasons Supply Chain Planning Implementations Fail." Gartner Research Note.
- Boston Consulting Group. (2023). "Digital Supply Chain Transformation: Why Most Fail and How to Succeed." BCG.
- McKinsey & Company. (2018). "Unlocking success in digital transformations." McKinsey Digital.
- Oliver Wight International. (2023). IBP Maturity Assessment Framework. Oliver Wight.
- ASCM. (2022). Supply Chain Resilience and Digital Readiness Report. ASCM.
- Wallace, T. F. (2004). Sales & Operations Planning: The Executive's Guide. T.F. Wallace & Company.
- Cecere, L. (2022). Supply Chain Metrics That Matter. Supply Chain Insights LLC.
- Lapide, L. (2011). "IBP: Not your father's S&OP." The Journal of Business Forecasting. 30(3).