Registration

Dear SAP Community Member,
In order to fully benefit from what the SAP Community has to offer, please register at:
http://scn.sap.com
Thank you,
The SAP Community team.
Skip to end of metadata
Go to start of metadata

Process step library

In the process step library, you ensure that every business function or capability required to operate your business is represented by a process step. You define the process steps according to the required business capabilities, regardless whether there is an application or IT system available. Also, manual steps or steps supported by non-SAP environments become process steps.

Definition

The process step library is the software-independent inventory of (business) functions, also called capabilities, a company needs to maintain in order to run its business.
The structure of the process step library follows the organizational structure starting with rather coarsely grained groupings to finer levels with the actual process steps.

 

Recommendation

In the process step library every process step exists only once. The process step library is software-independent and each process step represents a needed business capability. The process step library should follow your organizational structure and you should not use more than 5-7 levels. Please check the appendix for naming conventions.

The process steps available in the process step library are called process step originals. When you re-use one of the process step originals in a process, you also add a process step reference to your process. It references the original and can have a different title than the original. This is important to be able to follow business language.

For example, a Create Sales Order process step original may be added to a process as Order Entry if this is how a business refers to it. Either name would still reference the same original but follows the rules of the occurrence. The same applies to assignments used to describe an element in more detail. References and originals have their own sets of attributes and assignments. For instance, you can add a generic process step description and configuration guide to a process step original while you add occurrence specific documents to the reference. With this approach you can add documentation at the right place and you avoid double documentation. At the same time, at an occurrence you keep track on documentation which was attached on original levels.

If you have to deal with process step variances, the environment offers you directly to define multiple process step references pointing to one single process step original. You can accumulate multiple usages in one or multiple processes on one original. However, it can be required to represent step variation by a different definition. This will be especially the case when a specific execution variant shall be reused in several specific business processes. In this case additional process step origins can be created. The process step variants can be then collected in a dedicated folder grouping the same capability but in different variations.

Recommendation

You should accumulate as much usages as possible on the defined process step originals and you should avoid the creation of “equal” or very similar process step originals.
You should document aspects like use case documents, functional specifications, functional KPI document, end user training material, single functional test cases, or TBOMs at the process step originals.

If you want to get a jump-start on the process step library, you can create your process step library also based on the executables you have available in the executable library.

  • No labels