Lesson 2 of 5
Risk inputs: process criticality, change and usage
13 min
Listen to this lesson
Scoring risks from opinion alone produces a register where everything is high. The fix is to bring evidence into the room. For SAP change, three inputs do most of the work: how critical the process is to the business, what actually changed, and how heavily the affected functions are used in production.
Input 1: process criticality (mostly impact)
Start from the business process hierarchy your project already maintains, for example in SAP Cloud ALM or SAP Solution Manager, or in your SAP Signavio process model. For each process, ask the process owner what happens if it stops or produces wrong results for a day, a week, a month-end. The answer is mostly about impact: revenue, cash, customer service, legal and regulatory exposure, safety, and how quickly a failure would be noticed.
| Impact factor | Question to ask the process owner | Contoso example |
|---|---|---|
| Financial | Could a failure misstate the books or move money wrongly? | Billing, payment run, inventory valuation |
| Operational | Would shipments, production or receipts stop? | Goods issue at shipping point 1720 |
| Customer | Would customers see wrong prices, late goods or wrong invoices? | Fleet pricing for Great Lakes Fleet Services |
| Compliance | Could a failure break tax, audit or legal rules? | Sales tax, SoD controls, statutory reports |
| Detectability | Would anyone notice quickly, or only at month-end? | Wrong account assignment is silent until close |
| Workaround | Is there a manual workaround, and how costly is it? | Manual invoice correction for a few orders |
Impact factors. Low detectability raises effective impact: silent failures do the most damage.
Input 2: what changed (mostly likelihood)
Change is the main driver of likelihood. Something that did not change, in a stable environment, is less likely to break than something that did. Collect the change content of the release: the transport requests and their object lists (visible in the Transport Organizer, SE09 / SE10), SAP notes implemented, the support package or feature package stack level, configuration changes, master data rule changes, and interface changes. The companion course on change impact analysis goes deep on tracing these to processes; here you need only enough to judge likelihood.
- Size and complexity of the change: a new pricing procedure is riskier than a text change.
- Novelty: first use of a function at Contoso (for example a new output channel) carries more risk than a repeat.
- Defect history: areas that broke in the last release or in earlier test cycles tend to break again.
- Custom code: enhancements and modifications in the affected area add risk because they are tested only by you.
- Team and build factors: rushed builds, late changes and new developers raise likelihood.
Input 3: production usage (both)
Usage data tells you which transactions, apps, reports and programs are actually executed in production, how often and by how many users. It acts on both sides of the score. High usage raises impact (more users and documents affected) and also raises the chance that an unusual variant will be hit. Zero usage is just as useful: a changed program nobody runs is a low-risk change.
Sources you can ask your Basis team for include the workload monitor ST03N, which shows transaction and report usage by period; the ABAP Call Monitor SCMON, which records which ABAP programs, classes and function modules are executed; and SUSG, which aggregates SCMON data over a longer period. In SAP Solution Manager landscapes, Usage and Procedure Logging (UPL) served the same purpose. Availability depends on your release and on what has been switched on, so check with Basis before you plan around it.
- Every monthPeriod-end closeAccruals, allocations, settlements and valuation for company code 1710
- Every quarterQuarter closeRevenue reporting where account determination errors surface
- Once a yearAnnual price updateNew fleet and aftermarket prices for CMC-ALT-100
- Once a yearYear-end closeBalance carryforward, special periods and new fiscal year
- When publishedTax rate changesNew rates for ship-to states take effect
- Rarely, unplannedRecall processRuns only when a product problem occurs
| Input | Mainly informs | Where it comes from | Typical trap |
|---|---|---|---|
| Process criticality | Impact | Process owners, process hierarchy | Every owner says their process is critical |
| Change content | Likelihood | Transports, notes, stack level, configuration log | Missing configuration and master data changes |
| Production usage | Both | ST03N, SCMON / SUSG, UPL | Periodic processes look unused |
| Defect history | Likelihood | Previous cycles, incidents after earlier releases | Ignoring production incidents |
What would you do?
Contoso's release R2 changes a custom report that lists open deliveries. SUSG data for the last six months shows the report was never executed in production. The developer asks Priya whether it needs a full regression set. What is the most reasonable call?
Putting the inputs together
For each candidate risk, gather the three inputs on one line before the workshop. You do not need precise numbers; you need enough evidence that owners can argue about facts rather than feelings. Here is how Priya prepared three of Contoso's R2 risks:
| Risk | Criticality | Change | Usage (last 6 months) | Draft view |
|---|---|---|---|---|
| Fleet rebate pricing for Great Lakes Fleet Services | High: revenue and customer invoices | New rebate condition logic, custom routine | Pricing runs on every one of thousands of orders | Likely high impact, high likelihood |
| Goods issue at shipping point 1720 | High: shipments stop | New storage location 172A setting | Daily, several hundred deliveries | High impact, medium likelihood |
| Open deliveries custom report | Low: informational | Layout change | Not executed | Low impact, low likelihood; confirm with owner |
Preparing evidence per risk. The workshop confirms or corrects the draft view.
Keep the evidence attached to the risk in the register. When someone asks six weeks later why a process was tested lightly, "it was not executed in production in six months, and Maria confirmed nobody relies on it" is a far better answer than "we ran out of time".
- Process criticality mainly informs impact; change content mainly informs likelihood; usage informs both.
- Collect change content from transports, notes, stack level, configuration and master data rules.
- ST03N, SCMON and SUSG (or UPL in Solution Manager landscapes) show what is really used in production.
- Overlay periodic processes such as year-end on usage data, or they will look unimportant.
Check your understanding · not graded
Lesson check
1. Which input mainly drives the likelihood side of a risk score?
2. Which transaction aggregates ABAP Call Monitor data over a longer period?
3. Why is low detectability a reason to raise the effective impact of a risk?
4. What is the main blind spot of a three-month usage sample?