Skill Hub — SAP AMS / Operations

Change Impact Analysis

Before applying a transport, configuration change, or master data update, know which processes, interfaces, and stakeholders are affected.

What this skill is for

This skill helps you predict what will break, slow down, or behave differently after a change goes live. It produces a Change Impact Assessment that lists affected systems, data, interfaces, processes, and stakeholders, with a risk level and a rollback plan. The goal is to prevent the all-too-common pattern where a "small" config change breaks an interface that no one remembered existed.

When to use this skill

A transport is ready for production and the release note only says "config update."
A master data change (new plant, new company code, new payment term) is planned and downstream systems may be affected.
An interface schema or API contract is being modified and consumers need to adapt.
A new validation rule or incompletion procedure is being introduced.
A user role or authorization change is planned and sensitive transactions may be affected.
A periodic process timing or scheduling change is proposed.

Real work situations

Example 1: New payment term in SAP

A finance team requests a new payment term for a specific customer segment. The change seems small: one new entry in T052. Impact analysis reveals that the payment term is used in credit limit calculations in a custom report, in the dunning procedure configuration, and in the Ariba integration that sends payment terms to suppliers. The assessment prevents a go-live until the custom report and the Ariba mapping are updated.

Example 2: Adding a mandatory field to a sales document type

A business analyst proposes adding a mandatory reference field to a sales order type to improve traceability. Impact analysis checks the incompletion procedure, the web service API that creates orders from the e-commerce platform, the EDI ORDERS interface, and the BW extractor. The API and EDI interfaces do not send the new field, so orders would fail. The assessment delays the change until interface specifications are updated.

Example 3: Changing a background job schedule

A Basis team wants to move a billing job earlier to avoid peak hours. Impact analysis checks downstream jobs that depend on billing completion: the invoice print job, the IDoc generation job, and the BW delta extraction. Moving billing earlier without adjusting the dependent jobs would cause the invoice print job to run on incomplete data. The assessment proposes a coordinated schedule change for all three jobs.

Example 4: Updating a business partner grouping

An MDG team plans to change the business partner grouping for a customer category to align with a new organizational structure. Impact analysis checks CVI synchronization settings, customer account groups, the CRM replication filter, and the tax reporting interface. The CRM filter uses the old grouping as a selection criterion, so the change would stop replication for the affected customers. The assessment adds a CRM filter update to the change scope.

Inputs required

A precise description of the proposed change: what object, what value, what system, and what the intended outcome is.
The transport or change request documentation with object list and developer notes.
System landscape diagram or list: DEV, QAS, PRD, and connected systems (CRM, SRM, BW, Ariba, Salesforce, etc.).
Interface ownership matrix or list of interfaces that touch the changed object.
Process documentation for the business process that uses the changed object.
Where-used lists: for config objects, tables, fields, and custom code.
Stakeholder list: functional owners, integration team, data stewards, business users who will test.
Test environment availability and data freshness.

Questions to ask

What exact object is changing, and what is the current value versus the proposed value?
Which transactions, reports, batch jobs, and interfaces read or write this object?
Which downstream systems receive data derived from this object?
Which business process steps depend on this object, and what happens if the value is different?
Which users or user groups will see a change in behavior, screen layout, or available options?
Which validations, incompletion procedures, or workflow steps reference this object?
Which custom code, enhancement, or user exit references this object?
What is the rollback plan if the change causes unexpected failures in production?
Who will test this change, and do they have representative test data?

Working method

Define the change boundary. Document exactly what is changing: object name, table, field, transaction, program, or configuration path. Include current and proposed values.
Map direct consumers. Use where-used search, cross-reference tools, or SE11/SE16 to find all programs, classes, reports, and transactions that reference the object.
Map interface consumers. Check all interfaces (IDoc, RFC, API, file) that send or receive the object. Review the segment structures, API schemas, and mapping tables.
Map process consumers. Identify business process steps that use the object. Check process documentation or interview the process owner.
Map data consumers. Check BW extractors, reporting tables, data warehouse loads, and analytics tools that reference the object.
Identify authorization impacts. If the change affects transactions or data access, check roles and profiles that grant access. Use SUIM or similar tools.
Assess risk for each consumer. For each affected component, rate the risk: Low (no change needed), Medium (monitor or minor adjustment), High (breaks without update), Critical (revenue-impacting failure).
Define testing scope. List what must be tested: unit test, integration test, regression test, user acceptance test. Name the tester and the test data requirements.
Define rollback plan. How can the change be reversed? Transport reversal, config rollback, data restore, or emergency procedure?
Document in a Change Impact Assessment. Use the template below or the Artifact Templates page.
Obtain approval. The assessment must be reviewed by the functional owner, integration lead, and change manager before implementation.

Decision rules

If the change affects a table or field used by more than one interface, treat the risk as High until each interface is verified.
If the change introduces a new mandatory field, check all creation channels (GUI, API, EDI, batch) before approving.
If the change affects master data, check replication and synchronization settings in all target systems.
If the change affects a background job schedule, check all dependent jobs and their schedules.
If the change affects authorization objects, test with at least one user from each affected role.
If no rollback plan exists, do not approve the change.
If testing cannot be performed with representative data, delay the change until test data is available.
If the change was developed in DEV but the object exists differently in PRD, verify the production state before impact analysis.

Deliverables

Change Impact Assessment — The primary artifact. See Artifact Templates for the full format.
Affected Component List — A table of all systems, interfaces, processes, and reports affected, with risk levels.
Test Plan — What to test, who tests, with what data, and what success looks like.
Rollback Procedure — Step-by-step instructions to reverse the change if it fails.

Templates

Change Impact Assessment (compact)

---
artifact: Change Impact Assessment
id: CIA-001
date: YYYY-MM-DD
change: Description
status: draft | reviewed | approved
---

## Change description


## Change driver


## Systems affected


| System | Component | Risk | Action Required | Owner |
|--------|-----------|------|-----------------|-------|
| SAP PRD | T052 | Medium | Update dunning config | FI Lead |

## Data affected


## Interfaces affected


| Interface | Direction | Risk | Action Required | Owner |
|-----------|-----------|------|-----------------|-------|
| INVOIC02 | Outbound | High | Update segment version | Integration |

## Processes affected


## Stakeholders affected


## Testing required


| Test | Tester | Data | Success Criteria |
|------|--------|------|------------------|
| Sales order creation | SD Team | Customer 12345 | Order creates without error |

## Rollback plan


## Risk level


## Approval required


## Owner


## Related changes

Quality checklist

The change is described with exact object names, table/field references, and current versus proposed values.
At least one direct consumer (program, report, transaction) was identified through where-used search.
All interfaces that touch the changed object were checked and documented.
All business process steps that depend on the object were identified.
Each affected component has a risk rating and a required action.
A test plan exists with named testers, test data, and success criteria.
A rollback plan exists and has been validated as technically feasible.
The assessment was reviewed by the functional owner and change manager before approval.

Common mistakes

Mistake: Assuming a change is "small" without checking where-used. Consequence: A single config field change breaks three interfaces and a custom report.
Mistake: Checking only the primary system and ignoring connected systems. Consequence: The change works in SAP but fails in CRM, BW, or the data warehouse.
Mistake: Not testing with realistic data. Consequence: The change works in QAS with simple test data but fails in PRD with complex real-world records.
Mistake: Omitting the rollback plan. Consequence: When the change fails, the team spends hours improvising a reversal under pressure.
Mistake: Not involving the integration team early. Consequence: Interface impacts are discovered after go-live, when messages are already failing.

Agent instructions

When using this skill, an AI agent must:

Demand precision. Ask for the exact object, table, field, transaction, or configuration path being changed. Do not proceed with vague descriptions like "update the sales config."
Systematically check consumers. Ask the user to run where-used searches or provide interface documentation. Do not assume you know all consumers from general knowledge.
Separate direct from indirect impact. Direct impact: the object itself changes. Indirect impact: a derived value, dependent job, or downstream system is affected. List both.
Always ask for the rollback plan. If the user does not have one, refuse to approve the change in the assessment and flag it as a blocker.
Produce a Change Impact Assessment. Use the template above. Fill every section. If a section is unknown, state what information is missing and who can provide it.
Link to Atlas diagnostics for interface and integration checks. Reference the relevant Atlas pages for IDoc, RFC, or background job diagnostics when interfaces are affected.
Do not invent system names or interface IDs. Use only the systems, interfaces, and objects the user confirms exist in their landscape.
Flag high-risk combinations. Any change that affects master data + interfaces + batch jobs should be flagged as High or Critical risk by default.

Related skills

Incident Triage — Use when a change has already caused an incident.
Root Cause Analysis — Use when a change caused unexpected failures and you need to understand why.
Integration Observability — Use to understand how interfaces are monitored before and after changes.
Solution Architecture Review — Use for larger changes that require architectural assessment.

Related Atlas pages

SAP IDoc Status Diagnostics — When interfaces are affected.
SAP Background Job Diagnostics — When job schedules change.
SAP Business Partner Replication Diagnostics — When BP or CVI changes are planned.
SAP Incompletion Procedure Diagnostics — When new validations or mandatory fields are introduced.
SAP AMS Operating Model — How change management fits into AMS operations.

Verification status and limitations

This skill is a public working interpretation of change impact analysis practice. It is not official SAP change management documentation. The where-used tools and cross-reference capabilities vary by SAP release and system configuration. Some landscapes lack comprehensive interface documentation, making indirect impact identification difficult. The skill assumes the user has access to development and quality systems; restricted production-only access limits the depth of analysis.