The Statistics
The numbers are sobering. According to research from Gartner and McKinsey, roughly 70% of SAP implementations fail to meet their original objectives — whether that's timeline, budget, scope, or business outcomes. These aren't small projects. SAP S/4HANA implementations routinely cost $10M-$100M+ and span 12-36 months.
The Famous Failures
Lidl — $500M Written Off
German retailer Lidl spent seven years and an estimated $500 million attempting to replace their custom inventory management system with SAP. The project was ultimately abandoned. The core issue wasn't technology — it was a fundamental disagreement about whether to adapt business processes to SAP standard or customize SAP to match existing processes.
Hershey's — The Halloween That Wasn't
In 1999, Hershey's went live with SAP just before their peak shipping season. The result: $150M in lost sales during the Halloween and holiday period. Orders couldn't be processed, shipments couldn't be tracked, and retailers' shelves sat empty. The root cause was an aggressive go-live timeline that didn't allow sufficient time for testing and stabilization.
HP — $160M ERP Failure
HP's centralized ERP project resulted in a $160M hit to revenue. The failure was traced back to data migration issues and inadequate integration testing between SAP and legacy systems. Problems that should have been caught in testing appeared in production.
The Real Root Causes
These high-profile failures share common patterns. The causes aren't usually technical. SAP works. The technology is proven. What fails is the governance, the process, and the tooling around the implementation.
1. Requirements Drift
Decisions made during fit-to-standard workshops in the Explore phase are forgotten by the time the Realize phase begins. A business process owner agreed to a process change in March. By July, nobody remembers the agreement, and the development team builds a RICEFW that was never supposed to exist.
Requirements drift happens because workshop outcomes live in Word documents, meeting notes, and email threads. Three months later, these artifacts are effectively invisible. Without a structured system that captures every decision with full context and traceability, drift is inevitable.
2. RICEFW Sprawl
A well-governed project should have 80-120 RICEFWs for a mid-size implementation. Poorly governed projects end up with 200+ custom objects because:
- Fit-to-standard workshops weren't prepared properly
- The solution architect wasn't challenging unnecessary customization
- There was no approval gate for new RICEFWs
- The PMO didn't have visibility into RICEFW growth until it was too late
Every additional RICEFW costs $30,000-$80,000 when you factor in functional specification, technical specification, development, unit testing, integration testing, UAT, documentation, and ongoing maintenance through SAP upgrades.
3. Testing Gaps
Testing is where most SAP implementations are most exposed. The typical pattern:
- Test scripts are written in Excel
- Test execution is tracked in a spreadsheet or a generic tool like Jira
- Defects are logged separately with no direct link to the test case that found them
- There's no traceability from the defect back to the RICEFW or user story it affects
- UAT sign-off is a formality because nobody has the data to make an informed decision
The result: defects that should have been caught in FUT or SIT make it to production. Integration issues between modules are discovered after go-live. The business goes live with untested edge cases.
4. PMO Visibility Failure
On most SAP projects, the PMO's view of project health is based on status reports — compiled manually, presented weekly, and always at least a few days behind reality. The PMO learns about a RICEFW approval backlog in a steering committee meeting, not from a real-time dashboard.
This lag means problems are identified late and solved reactively. A RICEFW that's been blocked for three weeks doesn't appear as a risk until someone mentions it in a status meeting. A test cycle with a 40% failure rate doesn't trigger an escalation because the data is buried in an Excel tracker.
5. Knowledge Loss
SAP implementations run 12-36 months. Over that period, consultants roll off, business process owners change roles, and project team members move on. When they leave, their knowledge leaves with them.
The decisions they made, the context behind those decisions, the workarounds they designed — all of it exists only in their heads and in scattered documents nobody can find. The team that inherits the project spends weeks reconstructing context that should have been captured in a system of record from day one.
What Successful Implementations Do Differently
The projects that succeed share a common trait: they treat the implementation as a data problem, not just a technology deployment.
- Every decision is captured. Not in emails or meeting notes — in a structured system with full context and traceability.
- Every RICEFW has an approval gate. No custom development starts without PMO sign-off, T-shirt sizing, and a clear business justification.
- Testing is traceable end-to-end. Every test script links to a RICEFW or user story. Every defect links to the test case that found it. UAT sign-off is based on data, not gut feel.
- The PMO has real-time visibility. RICEFW status, testing progress, defect trends, approval backlogs — available in a dashboard, not a weekly email.
The System of Record Principle
The Lidl failure wasn't a technology failure. It was a requirements and governance failure. The technology worked exactly as configured — the wrong configuration.
The pattern across every SAP implementation failure is the same: critical information existed somewhere, but it wasn't accessible, structured, or connected in a way that allowed the right people to make the right decisions at the right time.
A system of record for SAP implementations means one place where every decision, every RICEFW, every test result, every approval, and every status change is captured and connected. Not as a reporting layer on top of disconnected tools — as the primary system where work happens.
Axia is the system of record for SAP implementations — connecting process flows, requirements, RICEFWs, testing, and decisions in one platform. Because the next SAP failure won't be a technology failure either.