Lesson 2 of 5
Impact assessment
8 min
Every SAP release comes with hundreds of changes. Most will not touch your processes. A few will, and some of those will change what users see, what the system posts, or what an interface receives. Impact assessment is the work of finding those few, early enough to test them and to tell people.
The process owner does not do this alone. IT and the platform team look at technical impact: custom code, interfaces, roles, performance. The process owner answers the business question: which of my process steps will behave differently, and how will we know they still work?
Where to look
- What's New Viewer on the SAP Help Portal: a filterable list of new and changed features per release and feature pack, which you can filter by product, line of business and release and export to a spreadsheet.
- Release Assessment and Scope Dependency (RASD), for Public Edition: SAP's tool that filters the changes in a release down to the scope your tenant actually uses (apps, scope items, APIs and CDS views that are new, changed, deprecated or deleted), and can create follow-up tasks in SAP Cloud ALM.
- SAP Road Map Explorer: planned future innovations, useful for the adoption decisions in the next lesson rather than for this release.
- Release notes and simplification information for a Private Edition base release upgrade, plus your platform team's custom code and interface checks.
- In-app notifications: after an upgrade, the Fiori launchpad can show a banner and a "what's new" panel for changed apps. Useful for users, too late for assessment.
The catch with the What's New Viewer is that it lists everything. To judge relevance you need to know which apps, scope items and processes are active in your system. That is why a current process model (scope items, the apps each role uses, the interfaces each process step touches) pays for itself at every release.
From change list to test list
- CollectExport what's new for the target release, filtered to your products and lines of business
- FilterKeep changes to apps, scope items and objects your process actually uses
- RateClassify each: no impact, user-visible change, behavior change, or removal or deprecation
- MapTag each relevant change to the process steps and regression scenarios that cover it
- AssignName an owner for the test and for any training or communication
- TrackRecord the list as tasks so nothing is lost before the regression window
The rating step is where judgment matters. A cosmetic change to an app layout is a training note. A change to how a field defaults or how a document is posted is a behavior change and needs a test. A deprecated app that your users rely on is a removal: you need a replacement, training and a date.
Agree the scale with the other process owners so a "behavior change" means the same thing in finance and in order-to-cash. When ratings are consistent, the PMO can add up the impact across processes and see whether a release is light or heavy before committing a date.
| Impact level | Example | Response |
|---|---|---|
| None | New app for a process Contoso does not run | Record as not relevant; no action |
| User-visible | New filter or column layout in Manage Journal Entries | Short note to users; spot check in regression |
| Behavior change | Changed default for a field on supplier invoices | Targeted test plus regression scenario; process owner review |
| Removal or deprecation | An app your AP team uses is deprecated in favor of a successor | Plan the switch: replacement app, role update, training, date |
A simple four-level scale is enough. Consistency matters more than precision.
- Does the change touch an app, scope item, interface or object we use?Yes → continue · No → record as not relevant
- Is something removed or deprecated?Yes → removal: plan replacement, roles, training and date · No → continue
- Does it change what is posted, defaulted, checked or sent?Yes → behavior change: targeted test plus regression scenario · No → continue
- Does it only change what users see?Yes → user-visible: note to users and spot check · No → recheck the first question
Working with the technical assessment
Run the business review alongside the technical one, not after it. IT's checks on custom code, enhancements, interfaces and authorizations often explain a business impact: a changed standard API can break the bank statement interface, and a renamed app may need its business role updated before anyone can open it. Meet once, compare lists and make sure every technical finding that touches a process step has a business owner and a regression scenario, and every business change has someone checking the technical side.
Do not forget your own changes
SAP's changes are only half the impact. Contoso's own transports, enhancements and configuration changes in the same release need the same treatment. Priya's team keeps a single impact list for the release, with a "source" column (SAP feature pack, SAP correction, Contoso enhancement, configuration change) so the regression plan covers both.
What would you do?
Two weeks before the Public Edition test system is upgraded, Maria asks whether she needs to do anything about the release. Contoso has not opened the RASD output yet. What is the best next step?
- Impact assessment finds the few changes that touch your process, early enough to test and communicate.
- Sources: What's New Viewer, RASD for Public Edition, release notes, and your own transport list.
- Knowing your active scope and apps is what makes filtering fast.
- Rate each change (none, user-visible, behavior change, removal) and map it to regression scenarios with an owner.
Check your understanding · not graded
Lesson check
1. What does the Release Assessment and Scope Dependency tool add over the full What's New list?
2. A field on supplier invoices will default differently after the release. How should it be rated?
3. What makes filtering a release's change list fast?
4. Which changes belong on the release impact list besides SAP's?