Five Signs Your Company Needs SAP Advisory Services Before Starting Any New Project

In 60 seconds

• ✔ Before starting another SAP project, make sure you understand why the current one is not delivering the value you expected.
• ✔ If two or more warning signs below exist, get a health check first.
• ✔ Most SAP problems are process, trust, and adoption problems — not technology problems.
• ✔ A focused assessment helps you decide whether to fix, finish, or build.

You usually don’t start a new SAP project because the last one finished well. You start because something still hurts — and a new project feels like the cure.

The trouble is, a new build on top of an unresolved one inherits every flaw underneath it. You end up paying for the same mess twice: in licence spend, in consulting fees, and in the working capital your processes quietly burn through in the meantime. And there’s a timing cost most business cases miss. Every month a workaround survives; it hardens into “how we do things”, and the next project has to fight that habit before it delivers a dollar of value.

The five signs below come from operational patterns we see again and again. If two or more feel familiar, it’s worth pausing for honest advice before you sign anything.

Sign 1: Your IBP forecasts are off, and planners have quietly gone back to Excel

What it looks like: Statistical forecasts in SAP IBP run 25–30% off actuals. Demand planners no longer open the planning view to make decisions. The real plan lives in a shared spreadsheet that one person maintains — and everyone downstream trusts that file more than the system.

Why it matters: A sustained 25–30% forecast error is never just a planning problem. It shows up as cash — excess inventory and write-downs on slow movers, expedited freight and lost orders on the items you under-forecast. The same error rate planners shrug off is, on the finance side, working capital stuck on one shelf and revenue walking out the door on another.

Why it happens: IBP rarely fails because the tool is weak. It fails because the inputs are wrong — poor master data, unclean sales history feeding the models, the wrong forecast model on the wrong demand pattern, promotions and outliers never modelled, and no one owning the model lifecycle after go-live. The maths is fine but the problem is usually the model that is being fed.

The Advisory starts by measuring forecast error and bias by using measures like MAPE or WMAPE rather than gut feeling. From there, it looks at how different products actually behave, cleans up the demand history and adjusts which forecasting models are being used. This isn’t about building a prettier dashboard. It’s about getting planners to trust the number again, so the spreadsheets quietly retire on their own.

From the floor: how this plays out

A mid-sized discrete manufacturer had gone live on SAP IBP a couple of years earlier. The S&OP deck looked polished, but the planning team had stopped using the system for daily decisions. One master Excel file ran the operation, kept alive by a single planner — who was, of course, on leave the week we arrived. As one demand planner put it: “I don’t even look at the system number anymore.”

The forecasts weren’t broken so much as starved. The sales history still included a pandemic spike and a discontinued product line, but nobody had cleaned it up or reviewed the model assignment since going live by cleaning the history, re-segmenting the portfolio and re-tuning the models.

Over the next quarter, forecast errors fell from 28% to approx. 12% and more importantly, the planners started checking the system first instead of going straight to the spreadsheet.

The SAP Trust Gap: a simple way to read the warning signs

Most of these signs are symptoms of one thing — the slow erosion of trust between your people and your SAP system. We call it the SAP Trust Gap, and it moves through four stages:

┌──────────────────────────────────────────────┐
│ STAGE 1 — TRUST │
│ Users plan and decide inside SAP. │
│ It’s the single source of truth. │
└──────────────────────────────────────────────┘
↓
┌──────────────────────────────────────────────┐
│ STAGE 2 — DOUBT │
│ Users still use SAP, but double-check │
│ key numbers in spreadsheets “just in case”. │
└──────────────────────────────────────────────┘
↓
┌──────────────────────────────────────────────┐
│ STAGE 3 — BYPASS │
│ The real work moves to Excel. SAP becomes │
│ a record people update after the fact. │
└──────────────────────────────────────────────┘
↓
┌──────────────────────────────────────────────┐
│ STAGE 4 — ABANDONMENT │
│ Users ignore SAP outputs entirely. │
│ The value has left the building. │
└──────────────────────────────────────────────┘

Here is why it matters: starting a new project when you are still at Stage 3 or 4 does not close the trust gap. It usually makes it worse.

Knowing where you actually are changes the decision in front of you. You may need to build or fix what is already there.

Sign 2: Your last go-live happened, but half the functionality is switched off

What it looks like: The project was declared live. Yet key capabilities — automated availability checks, constraint-based supply planning, advanced close steps — were quietly disabled because they “weren’t working right”, and no one came back to fix them.

Why does it happen: This usually happens when too much is taken into a go-live, testing gets squeezed, and hypercare finishes before things have really settled down. It is something we see quite often with S/4HANA migrations from legacy ECC, especially when the amount of process change involved has been underestimated. Features get switched off to hit go-live, the team moves on, and “temporary” becomes permanent. You’re now paying for the licence and maintenance for the capability you bought but never used.

What advisory does: A value-realisation review inventories what was scoped versus what’s actually running, flags the dormant functionality worth reactivating, and sequences it by business impact. More often than not, the highest return isn’t a new project. It’s finishing the one you already paid for.

Sign 3: Every small change needs an expensive outside consultant.

What it looks like: A minor change — a new pricing condition, a report tweak, a workflow adjustment — turns into a statement of work and a multi-week external engagement, because no one internally understands how the system was built.

Why it happens: Knowledge transfer never really happened at go-live. The build is buried under heavy custom (Z) code that strays from SAP standard, and documentation is thin. This is technical debt in its most expensive form — every customisation is a future bill, and every contractor who leaves takes institutional memory with them.

What advisory does: Good advisory reduces your dependency rather than increasing it — mapping and trimming unnecessary custom code, transferring real knowledge to internal staff, and helping you stand up a small internal Centre of Excellence so routine changes stop being billable events.

Sign 4: Month-end close is slow and managed together by manual workarounds

What it looks like: The process drags on for days.Teams reconcile across modules by hand, export to spreadsheets, and re-key numbers because the system views don’t tie out.

Why it happens: The close process was never fully designed in the system — integration gaps between modules, incomplete configuration, and standard tooling (like the Financial Closing cockpit in S/4HANA) were left unused. Reporting gets pulled into spreadsheets because SAP Analytics Cloud or standard reporting was never set up against the close. So people bridge the gaps by hand, every single period.

What advisory does: A close assessment finds where the process breaks, closes the integration and configuration gaps, and brings the standard automation into play. Success is not complicated to measure: less manual steps, less spreadsheets and a month end close that finishes on time without everyone having to scramble.

Sign 5: You are starting a new project, but nobody agrees on why 

What it looks like: The budget exists and the project is being scoped, but ask three leaders what success looks like and you get three different answers. There’s no agreed business case and no measurable outcome.

Why it happens: The project starts because of a technology requirement or external pressure, such as “we need to move to S/4HANA”, rather than a clear business problem that needs fixing. Without agreed goals and KPIs, the scope can keep changing, and by the time the project is finished, people are judging it against expectations that were never properly agreed in the first place.

What advisory does: Before any build, advisory defines the business case, the measurable outcomes, and a realistic scope — so the project is steered toward results everyone agreed on, not toward an expensive deliverable nobody can call a win.

What good SAP advisory looks like (and what to watch out for)

Here’s the honest part. A Good advisory is willing to tell you the truth, even when the truth is, “You don’t need a new project right now — you need to fix and finish what you already have.” It’s measured by whether your problem is solved and your dependency is reduced, not by how large the next engagement is.

Be cautious of any firm whose every assessment ends with the same prescription: another big implementation. That’s the tell. The real value of advisory is judgement — knowing when to build, when to repair, and when to do less. If the advice always points toward more billable work, it isn’t advisory. It’s a sales pipeline wearing a consultant’s badge.

What a credible SAP health check actually reviews

A real health check isn’t a sales call in disguise. It’s a structured assessment across six areas:

• Process — Are your core processes running in SAP as designed or worked around?
• Data quality — is master and transactional data clean enough for the system to be trusted?
• User adoption — are people actually using the system or quietly bypassing it?
• Integration — do the modules and connected systems tie out, or do you need manual bridging?
• Custom code — how much technical debt is baked in, and how much can be retired toward standard?
• Governance — a clear picture of who owns the changes, the decisions, and the roadmap of moving forward?

The difference advisory makes

Quick self-check: where does your SAP environment stand?

Answer yes or no:

• Forecasts are frequently overridden or rebuilt in Excel.
• Functionality was disabled after go-live and never switched back on.
• Routine changes require an external consultant.
• Month-end close depends on spreadsheets and manual reconciliation.
• Leadership can’t agree on the goals of the next project.

If you answered yes to two or more, your SAP environment is likely sitting in the Trust Gap — and a focused assessment would probably pay for itself quickly.

Frequently asked questions

What is an SAP health check? A focused review of your existing SAP landscape — system, processes, data quality, and adoption — to find where value is leaking and what’s worth fixing. It’s diagnostic, not a sales pitch.

How is SAP advisory different from SAP consulting? Advisory helps you decide what to do and why — strategy, business case, priorities. Consulting and implementation handle the how — the build and configuration. Good advisory is honest enough to recommend doing less when that’s the right call.

What causes IBP forecast inaccuracy? Usually not the algorithm — it’s unclean sales history, wrong model assignment, unmodeled promotions and outliers, and no one owning the model lifecycle after go-live. Fix the inputs and accuracy usually follows.

Why do SAP users go back to Excel? Because they’ve lost trust in the system’s numbers. Once a planner is burnt by a bad figure, they build a spreadsheet to feel safe — and that habit spreads. It’s a trust problem before it’s a technical one.

What is SAP technical debt? The accumulated cost of customisations, workarounds, and shortcuts that stray from standard. Like financial debt, it charges interest — slower changes and higher consulting bills over time.

Should we repair our current systems or migrate to S/4HANA? Depends on the situation. Sometimes the issue is process and adoption, which a migration won’t fix on its own. An assessment establishes S/4HANA readiness and tells you what to repair first.

How long does a health check take? Typically around two weeks, depending on scope and complexity. It’s short by design — enough to find the real issues, not a drawn-out project in itself.

Not sure which of these signs apply to you?

If two or more felt familiar, that’s worth taking seriously before the next project gets funded.

In a two-week SAP health check, SCM Champs identifies the top process, data, and adoption issues stopping your SAP investment from delivering value — and hands you a prioritised, plain-language picture of whether you should fix, finish, or build. No pressure, no commitment, and no default recommendation to start over.

Why SCM Champs

Our consultants bring more than 10 years of hands on SAP experience and are SAP certified. Our strongest areas are SAP S/4HANA, EWM, TM, PP and MM, covering the warehouse, transport, production and materials processes where issues can quickly turn into higher costs.

We work across manufacturing, automotive, retail, consumer goods, pharmaceuticals and other major industries. If your SAP system is not delivering the results you expected, we can help you figure out why. 

Sometimes you don’t need a new project at all but just to repair an existing one

Book your free 20-minute SAP health check call