Seven consulting frameworks for SAP and AI delivery

When an SAP or AI programme stalls, the cause is usually structural, and seven simple frameworks find it. Map the current state. Agree who decides what with a RACI. Tie the work to business capabilities. Find root causes with the five whys. Rank requirements with MoSCoW. Rank risks by what can actually stop the programme. Run a real post-mortem after each phase. This guide is for programme managers, consultants and sponsors on SAP and AI delivery. Start with the table below: find your symptom and use the matching framework first.

A mid-sized media company in Qatar was rolling out SAP across several regions. Finance and procurement were going live in phase one. It also wanted AI forecasting models in its reporting.

By week six, delays were creeping in. Business users said they had signed off requirements but were still confused about what they were getting. AI use cases had been proposed and nobody could say who owned the data or how the output would be used. People were arriving late to meetings, or not at all.

It was that in-between phase. Too early to call it a failure. Too late to pretend it would fix itself.

We applied the frameworks step by step. Not all of it was welcome at first. Some sessions were quiet. Others went off track. But the structure made the work easier: the team stopped circling, the backlog became manageable and the AI use cases got real owners. The project went live eight weeks later than planned. Not perfect. But it landed, and phase two started on better ground, with fewer unknowns.

I have used versions of all seven across 23 years of delivery on SAP, Oracle and AI programmes in the Gulf, Europe and beyond. None is exotic. All of them work if you apply them with discipline rather than as documentation exercises.

Match the symptom to the framework:

Symptom you are seeing	Framework	What it produces	Typical effort
Users signed off requirements but are still confused	1. Current state mapping	A shared map of how work really happens today	3 to 5 days of workshops
Decisions keep bouncing between meetings	2. RACI on critical decisions	Named decision owners for the 20 to 30 key calls	One workshop, then enforcement
Sponsors have disengaged from "the IT project"	3. Capability mapping	Progress reported as business capabilities	Built into fit-to-standard
The same defect type keeps coming back	4. Five whys	A root cause you can change	One facilitated session per issue
Everything is marked high priority	5. MoSCoW	A ranked scope with a realistic Must Have list	One joint business and IT session
The risk log looks fine but the team feels tense	6. Risk ranking	Separate lists of programme-stopping and nuisance risks	Weekly 30-minute review
The same mistakes repeat phase after phase	7. Post-mortem	Three to five changes with owners	Half a day after each phase

The most common mistake at the start of a programme is jumping to the solution before documenting what exists. Process documentation is usually out of date. People describe how things should work, not how they do. The gap between the two is where implementation problems live.

A useful current state map takes three to five days of workshops with the people who do the work, not the people who manage them. It covers process steps in order, the systems used at each step, manual interventions and workarounds, and data flows between departments.

Look for the manual steps nobody mentions because they have become invisible, the workarounds running so long they now count as standard process, and the data quality problems everyone knows about and nobody has fixed.

In Qatar, the current state map came from workshops with users, not from documentation. That is where the confusion about signed-off requirements started to clear.

Done properly, a current state map takes days. Treated as a document-collection exercise, it takes months and produces something nobody trusts.

Decision rights are the structural element most often missing from SAP and AI projects. Everyone has a view. Nobody knows who makes the final call. Decisions go to the next meeting, which defers to the steering committee, which sends them back to the working group.

A RACI matrix (Responsible, Accountable, Consulted, Informed) gives every decision and deliverable an owner. One person is Accountable and may also be Responsible or delegate it. Consulted people give input. Informed people hear the outcome.

The practical version: list the twenty to thirty most critical decisions in the current phase and run a RACI workshop with the decision-makers present. Where an assignment is contested, you have learned something: either the governance is unclear or there is a political fight over authority. Either way, surface it in week two, not week fourteen.

RACI without enforcement is decoration. The names must match the people with real authority. Assigning accountability to a role title instead of a named person is a way of avoiding the conversation about who owns the risk.

SAP and AI programmes generate a lot of technical activity the business cannot see. The link between what is being built and the outcome it should deliver becomes abstract. Sponsors disengage, and "the IT project" gets blamed for delays that are really business decisions.

Capability mapping connects system function to business capability: what the organisation needs to be able to do. Instead of tracking whether the purchase order workflow is configured, you track whether the organisation can process supplier invoices within three days of receipt. Configuration is the mechanism. The capability is the outcome.

In SAP Activate this maps onto the fit-to-standard workshops in Explore. Each process in scope is a capability, and each gap between SAP standard and the required capability is a decision: accept the standard, configure a variant or extend. Keeping the conversation at capability level holds business attention through the build, and it exposes capabilities everyone assumed were in scope but nobody confirmed.

When the same kind of problem keeps appearing across sprints or phases, patching each instance does not help. The cause sits upstream.

The five whys is the simplest root cause tool. Ask why the problem happened, then why that happened, until you reach something you can change. Five rounds usually reach the real cause. Two rounds usually stop at the symptom.

A data migration example. The trial load has data quality errors: that is the symptom. Why? The source extract had wrong field mappings. Why? The mapping specification was never reviewed by the business data owner. Why? The data owner was assigned only after mapping was finished. Why? The plan did not make data owner engagement a dependency for mapping. That is the root cause, and the fix is a governance decision, not a data fix. My piece on why SAP data migration fails shows how often this exact chain appears.

1. 01Trial load errorsThe symptom
2. 02Wrong field mappingsWhy did the load fail?
3. 03Spec never reviewedWhy were the mappings wrong?
4. 04Owner named too lateWhy was the spec not reviewed?
5. 05Plan missed the dependencyWhy was the owner late?

The root cause is a governance decision, not a data fix

Root cause analysis in a blame-free room produces honest answers. In a blame-attributing room it produces defensiveness. The facilitator's job is to keep the conversation on process, not people. My guide to structured thinking and problem solving covers how to break a messy problem down before you start asking why.

Every SAP and AI scope discussion has a consensus trap. Nobody wants to make trade-offs, so everything becomes high priority. When everything is high priority, nothing is, and the build team tries to do it all.

MoSCoW (Must have, Should have, Could have, Won't have this time) forces the choice. Must Have is the minimum needed for go-live. Should Have is important but not a blocker. Could Have is desirable if time and budget allow. Won't Have is explicitly deferred.

The discipline is in the Must Have line. The first pass of a MoSCoW exercise usually puts far too much in Must Have. The DSDM guidance from the Agile Business Consortium, where MoSCoW comes from, sets a ceiling of 60% of effort on Must Haves and warns that going higher puts delivery at risk. The gap between the first pass and a realistic list is mostly untested assumptions.

Run MoSCoW with business and technology in the same room. Run separately, IT's Must Have list and the business's Must Have list turn out to be incompatible, and nobody reconciles them until configuration has started.

Most risk registers are long lists scored by probability and impact, reviewed monthly, with RAG statuses that rarely move. They record risk without driving action.

Split risks that can stop the programme from risks that make it harder. The first group needs owners, response plans and weekly visibility. The second needs monitoring.

In Qatar, the risk log looked fine on paper, but everyone felt on edge. A fast risk-impact matrix, reviewed weekly rather than monthly, brought the real concerns out.

A register that looks fine while the team feels tense is almost always hiding something. The register is not the truth; the conversations around it are. A weekly review that asks "what kept you up last night?" surfaces more than "what is the status of item 14?". My SAP risk assessment matrix gives a template for the scoring and ownership.

Post-mortems after a phase or go-live stop the same mistakes recurring in the next phase. They are also the first thing cut when the schedule is under pressure.

A useful post-mortem asks four questions. What did we plan to achieve, and what did we achieve? What went well and should be repeated? What went badly, and what caused it? What would we do differently? It should end with three to five specific actions with owners, not a document summarising what happened.

The common failure is a justification exercise where teams defend decisions instead of examining them. Keep it forward-looking. The question is not who caused the week-six delays. It is what structural change prevents them in the next phase.

In Qatar, the post-mortem ran right after go-live and focused on action, not blame. It is a large part of why phase two started on better ground.

The frameworks have not changed. How they get applied has, in three ways.

Drafting got faster; listening did not. AI tools now turn workshop transcripts and process documents into a first-pass map within minutes, and SAP Cloud ALM can draft requirements from fit-to-standard transcripts. The workshops themselves take as long as they always did, because the listening is the point. The time saved on drafting should go into challenging the map with people.

RACI drafts arrive ready, and the hard part remains. A general-purpose AI assistant will produce a RACI from a charter and a list of work packages in a minute. The discipline shifts to negotiation: every cell needs a real conversation about authority and escalation. The time saved on building the draft should go into those hard conversations.

MoSCoW gets harder with AI in the room. An AI ranking of requirements is plausible, polished and often wrong about local politics. Consultants who accept it without challenge produce worse priority lists than consultants who start with a blank sheet. Treat the AI draft as a starting point, never the answer.

The judgement on top of these frameworks is worth more now, not less. If you are building these skills as a consultant, SAPopedia's career paths set out which ones matter at each stage of an SAP career.

What are consulting frameworks and why do SAP projects use them?

They are structured approaches to analysis, decisions and problem-solving. On SAP and AI programmes they give business leads, architects, project managers, integrators and sponsors a shared method.

Without one, each group defaults to its own mental model: process outcomes, architecture, or timeline and resources. Frameworks such as current state mapping, RACI and MoSCoW make disagreement explicit and resolvable. SAP Activate is itself a framework for phases, gates and deliverables; these seven work inside it and deal with the structural and human issues methodology alone does not resolve.

How does current state mapping work in an SAP implementation?

It documents how processes actually work before configuration starts, as opposed to how existing documentation says they should work. Build it in workshops with the people who run the processes: steps, systems, handoffs, manual interventions and workarounds.

It feeds the fit-to-standard workshops in the Explore phase of SAP Activate, where the current state becomes the baseline compared with SAP's standard processes. Complete it before those workshops start, or your gap analysis rests on assumptions.

What is MoSCoW prioritisation and when is it used in SAP programmes?

MoSCoW sorts requirements into Must have, Should have, Could have and Won't have this time. Must Haves are the minimum for go-live; Won't Haves are explicitly excluded so they cannot creep back in.

It is most useful in Explore, when fit-gap findings drive extension decisions, and in Realize, when defects and enhancements compete for build time. The usual problem is too many Must Haves on the first pass. DSDM recommends no more than 60% of effort on Must Haves; a facilitator who challenges each one, with business and IT in the same session, gets you there.

How do you run an effective risk review on an SAP project?

As a conversation, not a status update. Start with open questions such as "What is your biggest concern this week that is not in the register?" before going through the register.

For each high-priority risk, ask what has changed, what action was taken, whether the trend is improving and whether the response plan still fits. Risks that sit at the same rating for weeks without action are often understated. Review weekly in active phases, and show the steering committee the top five with status and next action, not the full register.

What makes a useful post-mortem after an SAP go-live?

Specific, actionable changes for the next phase. A summary of what happened is a record, not a post-mortem.

Cover what you set out to achieve, what you achieved, what worked and what did not. Push below surface explanations such as "we were under-resourced": was the resource plan wrong, the scope wrong, or the escalation path broken? End with three to five changes, each with an owner and a date.

How do consulting frameworks help with AI implementation in SAP environments?

AI projects fail for the same structural reasons as SAP projects, plus a few of their own: unowned data, undefined success measures and no agreed process for acting on the output.

Current state mapping shows who owns the data a model needs and how good it is. RACI answers who validates the output, who decides to act on it and who is accountable when it is wrong. MoSCoW separates essential use cases from interesting ones. Start with two or three essential use cases with clear owners and success measures, not fifteen at once.