SAP Implementation: The Blind Spots That Decide Whether It Delivers

Most SAP implementation issues are predictable and tied to the same handful of blind spots that appear in implementation projects regardless of company size or industry. Knowing which issues you will face during a major implementation allows you, and business users on your customers’ side, to prepare for most of them or avoid them altogether.

Most project kickoffs focus on budgets and technical requirements. What gets less attention is governance and organizational readiness, even though these are often exactly the aspects that determine whether the project will succeed. Below are the issues that come up most often on SAP implementations, and what to do about them.

Start With the “Why” – And Make It Specific

It’s worth saying plainly: “we need to modernize” is not a clear enough reason to start an SAP project. Before anything else, the leadership team needs a concrete answer to the question: what will change in the business after this implementation?

It’s not about which features will be available or which modules will be live – it’s about what business outcome will look different, and how you will know when you’ve achieved it.

This matters more than it looks. Vague reasoning creates a project without a clear finish line, and, more importantly, without real motivation. Decisions get harder to make, priorities harder to agree on, and scope harder to control. A clear business outcome, on the other hand, becomes the north star that keeps everything – and everyone – aligned.

Also, every implementation needs an executive sponsor with real decision-making authority. Not a nominal role, not someone who attends the kickoff and checks in six months later. Someone at C-level, or one step below, who is genuinely available to serve as the project’s ambassador within the company, remove blockers, and make calls when the project needs them. When that person is missing or present only in name, decisions pile up, timelines slip, and eventually the project stalls.

Scope Is a Promise – Treat It Like One

Scope creep is one of the most common and most expensive issues in implementation projects. In most cases, it stems from unjustified assumptions.

As a delivery manager at ACBaltica, I’ve often seen that the business agrees to a scope without fully understanding what’s in it – and, more importantly, what isn’t. A few months in, someone usually says: “We thought that was included.” And because nothing was documented clearly enough at the start, there’s no easy way to resolve it.

The fix is straightforward, though a little unglamorous: every element of scope should be clearly defined, fixed in writing, and agreed by both sides before work begins. What’s in, what’s out, and – crucially – what happens if something needs to change later. Ambiguous language is a risk; it’s worth spending extra time to make even the obvious things explicit.

There’s also a broader recommendation: start smaller than you think you need to. The best implementations I’ve seen start narrow: a core set of processes goes live first, and scope expands from there based on what the team actually learns in production. Trying to do everything at once can feel efficient when you’re planning, but it’s usually how projects end up over budget and behind on their go-live date.

On an S/4HANA migration, most of that discipline comes down to one thing: not rebuilding every ECC customization just because it existed. Fit-to-standard and clean core aren’t abstract principles here. Every customization you carry forward is something you’ll have to maintain and re-test at the next upgrade, so the scope conversation is really a conversation about what you, and the project’s stakeholders, are willing to own for the next ten years.

The Customer’s Best People Need To Be Genuinely Available

Here’s something that almost every business underestimates: the people who make an implementation succeed are not the consultants. Instead, they’re the key users on the business side – the people who know processes from the inside and can make decisions about them.

These individuals cannot be selected because they happen to have the most free time. For such roles, the business should choose people who actually understand how the business works: an experienced finance manager, logistics lead, or operations expert. These are precisely the employees with the fullest calendars, and they need real, protected time to participate in the implementation. For the duration of the project, it will effectively be their second job.

So before the project starts, work out who’s needed, for which phases, and how much of their time it will actually take. That allocation has to be real. If you’ve decided a key user will give 30% of their time to the project, something has to come off their plate to make room for it; otherwise, the commitment exists on paper and nowhere else.

One more thing: these people need authority within their area of the business. If every decision they make has to be escalated upward, the project slows to a crawl. The key user should be the expert and the decision-maker for their domain, not a messenger between the project team and management. You should clearly agree on that with your project’s stakeholders.

Data Quality: Always Worse Than You Think

Almost every company thinks their data is well organized. The reality is almost always messier. Duplicate records, incomplete fields, legacy entries no one has touched in years, critical information stored in a spreadsheet on someone’s desktop. These are not edge cases; they are the norm.

SAP is demanding when it comes to data quality. That is why data migration is one of the most time-consuming parts of any implementation. Two things are worth doing as early as possible: conduct a realistic audit of master data (materials, vendors, customers, employees, fixed assets), and ensure you have a dedicated person or team to own the cleanup process from the customer’s side. This is not something that can be handled on the side. It requires focused effort over a sustained period.

Starting the data audit early gives you time to find the problems before they become go-live blockers.

Change Management Is Not a Communications Exercise

Very often, implementations that are technically successful still fail because the people who are supposed to use the system aren’t ready, aren’t willing, or weren’t told what was coming until it was too late.

Change management often gets treated as a box to tick: an announcement goes out, a training session gets scheduled, the system goes live. Then people quietly build their own workarounds, and the resistance you were trying to avoid shows up anyway. What actually works is communicating the benefits of the ongoing implementation as early and clearly as possible to every team member involved.

For example, for a finance team member who has been doing things a certain way for 15 years, “digital transformation” means very little. But if you explain that the period closing that currently takes three days will now take hours, the same finance team member will have way less resistance.

People often resist change not because they’re difficult, but because they don’t see what’s in it for them. They might worry that automation will make their role redundant, or simply dislike uncertainty. Clearly explaining that to system users is not exactly the consultant’s role – but make sure business leaders do that.

Training also matters more than most projects budget for. A walkthrough of the system is not the same as training. People need to practice in a test environment before go-live, not read a manual after it.

Build a Realistic Budget – And Add a Buffer

The cost of an SAP project does not consist only of licenses and implementation fees. It also includes consultations, training time, productivity dips during the transition, potential overtime for business teams, post-go-live support, and any integration work that surfaces mid-project.

A budget built without a contingency reserve will definitely cause problems. In practice, scope and timelines almost always shift during implementation – not because of poor planning, but because some things simply cannot be known until the work is underway. A 15–20% contingency on top of the initial estimate is a reasonable buffer, not a sign of pessimism.

It’s also worth agreeing upfront on who makes the go/no-go decision at launch and what criteria they’ll use. Having this conversation after six months of work, under pressure, is much harder than having it at the start.

Define “Done” Before You Begin

Success criteria need to be defined before the project starts. Not in vague terms, but in specific, measurable ones. How fast does a particular report need to run? What does the order-to-delivery cycle look like after go-live? How many manual steps should be eliminated from a process?

Without defined criteria, there’s no shared understanding of what a successful outcome looks like, which creates real problems when the project is nominally “complete” but the business isn’t satisfied.

The same applies to the post-go-live period. Who is responsible for what after the system goes live? What does hypercare look like, and for how long? Who do end users contact when something doesn’t work? These questions are easy to answer before go-live and surprisingly difficult to answer after it.

A Final Thought

None of these challenges is a reason to avoid an SAP implementation. They’re the things worth getting right so the project actually delivers what the business case promised.

The companies that navigate implementations well tend to have a few things in common: they’re honest about their organizational readiness, they protect the time of their best people, and they treat the project as a business initiative – not just a technology one.

Andrei Karpovich is a Delivery Manager at ACBaltica, an SAP Platinum Partner, where he leads cross-functional SAP delivery spanning MM, FI, BI/BW, BPC, ABAP, and CRM. He runs multiple concurrent implementations as the single point of accountability for delivery, with a PMBOK-driven approach to scope, risk, and budgeting. He holds an MSc in Economics and Management and is PSM I certified.