Process hierarchy

To own a process you need to know where it starts, where it ends and what is inside it. A process hierarchy breaks the business into levels, from the broad end-to-end process down to the individual steps people perform in SAP. It gives the process owner a map: what they own, who does each part, and which SAP content supports it.

Levels

Different frameworks name the levels differently. SAP Signavio guidance describes a value chain at the top, process areas below it, then end-to-end processes modeled in BPMN, then sub-processes, and notes that most organizations use three to five levels. SAP also groups its offering into end-to-end processes such as lead to cash, source to pay, design to operate and recruit to retire, with finance processes often described as record to report. Pick one scheme, define it once, and use it everywhere.

Linking to SAP content

SAP Best Practices content, browsable in SAP Signavio Process Navigator, describes standard processes as scope items with IDs, process flows, and test scripts. Contoso links its level 3 processes to scope items: sell from stock to BD9, procurement of direct materials to J45, and so on. That link pays off repeatedly: fit-to-standard workshops start from the scope item, test cases start from its test script, and release information about the scope item tells the process owner what an upgrade changes. Check the current scope item IDs and names in Process Navigator for your release.

Variants

One process often runs in several variants. Contoso sells alternators to fleet customers under contracts with negotiated prices and to aftermarket distributors from a price list; both are sell from stock, but credit rules, pricing and output differ. Record variants under the level 3 process rather than creating separate processes, and decide as the owner which variants are justified. Every variant multiplies design, test and training effort, so a variant should exist because the business needs it, not because two departments never agreed.

The process owner uses the hierarchy in three ways: to see the full scope of what they own, to check that every step has a responsible role and test coverage, and to judge the impact of a change request or SAP release on their processes.

Where the hierarchy lives

Keep the hierarchy in one place that the project and the run organization share. Many SAP projects hold it in SAP Cloud ALM, where processes are linked to requirements, test cases and defects, or model it in SAP Signavio Process Manager. A spreadsheet works for a small company if it is controlled. What matters is that test cases, training material and change requests all refer to the same process names and IDs.