SAP Real projects

Modern SAP projects use SAP Activate, an agile, phased methodology with prebuilt best-practice content. Its phases are Discover, Prepare, Explore (fit-to-standard workshops), Realize (build and test), Deploy (go-live) and Run. It favours fitting to standard and iterative delivery over heavy customisation.

• Greenfield: a fresh implementation (clean start).
• Brownfield: convert an existing system (e.g. ECC to S/4HANA) in place.
• Selective/hybrid: a mix, migrating chosen data and processes.

Activate names four phases and it is worth knowing what a consultant does in each, because the work is quite different.

Prepare is governance and mobilisation: team, plan, environments, and agreeing how decisions will be made. Consultants are mostly reading and asking questions.

Explore is the fit to standard workshops. The standard process is demonstrated to the business, and every point where they say it does not work that way is logged as a gap. The output is a backlog of gaps with a decision on each: change the process, configure, extend, or accept. This phase determines the cost of everything after it.

Realize is building and testing in sprints: configuration, extensions, data migration, integration, and successive test cycles ending in user acceptance.

Deploy is cutover. The plan is rehearsed, usually more than once, because it runs over a weekend and every step depends on the previous one finishing.

Then run, which is where the system spends its life and where most people actually work.

Knowing the roles helps you find where you fit and what to aim at next.

Functional consultants own a module: they run the workshops, configure, and explain to the business why the standard behaves as it does. Technical consultants build what configuration cannot: extensions, reports, forms and interfaces. Basis runs the systems, transports and performance. Data migration extracts, cleanses and loads, and is consistently underestimated. Integration connects everything to everything else.

Above them, a solution architect keeps the design coherent across modules, and a project manager owns scope and schedule. On the client side, process owners make the decisions the gaps require, and a project without empowered process owners stalls in Explore.

Most people start as a junior functional or technical consultant on a specific module, and the route upward is usually breadth across adjacent modules rather than depth in one. See the finance tables and other reference pages for the detail those roles work with daily.

Clear scope, fit-to-standard (minimising custom code), strong data migration and testing, change management/user adoption, and disciplined cutover. Most failures come from over-customisation, poor data, weak testing or neglected adoption.

Two more, learned the hard way on most projects. Data migration starts early, because the state of the legacy data is always worse than the business believes, and finding that out in Realize is too late. And cutover is rehearsed, at least twice, with timings, so that the real weekend is an execution rather than a discovery.

If you are joining a project rather than starting one, these four documents tell you more in an hour than a week of meetings.

1. The scope document or backlog. What is in, what is explicitly out, and what is still undecided. The undecided list is where the risk lives.
2. The gap list from Explore, with its decisions. This tells you how much the client is bending to the standard, which predicts how painful upgrades will be.
3. The data migration plan. Which objects, from where, in what order, and who owns cleansing.
4. The cutover plan. Even in Explore, whether one exists tells you how the project is being run.

Ask which phase the project believes it is in, then check that against these four. The gap between the two is the most useful thing you will learn in your first week.

Cutover is the weekend the business stops using the old system and starts using the new one, and it is the single highest risk event of the project.

The plan is a sequenced list of tasks with owners, durations and dependencies, and it is genuinely long. Freeze the legacy system, run final extracts, load master data in dependency order, load open transactional data such as open orders and open items, reconcile, run validation transactions, open the system to users.

Reconciliation is what makes it defensible. Counts and control totals from the legacy system compared against the new one, per object, signed off by the people who own the numbers. Without it, nobody can say whether the load succeeded.

Rehearsals exist because the plan is always wrong the first time. A dress rehearsal runs the whole sequence against production-like data, with timings, and produces a corrected plan. Two rehearsals is normal on a large programme.

The two things that most often derail it: a step that takes far longer than estimated, which is why timings from rehearsal matter more than estimates, and data that fails validation at the last moment, which is why cleansing should have finished weeks earlier.

A rollback point is agreed in advance, with the criteria for using it. Deciding at three in the morning whether to abandon is not a decision anybody should be making fresh.

Testing is the phase most often compressed and the one where compression is most expensive, so it helps to know what the cycles are for.

Unit testing checks one configuration or one object in isolation, done by whoever built it.

String testing checks a sequence within one area: create an order, deliver it, invoice it. It catches the gaps between individually correct settings.

Integration testing runs an end to end business process across modules and interfaces, with real-shaped data. This is where most defects are found, because it is the first time the pieces meet.

User acceptance testing is the business confirming the system supports how they work. It is not a defect hunt, and treating it as one means the earlier cycles were not done.

Alongside these, data migration testing runs the load repeatedly, and performance testing checks the volumes nobody thought about.

The rule worth carrying: a defect found in unit testing costs an hour, in integration testing a day, and after go-live a week and somebody's confidence. See the purchasing tables and their item detail for the kind of data these cycles are checking.

• Over-customising instead of fit-to-standard.
• Underestimating data migration and testing.
• Neglecting change management.

• Gaps closed by building rather than deciding. Every gap answered with an extension is cost now and cost at every upgrade.
• Testing compressed because the build ran late. It is the only phase that can be squeezed, which is exactly why it should not be.
• No process owner with authority. Decisions get deferred and reappear in cutover. See the sample project for how one is structured.

• Treating go-live as the end. The weeks after are when the real defects surface, and a team that has already been released is a team that cannot fix them.

Understanding the method is the start, and configuring a process end to end so it survives a fit to standard workshop is the part you do in the course.

If you join a project mid-flight, the fastest orientation is the gap list. It tells you what the client would not change, which explains most of the design decisions you are about to be confused by.