Lesson 2 of 5
Objects to processes
11 min
Listen to this lesson
An object list is not a test scope. "Function module Z_FLEET_REBATE_CALC changed" means nothing to a process owner. The core of impact analysis is the translation from changed technical objects to affected business processes and process steps, so that you can pick the test cases that exercise them.
The mapping chain
- Changed objectProgram, class, function module, table entry, form, app
- Where it runsWhich transactions, apps, jobs and interfaces call it
- Process stepWhich step in the process hierarchy uses those transactions and apps
- Usage filterIs that step actually executed in production, how often, by whom
- Test casesWhich existing tests cover the step; which new ones are needed
Step 1: where does the object run?
For code, the developer's where-used list (in the ABAP Workbench, for example SE80 or the ABAP development tools) shows which programs, transactions and other objects reference the changed object. For configuration, the functional consultant knows which processes read the setting: an account determination entry affects billing and goods movements; a tolerance key affects invoice verification. For forms and outputs, the output determination tells you which documents use them.
Step 2: from transactions to process steps
Your process hierarchy (in SAP Cloud ALM, SAP Solution Manager or your process model) should record which transactions and apps each process step uses. That assignment is what turns "VF01 and the Create Billing Documents app" into "Order to cash, step: create customer invoice". Without it, every analysis becomes a manual hunt. If your hierarchy lacks these assignments, adding them for the main value streams is one of the best investments a test team can make.
How SAP tooling approached this
SAP Solution Manager offered the Business Process Change Analyzer (BPCA). It relied on technical bills of materials (TBOMs): traces of all ABAP objects touched while a process step was executed, stored against that step. For a change event such as a transport or support package, BPCA compared the changed objects with the TBOMs and listed the affected process steps, from which test plans could be built. SAP states that mainstream maintenance for SAP Solution Manager 7.2 runs until the end of 2027 and recommends moving to SAP Cloud ALM, so check which impact analysis capabilities your Cloud ALM tenant and your other tools provide today. The concept, however, is timeless: trace processes once, compare with change, and let the overlap suggest scope.
- Record a traceRun a process step and capture every ABAP object it touches
- Store against the stepThe trace (TBOM) is saved on the step in the process hierarchy
- Change eventA transport, note or support package arrives with its object list
- CompareChanged objects matched against the stored traces
- Suggest scopeAffected process steps listed; test plan built from them
Step 3: filter with usage
Usage information is the filter that keeps scope sane. If a changed function module is called by forty transactions but only three are used in Contoso's production system, the other thirty-seven are not where your business risk lies. Sources include the workload monitor ST03N for transaction and report usage, the ABAP Call Monitor SCMON and its aggregation SUSG for executed ABAP code, and, in Solution Manager landscapes, Usage and Procedure Logging (UPL).
| Changed object (R2) | Where it runs | Process step | Production usage | Scope decision |
|---|---|---|---|---|
| Custom pricing routine for fleet rebate | Pricing in sales orders and billing | O2C: create sales order; create invoice | Every order for fleet customers | In scope, high depth |
| Delivery note form | Output for outbound deliveries | O2C: print delivery note at shipping points 1710 and 1720 | Daily | In scope, both shipping points |
| Custom stock aging report | Report only | Inventory analysis | Not executed in 6 months | Owner confirmation, smoke test |
| Tolerance key change | Supplier invoice verification | P2P: post supplier invoice | Daily for Lakeside Components | In scope: within, at and beyond tolerance |
Tracing Contoso's R2 objects to process steps and filtering by usage.
What would you do?
A developer changed a shared custom function module used to read Contoso's alternator configuration. The where-used list shows 23 calling programs. SUSG shows that only 4 of them ran in production in the last six months, all in order to cash. How should Priya scope the regression?
Doing it without a dedicated tool
Many teams have no automated change analysis at all. The method still works by hand, just more slowly. Export the transport object lists into a spreadsheet, add a column for "where it runs" filled in by the developer or consultant who owns each transport, map those transactions and apps to process steps using the process hierarchy, then add usage figures from Basis. Even a rough version of this, done consistently every release, beats scoping from memory. Keep the spreadsheet from release to release: object-to-process mappings you worked out last quarter are still mostly valid this quarter.
- Export object listsTransport objects from the Transport Organizer into a spreadsheet
- Where it runsTransport owner fills in transactions, apps, jobs and interfaces
- Map to stepsProcess hierarchy turns transactions into process steps
- Add usageBasis supplies ST03N or SUSG figures per transaction or program
- Decide and keepScope decision per step; mappings reused next release
- Impact analysis translates changed objects into affected process steps.
- Use where-used lists for code and consultant knowledge for configuration.
- Assign transactions and apps to process steps in the process hierarchy; it makes every later analysis faster.
- Solution Manager's BPCA compared change with process traces (TBOMs); the concept still applies.
- Filter with production usage, then check rarely used programs with owners.
Check your understanding · not graded
Lesson check
1. What did a TBOM record in SAP Solution Manager?
2. What turns a list of transactions into a list of process steps?
3. Why filter impact results with production usage?
4. Why re-record process traces after a large release?