SAP Implementation Methodology in Practice: What Actually Happens in Each Phase

What actually happens in each phase

Every consulting firm has a methodology deck with neat phases and arrows. This article is the other version: what really happens in each phase, what you actually produce, and where projects really go wrong.

1. The five phases (classic on-premise / private cloud)

Project Preparation → Blueprint → Realization → Final Preparation & Cutover → Go-live Support

If you work on SAP Cloud ERP, the names change (Prepare, Explore, Realize, Deploy, Run — see the SAP Activate article), but the underlying work is surprisingly similar. The biggest difference is in the middle: Cloud ERP replaces "write a blueprint" with "demonstrate the standard and confirm the gaps".

2. Phase by phase

Phase 1 — Project Preparation

What happens

• Kickoff, organization chart, team contact list, plan and governance (weekly status meeting, monthly steering committee).
• Agree document standards: templates, naming rules, version numbers, who signs off.

What you produce

• Project charter / plan, team structure, document standards, issue & risk log.

Lesson: agree document naming and versioning on day one. On a project with hundreds of specs, test scripts and templates, a consistent ID system (for example FS-MM-013, UT-MM-005, IT-MM-001) is what lets anyone find the latest signed version months later.

Phase 2 — Blueprint (requirements and design)

What happens

• Site visits before workshops: walk the factory, the warehouse, the pharmacy. You learn more in a day on site than in a week of meetings.
• Workshops per process area, documenting current state → expectation → proposed solution.
• Design the organization structure in SAP (company codes, plants, storage locations, purchasing organizations).
• Design master data: numbering and description rules, material types and groups, which fields are mandatory and who maintains them.
• List everything that isn't standard configuration: reports, interfaces, conversions, enhancements, forms, workflows (the classic "RICEFW" list).

What you produce

• Business blueprint per module (often bilingual), process flow charts, requirements list, development list, interface list.
• Customer sign-off.

Lessons

• Master data design is architecture. When products have many technical attributes, the material number and description rules decide whether downstream systems (MES, sales, reporting) can work with the data. Getting this right in blueprint saves months later.
• Interfaces often dominate the scope. In China projects especially, SAP is rarely alone: OA approval systems, MES, hospital HIS/LIS, government procurement platforms, VAT invoice (golden tax) systems. It is common for interfaces to be more than half of a module's developments. List them early, with an owner on both sides.
• Separate "how we work today" from "what we need". Many requirements are habits of the old system. Ask for the business reason.

Phase 3 — Realization (build and test)

What happens

• Configure the system and document the configuration.
• Write functional specifications for every development; developers build; you test.
• Unit tests → integration tests across modules and systems.
• Design user roles and authorizations.
• Start data migration: collection templates to the business, cleansing, test loads.
• Prepare key-user training.

What you produce

• Configuration document, functional specs (signed), unit test results, integration test scripts and results, authorization design, data templates, training manuals.

Lessons

• A good functional spec answers the developer's questions before they ask. Include: business background, trigger, input/selection screen, logic step by step, output layout, error messages, authorization, and test cases. Attach real sample data.
• Specs evolve — keep the history. A report spec may go through ten versions. Keep a change log and the signed copy; it protects you when someone says "that's not what we asked for".
• Integration testing needs the other system's team in the room. Most integration defects are about mapping and timing, not about SAP.
• Train key users per process, and write minutes. Training per topic (master data, purchasing, inventory movements, consignment) with recorded questions becomes your best source of last-minute requirement changes.

Phase 4 — Final Preparation & Cutover

What happens

• Data migration rehearsals: full dry runs of extracting, converting, loading and reconciling data — usually at least two before the real one.
• Cutover plan hour by hour: system freeze, open documents, opening stock, open purchase orders, balances.
• End-user training, go/no-go decision.

What you produce

• Migration procedure, conversion rules, rehearsal plans and results, cutover plan, go/no-go checklist.

Lessons

• Data migration is always bigger than planned. Collection templates go through many versions, and different material types often need separate rounds. Plan for many rounds.
• Conversion rules are business decisions. Mapping old supplier codes to new business partners, old material numbers to new ones, old accounts to the new chart of accounts — the business must decide and sign off, not the consultant.
• Rehearse until it's boring. Two or more migration rehearsals (MR1, MR2) should find most problems before the production weekend. Track every issue between rehearsals and fix the rule, not just the data.
• Reconcile, don't just load. Every object needs a check: record counts, quantities and values, old vs. new.

Phase 5 — Go-live Support (hypercare)

What happens

• Daily checks of key processes, interfaces and error logs.
• Fast fixes: data corrections, missing master data, authorization issues.
• Collect new requirements that only appear once people use the system for real.
• Handover to the support team.

Lessons

• Build a daily checklist. A short list (failed interface messages, stuck documents, stock anomalies) run every morning catches problems before users call.
• Give users self-service tools. Upload templates and mass-maintenance programs (e.g. extending materials to a new plant) remove hundreds of tickets.
• Separate defects from new requirements. After go-live everything feels urgent. A clear log protects both the project and the client relationship.

3. Variants you will meet

4. A checklist to keep in your pocket

• Document IDs and versioning agreed in week 1
• Site visits before blueprint workshops
• Master data rules designed and signed
• Full interface list with owners on both sides
• Every development has a signed spec and a unit test record
• Authorization design started in Realization, not at go-live
• Data templates sent to the business early; cleansing has an owner
• At least two migration rehearsals with reconciliation
• Hour-by-hour cutover plan
• Daily hypercare checklist and a clear defect vs. new-requirement log