Business process variants and change impact analysis with BPCA (Part 1 – Introduction)
If you are documenting your business scenarios and business processes in a SAP Solution Manger project/solution, you may ask yourself:
- How should I document my process variants?
- What is the right level of details I want to have my variants documented with?
There are different ways to document the business process variants in the SAP Solution Manager project/solution. When choosing the documentation approach, you should consider what you want to achieve and what will be your business process documentation used for. It is important to know how the other Application Lifecycle Management scenarios integrate with Solution Documentation and what information of the business process details is used.
First, you should answer a question: What is a business process variant?
In the following SCN document (Business Process Variant
“A Business Process Variant should differ to another at least in one of the following:
- Flow of documents
- Business Objects needed
- Lifecycle schema of the Business Objects (status and status transitions)
- A2A/B2B (Application to Application/Business to Business) message choreography or choreography with direct interactions with other Business Processes.
- A Business Process Variant is not just an alternative UI.
- A Business Process Variant is not just another sequence a user decides to perform tasks on the UI (User Interface).
- Two Business Process Variants differ in the way the Business Process flows. The difference is so important that the variants are to be considered separately in a business process analysis. The difference is so fundamental that it typically needs to be treated by special software functionality and not just configuration, if implemented in software. “
Although, this is a modeling description of a process variant it is applicable also to our technical documentation of a process variant in the SAP Solution Manager project/solution. If you decide to create a new process variant you should have a reason for it, for example:
- There are significant differences in functionalities what require a different functional/integration test script or test set
- There are differences in flow of documents and interactions with 3rd party systems resulting in a different business process monitoring setup
- There are functional and customizations differences of such a process in different regions that requires a separate set of documentation to be created. This in turn drives to different set of test scripts (e.g. per region).
The business process structure should have the right granularity (the business process step shall be understood as the transactional level, not as a task or activity). Assigning transaction codes on the “Transactions” tab (including custom transactions and programs) to the business process steps is important for the future usage of Solution Manager scenarios for ALM.
Quite often, there will be hundreds of business processes and dozens of variants the processes run with, but it impossible to documents precisely everything. We have to keep the documentation at a reasonable and manageable level. At a level, that is supporting our ALM strategy and the other ALM scenarios the business process documentation is used for (e.g. the testing scenario).
The Solution Documentation (e.g. the business process structure/hierarchy (BPH) with the executables) is foundation for the Test Management scenario, in particular for the change impact analysis with the Business Process Change Analyzer (BPCA). The use of BPCA is dependent on the assignment of transactions and other executable objects (including custom executable objects) in the business process structure. Based on this, the TBOMs (Technical Bill of Material) are created and used as the basis for the change impact analysis.
There are different ways to create the TBOMs. The TBOM can exactly represent a process step variant (a transaction variant) if it is dynamically created or it can be an accumulation of process step variants if it is semi-dynamically created.
Now, you see the connection: a process variant <-> a TBOM variant.
But what possibilities do we have to document the process variants in the SAP Solution Manager project/solution?
You may come across the following option:
- Replication method
- Accumulation method
- Executable variants.
Further on, I will discuss the replication method and the accumulation method and their appliance in the BPCA and Testing scenarios.
The executable variants have been described in this blog Documenting business process step variants in SAP Solution Manager 7.1 SP06 (http://scn.sap.com/community/it-management/alm/blog/2013/02/20/documenting-business-process-step-variants-in-sap-solution-manager-71-sp06 ). The concept of executable variants will be discontinued in SAP Solution Manager 7.2.