SAP Activate methodology explained

SAP Activate is the vendor's implementation methodology: a sequence of phases — Discover, Prepare, Explore, Realize, Deploy, Run — combined with ready-made best-practice process content and a working style built around showing the standard system first and configuring the differences afterwards. Almost every current SAP project is planned in its vocabulary, so knowing what each phase means is knowing what your own weeks will look like.

What are the SAP Activate phases?

• Discover. Before the project exists. The customer evaluates what the software would do for them, often in a trial system, and builds the business case and the rough scope.
• Prepare. The project is set up: team, governance, plan, the initial systems, the project standards. Consultants are on-boarded, the scope is confirmed and the workshop calendar is agreed.
• Explore. The fit-to-standard workshops. The preconfigured processes are demonstrated to the business, area by area; every place the company needs something different is written down as a delta. The output is a backlog, not a blueprint.
• Realize. The backlog is worked off in iterations: configuration, extensions, integration, data migration, with the business seeing working increments along the way. Testing runs in waves inside this phase, from unit tests to end-to-end integration tests and user acceptance.
• Deploy. Cutover rehearsals, the final data load, training, go-live and the first weeks of stabilisation.
• Run. The system in operation: support, continuous improvement, and — in the cloud editions — adopting the vendor's regular releases. This is where AMS work lives.

Between phases sit quality gates: agreed checks that the phase's deliverables exist before the next phase spends money. Project managers run their calendars on them; the project manager guide covers what that job is.

What is a fit-to-standard workshop?

The centrepiece of Explore, and the thing that most distinguishes the methodology. A consultant runs the standard process in a live system in front of the process owners — a purchase order raised, approved, received and invoiced, say — and asks a single question at each step: does this work for you? Where the answer is yes, the standard is adopted and documented as such. Where the answer is no, the consultant captures a delta requirement with its business reason, and the team later decides whether it becomes configuration, a key-user extension, a side-by-side app or a change to the way the company works. The skill is in the conversation: keeping the business looking at what exists rather than describing what they had, and pushing back, politely, on deltas that are habits rather than needs.

What role does best-practice content play?

The workshops only work because there is something to show. SAP ships preconfigured business processes — scope items, in the methodology's vocabulary — each with a process description, a configured system behind it and test scripts. A project selects the scope items it needs, activates them, and starts every workshop from a running process rather than a blank page. For a consultant this means two things: the content sets the default, so knowing the standard process in your area cold is the entry ticket; and the test scripts become the backbone of testing, so a great deal of Realize is adapting them to the deltas rather than writing tests from nothing.

How does Activate differ from classic ASAP thinking?

The older methodology began with a blueprint: months of requirement workshops producing documents that described the future system, followed by a realization phase that built what the documents said. The risk was structural — the business specified from memory of the old system, the documents drifted from what was possible, and the first time anyone saw working software was late. Activate inverts the order. The working system comes first, requirements are captured as differences from it, and build happens in iterations the business sees. Blueprint thinking still shows up in candidates and in some project shapes — large brownfield conversions and template rollouts keep more of the documentary style — but the direction of travel is clear, and the cloud editions sold under RISE and GROW more or less require the fit-to-standard style.

What does each phase mean for a consultant's week?

• Prepare — reading the scope, learning the client's organisation, preparing demo data for your area, checking the sandbox works. Quiet, and the last quiet you will get.
• Explore — workshop days, usually on site, with evenings spent writing up deltas and preparing tomorrow's demo. The most sociable phase and the one where a functional consultant's reputation is made.
• Realize — configuration in the morning, a developer conversation about an extension at noon, test scripts in the afternoon, a stand-up somewhere in between. Increasingly remote as the phase goes on.
• Deploy — cutover checklists, rehearsals at odd hours, the go-live weekend, then a hypercare desk with the key users. The phase that produces the stories interviews ask for.
• Run — tickets, small changes, release reviews, and the beginning of the next project's Discover.

A fuller picture of those days is in a day in the life.