Why Most SAP Business One Projects Fail Before Implementation Even Starts
Try It For Free

Blog

Why Most SAP Business One Projects Fail Before Implementation Even Starts

By IngoldMay 18,2026
Here is something most SAP Business One partners will not tell you upfront: a lot of ERP projects are already in trouble before the first workshop takes place.  Not because the software is wrong for the business. Not because the implementation team is incompetent. But because the business signing the contract has not yet done the internal work that makes implementation possible. They have selected a system before understanding their own processes. They have started a project without deciding who inside the business actually owns it. They have agreed to a go-live date based on a feeling rather than a realistic assessment of what needs to happen first.  The research on this is blunt. According to Gartner, more than 70% of ERP implementations fail to reach their original business case goals. A separate analysis found that only 23% of companies complete their ERP project on time and within budget. And when researchers look at where exactly these projects go wrong, the answer is almost always the same: the failure was baked in before the technical work began.  70%+  of ERP projects fail to reach their original business case goals — Gartner  At Ingold Solutions, we have worked with businesses across the DACH region and beyond as a certified SAP Business One partner for years. The projects that struggle are rarely the ones where the software proves difficult. They are the ones where the business turned up to implementation without having genuinely prepared. What follows is an honest account of the five pre-implementation failures we see most often — and what addressing each one actually looks like in practice. 

  1. The Process Map That Does Not Exist

Ask most business owners to describe how a purchase order moves through their organisation and they will give you a confident answer. Ask four different people in that same organisation the same question and you will get four different answers. None of them will be wrong, exactly. But none of them will be the same.  SAP Business One implementation begins with configuring the system around your actual business processes. If those processes are not documented — not ‘roughly understood’ or ‘mostly consistent,’ but actually written down and agreed upon — the configuration work cannot happen properly. The implementation team ends up configuring the software around what different people think the process is, rather than what it should be. That produces a system that works for no one department particularly well and creates arguments at go-live about why things do not behave as expected.  The most common version of this problem is the gap between documented policy and actual practice. A business might have a three-level purchase approval policy on paper. In reality, the operations manager approves everything themselves because the system that was supposed to enforce the policy was too slow. Implementing SAP around the documented policy produces a system that clashes with how people actually work. Implementing it around actual practice means building in a workaround as the foundation.  Pouring modern technology over bad processes is a recipe for failure. If you don’t fix underlying processes first, technology will simply accelerate existing inefficiencies.  A good SAP Business One consulting engagement insists on process mapping as a prerequisite, not a deliverable. That means sitting with the people who do the work — not just the managers who describe it — and building a shared understanding of what the process actually is before any configuration begins. It is slower upfront. It avoids months of rework later. 

  1. Nobody Has Decided Who Owns the Project

ERP projects need an internal owner. Not a sponsor who attends the steering committee. Not a project manager who books the meeting rooms. Someone with real authority over business decisions, adequate time allocated to the project, and the seniority to resolve internal disagreements when they arise.  In practice, what often happens is that ownership is assumed rather than decided. The IT manager assumes it is a technology project. The finance director assumes it is an accounting upgrade. The operations lead assumes someone else is handling it. The result is a project that moves at the speed of whoever can be assembled in a room at any given moment, with decisions deferred because the right person is not available, and scope changes slipping through because nobody is formally accountable for saying no.  According to industry data, 72% of failed ERP projects can be traced back to poor stakeholder management. That statistic covers everything from absent executive sponsorship to conflicting departmental priorities — but at its core, it reflects the same problem: nobody was clearly in charge.  72%  of failed ERP projects are attributable to poor stakeholder management — WorldMetrics 2024  A capable SAP Business One partner will make internal ownership a non-negotiable condition of the project structure. The internal project owner needs to be named, their time commitment confirmed, and their authority over decisions made explicit before the engagement begins. Without that, even the best-planned implementation will stall at the first disagreement between departments. 

  1. The Expectation That Software Fixes Broken Processes

Lidl spent €500 million and seven years trying to implement SAP before abandoning the project entirely. One of the core reasons cited was a refusal to adapt internal processes to the way SAP was designed to work. The retailer wanted heavy customisation to replicate what their old system did rather than rethinking the process itself. After nearly half a billion euros, the project was scrapped.  That is an extreme example. But the underlying assumption — that the ERP should bend to match existing habits rather than the business adapting to better-designed processes — is one of the most common reasons SAP Business One implementations run into difficulty.  The expectation usually surfaces in discovery workshops. A department head says: ‘Our current system does X this way, so SAP will need to do X the same way.’ Sometimes that is reasonable. Often, the current system does X in a particular way because it was designed in 2009 around a specific limitation that no longer exists. The workaround has become the process, and nobody has questioned it in fifteen years.  SAP Business One is an opinionated system. It has a logic to how financial postings work, how inventory moves, how purchasing approvals flow. That logic is based on decades of accumulated best practice across thousands of SMB implementations. Businesses that come into the project willing to understand that logic and adapt where it makes sense have significantly better outcomes than businesses that treat every configuration decision as an opportunity to replicate what they have always done.  Unrealistic expectations also show up in project timelines. Businesses frequently anchor on a go-live date that was set before anyone understood what the implementation would require. When the actual scope becomes clear, there is reluctance to adjust the date. That reluctance leads to rushed configuration, skipped testing cycles, and go-live on a system that has not been properly validated. 

  1. The Data Quality Problem Nobody Wants to Look at Directly

Almost half of all ERP implementations — 48% according to published research — experience significant data migration problems. Given how consistently this figure appears across studies, it deserves more attention than it typically gets in pre-sales conversations.  The data quality problem tends to follow a predictable pattern. A business has been running on a legacy system for several years. During that time, supplier records have been duplicated, product codes have been applied inconsistently, cost prices are missing or incorrect on older stock items, customer accounts contain outdated contact information, and historical transaction data has accumulated errors that nobody has ever needed to resolve because the old system could tolerate them.  Moving this data into SAP Business One does not clean it up. SAP will accept what it is given. If you migrate 3,000 business partner records and 400 of them are duplicates, you will have 400 duplicate business partners in SAP from day one. If your product master data has cost prices missing, your margin reporting will be wrong from the first week of operation. If your opening stock balances are inaccurate, every inventory report you produce for the first several months will be unreliable.  One manufacturing company discovered their inventory data was so corrupted they couldn’t trust basic stock levels. Products listed as available didn’t exist. Items marked as discontinued were their best sellers. The ERP worked perfectly — with garbage data.  Addressing this requires a data audit before the migration project begins, not during it. That means extracting the current data, reviewing it systematically, cleaning and standardising it, and only then planning how it maps into the SAP data model. Ingold Solutions treats this as a distinct workstream within every SAP Business One implementation, not a task to squeeze into the final weeks before go-live.  48%  of ERP implementations experience significant data migration issues — WorldMetrics 2024 

  1. Departments That Have Not Been Part of the Conversation

SAP Business One touches every part of the business. Finance, purchasing, inventory, sales, warehouse operations — all of these functions interact with the system and with each other through it. Yet it is remarkably common for the implementation scoping conversations to happen primarily with the finance director and the IT manager, while the warehouse team, the purchasing team, and the sales department find out what has been decided when the training sessions begin.  The result is a system configured around the priorities of the people who were in the room rather than the requirements of the people who will use it daily. The warehouse team discovers that the picking workflow does not match the way they actually operate. The sales team finds that the quotation template does not include a field they have always used. The purchasing team realises that the approval matrix is configured for how the finance director thought purchasing worked, not how it actually does.  These problems are entirely fixable — but fixing them after go-live is far more expensive and disruptive than addressing them in the design phase. Change requests after go-live carry cost, delay, and the frustration of staff who feel the system was built without them.  Proper stakeholder alignment means bringing every affected department into the scoping conversation before configuration begins, even if those conversations are difficult. It means surfacing the differences in how each team understands a shared process and resolving them in a document rather than in a live system. It means defining what ‘success’ looks like for each department, not just for the project sponsor. 

What a Serious SAP Business One Partner Does Differently 

The five failures above share a common thread: they are all decisions made, or avoided, before any technical work begins. The partner selection conversation therefore matters enormously, and it should be evaluated not just on cost and timeline but on how much the partner is willing to push back.  A partner that tells you implementation can begin in four weeks without asking how your processes are documented, who your internal project owner is, or when you last looked seriously at your data quality is not saving you time. They are deferring the problems to a moment when they will be much harder to solve.  At Ingold Solutions, our approach to SAP Business One consulting begins with a structured discovery phase that covers process mapping, project governance, realistic timeline assessment, and a data readiness review before a single system configuration decision is made. We are a certified SAP Business One partner with ISO 9001 and ISO 27001 accreditation, and our implementation methodology is built specifically around the SMB context — businesses where a failed ERP project does not just miss a milestone, it genuinely threatens operations.  The businesses that get the best outcomes from SAP Business One implementation are not necessarily the ones with the most sophisticated technical requirements. They are the ones that do the unglamorous internal work before the project starts: mapping their processes honestly, appointing a genuine owner, setting realistic expectations, cleaning their data, and making sure every affected team has been in the room.  Getting that groundwork right is not the partner’s job alone. But it is absolutely the right partner’s job to insist on it. 

Recent Posts

Why Most SAP Business One Projects Fail Before Implementation Even Starts

May 18,2026

SAP Business One Cloud: What Competitors Are Not Telling You

May 15,2026

Why SAP Business One Cloud Is Not Just IT Infrastructure — It’s a Revenue Engine

April 28,2026