Insights - Enterprise Transformation

Why Manufacturing SAP Implementations Fail (And How To Prevent It)

The failures that make headlines are the cancellations and the budget overruns. The failure that quietly drains value across Nigerian and African manufacturing is different: the system goes live, the consultants leave, and the transformation never arrives. Here is why that happens, and the disciplines that prevent it.

Somewhere in Nigeria right now, an executive committee is reviewing a proposal for a "value realization initiative" on an SAP system that went live two years ago. Nobody in the room calls the original project a failure. It hit its go-live date, more or less. The system runs. Invoices post. And yet the Chief Executive Officer (CEO) is asking the question every implementation partner dreads: what exactly did we get for all that money? Month-end close took two weeks before the project; ten months after go-live it takes eleven days. The CEO and the Chief Operating Officer (COO) still receive the same reporting packs, still prepared manually in spreadsheets. The powerful SAP that was marketed to the board has not been experienced by the business. That, not the spectacular cancelled programme, is the failure mode most executives will actually live through, and it is the one this article is about.

The Two Faces of Failure

The research on Enterprise Resource Planning (ERP) programme failure is sobering and remarkably consistent. McKinsey estimates that three-quarters of ERP transformation projects fail to stay on schedule or within budget, and that two-thirds deliver a negative return on investment. Across large-scale organisational transformations more broadly, the success rate has been stuck around 30 percent for as long as the question has been studied. Panorama Consulting's 2026 ERP Report finds more than a quarter of projects over budget and almost a quarter over schedule, with organisational issues, not technology, cited as the leading cause of timeline overruns.

Those numbers describe the first face of failure: delivery failure. The programme consumes more money and time than planned, scope gets cut in flight, and in the worst cases the initiative is cancelled or restarted. Every seasoned executive has seen or heard of one, and an entire industry of project assurance exists to prevent it.

But there is a second face, and in our experience delivering and rescuing SAP programmes across Nigerian manufacturing, it is the one that destroys more value: transformation failure. The project finishes. The system works, technically. Yet the organisational transformation the board was sold never materialises. The same manual reconciliations survive. The same parallel spreadsheets persist. The same month-end grind continues at nearly the same length. Executives express it in a phrase we have heard in more than one boardroom: "SAP has not delivered value for the investment." The tell-tale symptom is the corrective programme that follows, usually badged a value realization initiative, which is the organisation paying a second time for outcomes the first programme was supposed to deliver.

The distinction matters because the two failures have different root causes. Delivery failure is mostly a management problem: governance, estimation, scope discipline, vendor performance. Transformation failure is an alignment problem, and it is fully compatible with a project that was, by delivery standards, a success. McKinsey's transformation research makes the point starkly: even organisations that call their transformations successful capture only 67 percent of the value available to them; everyone else captures 37 percent.

The Scale of the Problem, in Numbers

These are not opinions. They are published benchmarks from independent research, and they frame every recommendation in this article.

Note the last row. The fastest-growing category of third-party help that organisations buy is help realising benefits after the implementation is over. That is the global market quietly confirming what Nigerian executives already know: the gap between go-live and value is where programmes are actually failing.

Anatomy of the Value Gap

Why does a technically successful SAP implementation fail to transform the business? Across the programmes we have delivered, inherited and repaired, five root causes recur so reliably that we now treat them as a checklist. Each one opens the gap between the value the board expected and the value the business experiences, and each one is preventable.

1. Success was never actually defined

Most organisations embarking on an SAP-driven transformation are vague about what success means at any level of detail that could be engineered. Ask for the objective and the answer is a buzzword: "best practice", "world class", "a single source of truth". What the future organisation, its processes, its people and its ways of working should actually look like, process by process, is never written down. The programme is conceived as an SAP implementation when what the board is paying for is an SAP-driven business transformation, and nobody notices the difference until after go-live, when the difference is the only thing anybody can see.

This is how a company goes live and finds that month-end close has moved from two weeks to eleven days, a result that is simultaneously an improvement and a failure, because nobody ever specified that the target was five days, or identified which reconciliations, data disciplines and cutoff behaviours would have to change to get there. It is how a CEO ends up receiving the same manually assembled reporting pack on a system that was sold partly on real-time analytics. When executives cannot articulate what has changed, they conclude, reasonably, that nothing has.

The prevention is disarmingly concrete. On a greenfield S/4HANA programme for a Nigerian food and beverage group, we facilitated a discovery exercise that ended with each process owner answering one question on record: what are the top three to five outcomes we want from this process area? The answers were specific and personal: all planning will be done in the new system alone, and Microsoft Excel will no longer be used to present planning data; one consolidated purchase order per vendor across all locations instead of dozens raised store by store; materials required by production converted automatically into purchase proposals, with the manager comparing prices and approving rather than typing. Each statement is testable. Each has an owner. A programme with fifty such statements has a definition of success. A programme with none has a licence bill.

2. The contract buys deliverables, not outcomes

Look at the Statement of Work (SOW) behind most SAP implementations and you will find it is a list of deliverables: Business Process Design (BPD) documents, configuration workbooks, test scripts, training materials, sign-offs. All necessary. None of them is the point. A System Integrator (SI) under time and cost pressure will rationally go through the motions and produce every deliverable on the list, and the deliverables can all be accepted while fifty real supply chain pain points, the aged process blockers the business actually suffers from, are never identified, never designed away, and never priced in terms of the efficiency they would unlock.

McKinsey identified this exact dynamic as one of the five structural reasons ERP transformations fail: activities and deliverables drive the programme, when business value, quantified, documented and monitored, should. We would add an uncomfortable observation from the field: on several projects we have reviewed, the SI's process consultants did not deeply understand the client's business or its value levers. They knew SAP. They did not know why the client's working capital was trapped, where its margin leaked, or which manual controls existed because a control once failed.

You cannot solve for what you do not understand.

The prevention is to invert the contract. Before the SOW is written, build a register of problems and opportunities per functional area, each with an estimated value: hours saved, Full-Time Equivalent (FTE) capacity released, days of working capital freed, partner satisfaction unlocked. Then tie the SOW to that register, so the SI is engaged to resolve named problems with estimated values, not merely to produce documents. This changes the flavour of the entire project. Design workshops stop being theoretical walkthroughs and become decisions about specific pain points; the rationale for every design choice is clear; and all stakeholders, client and consultant alike, are solving for outcomes rather than sign-offs.

3. Enablement is an afterthought, so users retreat to the familiar

We have seen implementations run for eighteen months, only for an end user to receive five days of training at the end of it. Many programmes spend about fifty weeks preparing the technology and fewer than ten days preparing the people who must operate it. The user is confronted at once with a new interface, new process flows, new screen sequences, new controls and new terminology, and before any of it can be digested, the training is over and the trainers are gone. What happens next is entirely human: users seek refuge in the familiar. The parallel spreadsheet returns. The manual register reappears. The old approval memo survives alongside the new workflow. And every one of those retreats subtracts directly from the transformation the system was supposed to deliver, because the system and its processes will only ever be as good as their operators.

In the Nigerian context two local realities sharpen the problem. The first is attrition: trained super users are precisely the people most likely to be poached, or to leave the country altogether, taking the programme's knowledge investment with them unless it has been institutionalised into content, curriculum and a continuous-learning structure. The second is hierarchy: in deferential organisational cultures, users who are struggling rarely say so in a classroom or to a visiting consultant. Silence gets read as readiness. It is usually shock.

The prevention is to treat people enablement as a full workstream of equal rank with configuration, running the entire length of the programme rather than its final month. In enablement programmes we have designed for large Nigerian enterprises, that means: identifying every impacted learner group, internal and external, and mapping business change impacts into role-based learning needs; a blended curriculum built on repeated, practical, real-life simulation of actual business transactions rather than hurried theoretical walkthroughs; formal knowledge checks with target proficiency levels before go-live; and, critically, floor-level support and on-the-job handholding after go-live, when the "depth of despair" is at its deepest and habits are actually formed. Adoption should then be measured, not assumed, by checking conformance to the new processes in the system data itself.

4. Garbage in, garbage live: the legacy data problem

No SAP system can transform an organisation that migrates its old chaos into it. Yet programme after programme loads unreconciled legacy transactional data into a pristine new environment and is then surprised when the same old problems continue: purchase orders that have been open for years; Goods Receipt/Invoice Receipt (GR/IR) clearing accounts with unreconciled items stretching back multiple financial years; fixed asset registers that do not agree with the physical estate; inventory balances that everyone quietly knows are wrong, propped up by write-offs that were never resolved; vendor and customer balances that neither party can confirm. Each of these is a small lie the organisation tells itself, and a new system does not make old lies true. It gives them a fresh database and a longer life.

The prevention is a data remediation workstream that starts before, and runs ahead of, the implementation itself: every data object, master and transactional, assigned to a named business owner accountable for its completeness and accuracy; aged open items reconciled or formally written off with governance sign-off before migration, not parked for "later"; and hard quality gates in the cutover plan that the programme is genuinely willing to enforce. Clean data is unglamorous, slow, and politically awkward, because reconciliation surfaces losses someone would rather not book. It is also the difference between a new system and a new start.

5. Go-live is treated as the end, when it is the beginning

The deepest cause of the value gap is a mental model: the belief that the transformation is delivered when the project closes. It is not. Go-live is when the real transformation, an actual change of ways, starts. Yet standard practice is that the SI packs up weeks after cutover, hypercare hands over to a reactive break/fix support desk, and the organisation is left holding a set of signed-off design documents that no one will ever read again. A break/fix desk answers tickets. It does not codify the signed-off designs into corporate policies and Standard Operating Procedures (SOPs). It does not monitor whether the business is actually complying with the new ways of working, or quietly reverting. It does not drive a pipeline of proactive improvements as the business learns the system's real capabilities. Nobody owns the value case anymore, so the transformation stalls, and then it rolls back.

Go-live is not the finish line. It is the starting gun, and most organisations leave the stadium at the gunshot.

The prevention is deliberate post-go-live transformation management, resourced and governed as seriously as the project itself. In the operating model we have run for a diversified Nigerian group over several years, that structure reports quarterly to a governance board drawn from executive leadership, and its remit goes far beyond support: codifying every signed-off design into policies and SOPs; measuring adoption business unit by business unit and intervening where usage decays; policing process compliance so workarounds die rather than breed; and running a continuous pipeline of improvement and digitalisation initiatives on top of the stabilised core, so the platform keeps compounding value years after the implementation partner has left. Panorama's finding that demand for post-implementation and benefits realization support has jumped from 28 percent to 42 percent in a single year suggests the wider market is arriving at the same conclusion, after the fact. It is far cheaper to arrive at it in the programme design.

Why It Bites Harder Here: The African Context

None of the five causes above is uniquely African. What the Nigerian and wider African operating environment does is amplify them, and a programme designed as if it were running in Frankfurt will be blindsided by realities that were never in the methodology.

Hierarchy filters the truth. In strongly deferential cultures, bad news travels upward slowly, softened at every level. Steering committees see green dashboards until the week they do not. Programme governance has to be designed for this: independent quality assurance, direct unfiltered channels to the sponsor, and leaders who visibly reward the bearer of bad news rather than shooting them.

Workarounds are an institution. Years of operating around unreliable systems, and unreliable infrastructure, have made the manual memo, the parallel register and the offline approval a respected survival skill. These instincts do not disappear at cutover; they compete with the new system for legitimacy. That is why process compliance must be actively managed after go-live, and why the transparency SAP brings, of stock positions, of spend, of aged balances, will be experienced by some stakeholders as a threat rather than a feature. Expect that, and manage it as the political change it is.

Skills walk out of the door. The emigration wave and a hot regional market for SAP talent mean the super users you train are a depreciating asset unless knowledge is institutionalised: documented processes in a living repository, role-based curricula that can onboard replacements quickly, and a core team deliberately sized for attrition.

Budgets are exposed to the exchange rate. Licensing and much consulting capacity is priced in dollars while benefits accrue in naira. Currency movements mid-programme squeeze exactly the budget lines that feel most discretionary, which are, invariably, enablement, data remediation and post-go-live support: the three disciplines this article has just argued decide the outcome. Protecting them in the business case, explicitly, is a C-suite responsibility.

The Prevention Playbook

The five causes yield five disciplines. Together they form a playbook we have applied and refined across Nigerian manufacturing, retail and consumer goods programmes, and the striking thing is how much of it happens before and after the implementation project that most organisations think of as "the programme".

Start with a Business Discovery, before any RFP

The highest-leverage intervention in the whole lifecycle is a short, business-driven Business Discovery sprint conducted before an SI is engaged and before a Request for Proposal is issued. An experienced SAP and business architect studies the current state of work at user level, sitting with the people who actually run the processes, walking the flows as they truly happen rather than as the procedure manual claims. On the programmes where we have championed this, for a Nigerian food manufacturer and a restaurant group among others, the discovery produced, in a matter of weeks: a process-by-process map of what actually runs in the current system, what runs partially, and what is fully manual; a register of named issues and gaps per process area; the improvement opportunities and system requirements that resolve them; and a "picture of success" for every process, in the owner's own words. That material reframes everything downstream. The RFP describes precise problems, not module lists. SI proposals can be evaluated on how convincingly they resolve the named issues. The SOW ties to outcomes. Fit-to-standard workshops start from documented reality rather than folklore. And the executive team holds, from day one, a concrete definition of the transformation it is buying.

Then hold the line through delivery and beyond

How Newen Helps

Newen works on both sides of the implementation project, which is exactly where the value gap opens. Before a programme, we run the Business Discovery: user-level current-state assessment, issue and opportunity registers per process area, pictures of success with owners on record, and RFP and SOW framing that ties your implementation partner to outcomes rather than documents. During delivery, we act as the client-side architect and quality assurance: keeping design decisions anchored to the discovery, running people enablement as a first-class workstream aligned with the SAP Activate methodology, and enforcing the data remediation gates that protect the new environment. After go-live, we design and, where wanted, operate the post-go-live transformation structure: codifying designs into policies and SOPs, measuring and driving adoption, policing process compliance, and running the improvement pipeline that turns a stabilised system into a compounding asset, all under a governance rhythm your board can hold to account.

We have delivered this playbook on greenfield S/4HANA implementations for Nigerian food and beverage manufacturers, on people-enablement programmes for large retail operations, and in multi-year post-go-live transformation management for a diversified Nigerian group. The pattern holds across all of them: when success is defined precisely, contracted deliberately, enabled seriously and managed past go-live, SAP delivers what the board was promised.

Sources: McKinsey & Company, "Agile in enterprise resource planning: A myth no more" (2019); McKinsey & Company, "Losing from day one: Why even successful transformations fall short" (2021); Panorama Consulting Group, "The 2026 ERP Report" (2026); Newen delivery experience across anonymised client engagements in Nigerian manufacturing, consumer goods and retail (2020-2026). Client-specific figures cited (for example, month-end close duration and training durations) are drawn from Newen project experience and are presented in anonymised form.