Change Management

SAP Change Management

This skill enforces structured, evidence-based change management for SAP implementations so that no stakeholder group goes unanalyzed, no communication is broadcast without targeting, no training is generic, and adoption is measured before go-live is declared successful.

Iron Laws

1. NEVER SKIP STAKEHOLDER IMPACT ANALYSIS. Deploying SAP without a stakeholder impact analysis is deploying into the unknown. You do not know who is most affected, who will resist, or who needs to be onside first. Every role that touches the new system must be analyzed before communication or training begins.
2. NEVER ASSUME ONE CHANNEL REACHES ALL. An email to all staff is not a communication strategy. Different stakeholder groups have different access, literacy, and trust in different channels. Segment your audiences and match channel to group.
3. ALWAYS CREATE ROLE-BASED TRAINING. Generic "how to use SAP" training fails because it does not connect to the user's actual daily tasks. Every training audience must be defined by role, and every training module must be tied to the transactions and processes that role performs.
4. DEFINE ADOPTION METRICS BEFORE GO-LIVE. If you have not defined what adoption looks like, you cannot measure it, and you cannot declare go-live successful. Metrics must be agreed with the business before cutover — not retrospectively applied to explain poor outcomes.

Rationalization Table

Red Flags

Watch for these phrases in your own reasoning — each one signals you are about to violate an Iron Law:

• "We'll cover everyone in one communication..." → Have you segmented your audiences by role and concern? Stop.
• "Users will get used to it after go-live..." → Resistance does not resolve itself. Identify it and address it now.
• "Training will be a few sessions before go-live..." → Training is role-based and runs through Realize, not just Deploy. Redesign the plan.
• "We'll measure adoption once it's live..." → Adoption metrics must be defined before cutover. Stop.
• "The sponsor sent an email, so awareness is covered..." → Awareness is one stage of change readiness. Have you measured it? Have you confirmed receipt and understanding?
• "Change management is the HR team's responsibility..." → Change management is a project delivery responsibility. HR may co-own training, but the project team owns the plan.
• "We know our stakeholders..." → Have you analyzed their impact level, readiness, and influence? Knowing who they are is not enough.

Hard Gates

Checklist

Step 1: Identify and Register All Stakeholder Groups

Before any change activity begins, map the full stakeholder landscape:

• Roles affected: Every role that will use, oversee, approve, or be impacted by the new SAP processes
• Organizational units: Which departments, locations, and business units are in scope
• Influence and interest: For each group — level of influence over project success and level of interest in outcomes
• Key individuals: Named champions, blockers, and decision-makers within each group

Evidence: Stakeholder register with role, org unit, influence rating (H/M/L), and interest rating (H/M/L). Gate: Every in-scope process area has at least one identified stakeholder group before Step 2 begins.

Step 2: Conduct Stakeholder Impact Analysis

For every stakeholder group, assess the nature and severity of change they face:

Impact Dimensions:

Rate each dimension: High / Medium / Low impact. Calculate an overall impact score per stakeholder group.

Evidence: Impact assessment table per stakeholder group with dimension-level ratings and overall impact score. Gate: No stakeholder group has an impact score of "Low" without written justification — assumption of low impact is a risk.

Step 3: Assess Change Readiness

Establish the current readiness baseline for each stakeholder group:

Readiness Assessment Methods:

• Survey (quantitative — likert scale questions on awareness, understanding, desire, ability)
• Workshop / focus group (qualitative — understand concerns, blockers, and motivators)
• Interview (for senior stakeholders and identified resistors)

Readiness Dimensions (ADKAR model):

Rate each dimension per stakeholder group (1–5 scale). Identify the lowest-scoring dimension as the primary intervention point.

Evidence: Change readiness baseline per stakeholder group with ADKAR dimension scores and primary gap identified. Gate: Readiness assessment is conducted with actual stakeholders — not estimated by the project team on their behalf.

Step 4: Design the Communication Strategy

Build a targeted communication plan that segments by audience:

Communication Planning Principles:

• Match message to the audience's primary concern (What does this mean for me? What changes? What support is available?)
• Match channel to audience access and trust level
• Sequence messages: Awareness → Understanding → Acceptance → Readiness
• Identify the most credible sender for each audience (sponsor, line manager, peer champion)

Channel Options:

Evidence: Communication plan with event, audience, channel, sender, message, and timing for every planned communication. Gate: Every communication event has a named sender and a mechanism for two-way feedback.

Step 5: Define Training Needs by Role

Build a role-based training needs analysis:

• Role inventory: List every role that will use the SAP system
• Transaction mapping: For each role, identify the SAP transactions and processes they will perform
• Learning objectives: Define what the person must be able to do after training (behavioral outcomes, not feature lists)
• Prerequisite knowledge: What does the learner already know? What is the delta?
• Training format: Classroom / virtual / e-learning / job aid / on-the-job — match to content complexity and audience size

Training Curriculum Design:

Evidence: Training needs analysis per role with learning objectives, transaction mapping, and format decision. Gate: No training module is labelled "All Users" or "General SAP." Every module has a specific target role.

Step 6: Identify and Manage Resistance

Proactively identify and address resistance before it becomes blockers:

Resistance Identification:

• Who has the most to lose from the change?
• Who has influence to derail adoption if they resist?
• Who has resisted previous technology changes in this organization?

Resistance Response Strategies:

Evidence: Resistance register with identified resistors, resistance type, response strategy, owner, and status. Gate: Resistance register is reviewed at every project steering meeting — not treated as a one-off assessment.

Step 7: Define Adoption Metrics and Go-Live Readiness Criteria

Before cutover, agree on how adoption will be measured:

Adoption Metric Categories:

Go-Live Readiness Criteria (Change Perspective):

• Training completion rate ≥ [X]% per role group
• Change readiness re-assessment score ≥ [Y] on ADKAR scale
• All high-impact, high-influence resistors have been engaged
• Communication plan fully executed for Prepare and Explore phases
• Hypercare support model communicated to all user groups

Evidence: Adoption metrics table with metric, target, measurement method, and measurement frequency agreed with business sponsor. Gate: Adoption metrics are documented and signed off before cutover rehearsal — not defined after go-live.

Deliverable Template

# SAP Change Management Plan

## Header
- **Project:**
- **SAP Scope:**
- **Plan Version:**
- **Prepared By:**
- **Business Sponsor Sign-Off:** [Name, Role, Date]

## Stakeholder Register

| Stakeholder Group | Org Unit | Role Count | Influence | Interest | Impact Score | Primary Concern |
|------------------|---------|----------:|:---------:|:--------:|:------------:|----------------|
| | | | H/M/L | H/M/L | H/M/L | |

## Impact Analysis Summary

| Stakeholder Group | Process Change | System Change | Role Change | Volume | Readiness Gap | Overall Impact |
|------------------|:-------------:|:------------:|:----------:|:------:|:-------------:|:-------------:|
| | H/M/L | H/M/L | H/M/L | H/M/L | H/M/L | H/M/L |

## Change Readiness Baseline

| Stakeholder Group | Awareness | Desire | Knowledge | Ability | Reinforcement | Primary Gap |
|------------------|:---------:|:------:|:---------:|:-------:|:-------------:|------------|
| | 1–5 | 1–5 | 1–5 | 1–5 | 1–5 | |

## Communication Plan

| # | Event / Activity | Audience | Channel | Sender | Key Message | Timing / Phase | Feedback Mechanism |
|---|----------------|---------|--------|--------|------------|----------------|-------------------|
| | | | | | | | |

## Training Plan

| Module | Target Role(s) | Transactions / Processes | Objectives | Duration | Format | Delivery Date | Owner |
|--------|---------------|------------------------|-----------|----------|--------|--------------|-------|
| | | | | | | | |

## Resistance Register

| Stakeholder | Resistance Type | Risk to Project | Response Strategy | Owner | Status |
|------------|----------------|:---------------:|------------------|-------|--------|
| | | H/M/L | | | |

## Adoption Metrics

| Metric | Target | Measurement Method | Frequency | Owner | Baseline |
|--------|-------:|-------------------|-----------|-------|---------|
| Training completion rate | ≥ [X]% | LMS report | Pre go-live | | |
| System login rate (30d) | ≥ [X]% | SAP usage report | Monthly | | |
| Process compliance rate | ≥ [X]% | Transaction audit | Monthly | | |
| Support ticket volume | ≤ [X]/week | Helpdesk report | Weekly | | |

## Go-Live Readiness — Change Perspective

| Criteria | Target | Status | Owner |
|---------|--------|--------|-------|
| Training completion per role group | ≥ [X]% | | |
| ADKAR re-assessment score | ≥ [Y] | | |
| High-impact resistors engaged | All identified | | |
| Hypercare support model communicated | All user groups | | |

## Open Items

| Item | Risk if Unresolved | Owner | Due Date |
|------|-------------------|-------|----------|

Verification

This skill is complete ONLY when ALL of the following are true:

• Stakeholder register covers every role and org unit impacted by the SAP implementation
• Impact analysis has been completed per stakeholder group with dimension-level ratings
• Change readiness baseline has been established using actual stakeholder input — not estimated
• Communication plan has a separate event for each audience segment — no all-staff-only entries
• Every communication event has a named sender and a feedback mechanism
• Training plan is role-based — every module has a specific target role and transaction mapping
• No training module is labelled "General SAP" or "All Users"
• Resistance register identifies specific individuals or groups with tailored response strategies
• Adoption metrics are defined, targeted, and agreed with the business sponsor before go-live
• Go-live readiness criteria (change perspective) are documented and measurable

Evidence required: Completed change management plan with all sections populated, resistance register reviewed, and adoption metrics signed off by the business sponsor.

If any verification item is not met, the skill is NOT complete. Do not claim completion.

Next Skill

After completing this skill, invoke:

• go-live-readiness — When the change management plan is baselined and the project moves into Deploy phase to confirm organizational readiness for cutover

Conditions for handoff: Communication plan is underway, training delivery is scheduled and resources confirmed, adoption metrics are agreed, and resistance register has no unaddressed high-risk items.

Cross-References

• project-kickoff — Stakeholder identification from kickoff feeds into the change management stakeholder register
• fit-gap-analysis — Process changes identified in fit-gap drive the impact analysis and training needs
• process-design — To-be process designs define the scope of behavior change that stakeholders must adopt
• testing-strategy — UAT is a change management event — users engaging with the system before go-live builds ability (ADKAR)
• go-live-readiness — Change readiness is a go-live gate — adoption metrics and training completion feed the go-live checklist