What consultants actually do: a realistic view

SAP consultants configure, build, test and stabilise SAP for a business. In practice, most of their value is delivered mid-programme. They clarify scope that has drifted, run the walkthroughs nobody ran, triage UAT defects, and stabilise operations after go-live. Functional consultants own module configuration, technical consultants own extensions and integrations, and programme and change consultants own delivery and adoption. This piece is for leaders deciding whether to bring in outside help, and for people weighing consulting as a career. If you are a leader, the signals table below tells you when to call. If you are a consultant, the sections on the day-to-day show what the job really involves.

The question comes up every time someone weighs external support: what exactly is a consultant doing that we cannot do ourselves?

The honest answer is not especially flattering to the consulting industry. Most of the value comes from fixing things that should not have broken. From asking questions that should already have been asked. And from adding capacity and clarity at the moment the internal team runs out of both.

That is not a criticism of internal teams. It is how SAP programmes tend to run. The internal team is stretched. The systems integrator has its own priorities. Decisions pile up and scope drifts. Six months into a twelve-month programme, someone opens the issue log and finds twenty items marked "to be resolved" that have sat there since week three.

That is usually when the call comes in.

Some consultants are brought in during blueprint or planning. Many get the call mid-project, often after two or three months of slow progress or missed handoffs. The steering committee reports look orange. The team is working hard. Progress is slow and nobody can say exactly why.

1. ExploreWorkshops and gapsFit-to-standard workshops, gaps documented
2. RealizeBuild and walkthroughsConfiguration and extensions. Mid-project is when recovery calls usually come
3. DeployUAT triage and cutoverConfiguration, process or training gap? Triage decides
4. HypercareStabilisationThe first month-end close and the issue queue

The typical entry points:

1. Scope has drifted. What was signed off in Explore no longer matches what the build team is working on. Requirements were added informally in workshops, the change log was not maintained, and nobody has a definitive scope list.
2. A critical workstream has stalled. Data migration has been stuck at the same error rate for weeks with no plan to improve it. UAT is opening more defects than it closes.
3. The go-live date is fixed and the plan does not support it. The board set the date. The plan has not been reconciled with actual progress. The programme manager knows the trajectory misses the date but has not escalated yet.

In each case, the job is not to add people to the existing plan. It is to look at what is actually happening, name the problem plainly, and produce a path forward. My guide to getting SAP projects back on track covers that recovery sequence.

Scope and process clarification

Sometimes the configuration is right, but the process around it is broken. A common pattern: the team configured against a fit-to-standard document from Explore, and business users have not seen the configuration since sign-off. They were told what was being built, not shown it.

The fix is not technical. It is a conversation gap. The job is to walk business users through the configuration before UAT and produce a clear list of changes before testing opens.

That is not glamorous. It is what the work looks like.

Translating between technical and business teams

SAP programmes routinely produce something technically correct that the business cannot use. A pricing determination that works for 90% of cases and breaks on export orders. A goods movement that posts correctly but creates a financial document the reconciliation team does not recognise.

The functional consultant closes that gap. Not by being the most technical person in the room. By understanding the system behaviour and the business impact well enough that the right people can make the right decision.

UAT support

User acceptance testing is where a programme's accumulated decisions hold or fall apart. Every shortcut in Explore, every informal scope addition and every test case written at summary level surfaces here.

Good UAT support means triaging defects correctly, separating configuration gaps from process gaps from training gaps. It also means managing the temperature when business users hit a run of failures that shakes their confidence in the whole programme. Without that, every defect in a UAT session becomes a reason to question go-live, usually because triage was weak and nobody had defined what "go-live ready" meant.

Post-go-live stabilisation

The least glamorous work in SAP consulting is hypercare. Go-live happened, the celebratory emails went out, the implementation team started rolling off. Then the first month-end close arrives. Postings do not match the reconciliation format. Production orders complete but do not settle. The help desk fills with users who were trained but not prepared for edge cases.

This is where much of the real value is delivered and where most programmes are under-resourced. The hypercare team works the issue queue systematically, separates systemic problems from one-off errors, and rebuilds confidence in the system.

The structure of the work has not changed. The time mix has.

Documentation drafts itself, mostly. SAP Joule for Consultants, generally available since 2025, answers configuration questions from SAP's own knowledge base, including SAP Notes, and explains ABAP code. Joule-based assistants in SAP Cloud ALM draft requirements and test cases from workshop material. The functional consultant spends less time typing documents and more time challenging workshop conclusions.

Code is reviewed more than written. SAP's developer assistants draft code, including SAP Build Code for Java and JavaScript extensions on SAP BTP. Technical consultants now review, secure and test it.

Hypercare desks see fewer routine questions. Joule can answer routine questions such as leave balances or expense status inside SAP applications, which takes some volume off the hypercare desk. Consultant time shifts to process gaps, master data issues and the cases that need a person.

The point of bringing in a consultant has not changed. Consultants who learned these tools spend more time on judgement, communication and escalation, and less on work the AI now drafts adequately. SAP's own description of Joule for Consultants is a fair summary of what it covers.

Functional consultants specialise in modules such as FI, CO, SD, MM, PP, EWM or SuccessFactors. They configure the system around business processes and close the gap between SAP's standard and the client's requirements. Their value is module depth plus business process knowledge.

Technical consultants (ABAP developers, SAP BTP specialists, integration architects, Basis) build the extensions and integrations configuration cannot cover. On modern S/4HANA programmes, clean-core principles push new extensions onto SAP BTP or released APIs, which needs a different skill set from classic ABAP modification.

Project and programme managers provide delivery structure: governance, risk, schedule and issue resolution, with visibility across the whole programme so problems are escalated before they become crises.

Change management consultants work on the people side: training, communication, engagement, and the governance that decides whether users adopt the system or work around it.

Most large SAP programmes need all four. Mid-market programmes often have fewer people covering several roles, which is where gaps form. The consulting frameworks and skills that matter in consulting are the same across all four. If you are a consultant mapping your own route through these roles, SAPopedia sets out career paths and courses, and ERPCV helps you present that experience to recruiters.

The most expensive consulting mistake is bringing someone in too late. A pre-cutover risk review four to six weeks before go-live can find critical issues while there is still time. A recovery engagement after a failed cutover costs far more. It also happens under operational pressure, in an organisation that has lost confidence in the system.

The table shows the signals and the help each one calls for.

Signal	What it usually means	Help to bring in	What they should deliver in two weeks
Issue log items open more than four weeks with no resolution date	A governance problem, not a technical one	Independent programme advisor	A decision list with owners and dates
Go-live within 60 days and no cutover rehearsal	Untested cutover; surprises at go-live are not recoverable in real time	Cutover or programme lead	A rehearsed cutover plan and go/no-go criteria
Business owners have stopped attending	UAT will fail without deliberate intervention	Change lead plus a functional lead	Walkthroughs with key users and a re-engagement plan
One workstream stuck at the same error rate for weeks	Root cause not found	Specialist in that workstream	A root-cause analysis and a recovery plan
SI reporting is the only view of programme health	No independent check	Client-side advisor	An honest health assessment for the sponsor

What do SAP consultants actually do on a project?

They analyse business requirements, configure SAP to support them, and close the gap between SAP's defaults and what the business needs. In Explore they run fit-to-standard workshops and document gaps. In Realize they build configuration and work with developers on extensions. In Deploy they support UAT, manage defects and prepare cutover. In hypercare they resolve post-go-live issues. The part missing from job descriptions is triaging the gaps between phases and keeping delivery discipline under pressure.

When do organisations actually need a consultant?

Three situations cover most engagements. Programme recovery, when scope has drifted, a workstream has stalled or the go-live date is at risk. Specialist capability, when the team lacks a module or technical skill such as PP-PI configuration or integration on SAP BTP. And governance, when the organisation wants independent oversight of a programme run by a systems integrator. Waiting for things to deteriorate before calling is the most common pattern and the most expensive.

What is the difference between a functional and a technical SAP consultant?

Functional consultants configure SAP to support business processes in modules such as FI/CO, SD, MM, PP or EWM, and work directly with business users on requirements. Technical consultants build what configuration cannot: ABAP and BTP extensions, integrations, and system administration through Basis. Clean-core principles are shifting technical work from in-system ABAP modifications toward BTP extensions and released APIs.

How do you know if a consultant is adding value?

Three indicators. They surface assumptions that were never tested and decisions that were deferred, rather than confirming existing opinions. Decisions that were stuck for weeks start getting made. And the issue log shrinks because root causes are fixed, not because items are closed without resolution. A log that stays the same length despite activity means the problems are systemic or the fixes are not reaching the cause.

What is the hardest part of consulting work?

Naming problems the client already knows about but has not acted on: the drifted scope, the unwritten test cases, the sponsor who stopped engaging. That takes enough trust to be heard, enough credibility to be believed and enough directness to say uncomfortable things. Consultants who protect the relationship at the expense of the diagnosis are expensive agreement.

Why hire an independent consultant if the client already has an SI?

The systems integrator is accountable for delivering the contracted scope. An independent consultant is accountable to the client for the outcome. Those are different jobs. The client-side advisor challenges design assumptions and validates that the design meets business needs. They protect the client's commercial position in change control, and give leadership a view of programme health that is not filtered through the integrator's reporting. That is a structural conflict of interest, not a criticism of integrators.