Lesson 1 of 5
Sources of change
12 min
Listen to this lesson
Change impact analysis answers one question for every release: given what changed, which business processes could behave differently, and therefore what must we test? Answer it badly and you either test everything (slow and expensive) or test what you happen to remember (fast and dangerous). Answer it well and regression shrinks to what matters, with a written reason for every inclusion and exclusion.
The analysis starts with a complete inventory of change. In an SAP landscape, change arrives from two directions: SAP delivers it, and your own team makes it. Both reach production through the same transport landscape (development, quality, production), but they look very different when you try to analyze them.
Change delivered by SAP
- Release upgrades, for example from SAP S/4HANA 2023 to SAP S/4HANA 2025. These bring new functions, changed behavior and sometimes removed or deprecated features.
- Feature package stacks and support package stacks within a release. They deliver corrections and, for feature packs, selected new functions.
- SAP notes implemented individually (in ABAP systems with the Note Assistant,
SNOTE). A note can correct a single program or change behavior across a whole area. - Legal and regulatory changes, such as tax and statutory reporting updates, often delivered as notes or in support packages.
- Cloud updates: SAP S/4HANA Cloud Public Edition receives upgrades and smaller updates on a schedule SAP publishes, with no option to skip them, so impact analysis becomes a recurring routine.
Change made by your own team
- Configuration (customizing): pricing procedures, account determination, document types, output settings, tolerances. Usually transported in customizing requests.
- Custom code: reports, enhancements, BAdI implementations, user exits, custom Fiori apps, and modifications of SAP objects. Transported in workbench requests.
- Master data and data-like settings: condition records, bank details, number ranges, some tables maintained directly in production. Often not transported at all.
- Integration: interface mappings, IDoc and API settings, middleware flows, partner profiles, external system changes on the other side of the interface.
- Security: roles, authorizations and Fiori catalogs, which decide who can do what.
| Change source | How it arrives | Visibility to tools | Typical impact |
|---|---|---|---|
| Release upgrade | Upgrade project | Release documentation; very large object lists | Broad; behavior changes across many processes |
| SAP note | Note Assistant (SNOTE) or support package | Good: changed objects listed | Narrow to medium; check side effects |
| Configuration | Customizing transport | Medium: table keys visible, effect is data-driven | Can change behavior widely with no code change |
| Custom code | Workbench transport | Good: objects listed; dynamic calls hidden | Depends on where the code runs |
| Master data / direct table maintenance | Maintained in production | Poor: often no transport at all | Can change pricing, payments, valuation |
| Integration | Transports plus middleware and partner changes | Poor across system boundaries | Orders, invoices or payments lost or wrong |
Building the change inventory
For Contoso Motor Co.'s first post-go-live release (R2), Luis's release calendar lists 46 transports, a feature package stack update and 12 SAP notes. Priya asks the change manager for an inventory with one line per item: the transport or note number, its owner, the requirement or incident it implements, the object list and a one-sentence business description. Transport object lists come from the Transport Organizer (SE09 / SE10); the business description has to come from a person.
What would you do?
Contoso's change inventory for R2 lists 46 transports and 12 notes. Maria mentions in passing that the pricing team will load new fleet rebate condition records for Great Lakes Fleet Services the same weekend. The records are maintained directly in production. Should they be in the impact analysis?
Cadence matters
Impact analysis is easiest when change arrives in predictable packages. Contoso's release calendar bundles changes into a monthly minor release and a quarterly major release, with emergency fixes handled separately. Each package has a scope freeze date after which new transports go to the next release unless the change advisory board grants an exception. A freeze gives the test lead a stable inventory to analyze; every exception reopens the analysis for the items it adds.
- Week −4Scope freezeChange inventory compiled: transports, notes, stack updates, data and interface changes
- Week −3Impact analysisObjects to processes, release information, SME review
- Week −3Scoped list approvedOwners confirm inclusions, exclusions and depth
- Weeks −2 to −1Test executionBaseline, impacted regression, targeted tests; late changes re-scoped
- Week 0Sign-off and importResults against the scoped list; transports imported to production
- Change comes from SAP (upgrades, feature and support packages, notes, legal changes) and from your team (configuration, code, data, integration, security).
- Build a change inventory with one line per item: number, owner, purpose, objects and a business description.
- Configuration, master data and integration changes are poorly visible to object-based tools.
- Ask explicitly for changes that do not travel in transports.
Check your understanding · not graded
Lesson check
1. Which change source is least visible in transport object lists?
2. Which transaction is used to implement individual SAP notes in an ABAP system?
3. What makes Public Edition impact analysis a recurring routine?
4. Why does each inventory line need a business description from a person?