Many companies are reluctant to apply changes to their SAP solutions because important or even mission-critical business processes might be affected by these changes. Because of this, translating technical information about planned changes on programs, tables, or user interfaces into an easy-to-understand business process view is crucial. Only then can the company make an informed decision on how to deal with planned changes.

There are many reasons why changes must be deployed to SAP solutions, including:

• Maintenance activities provided through SAP Support Packages
• Adjustments of the business process logic provided by customizing changes
• New or enhanced functionality delivered by SAP Enhancement Packages (EhPs)
• Extension of SAP functionality to partner and non-SAP applications via custom code developments or interfaces

Although IT departments fully know which technical objects are changed, they often don’t receive insight into the important business processes that are affected by these changes. Very few tools are available to link technical piece list information on transport requests to the business processes that require these objects during process execution. To address this, many companies delay necessary changes or perform time- and resource-intensive regression tests for major parts of their SAP solution.

Most companies have a restricted time window for performing regression tests and because of this cannot test all mission-critical business processes. As a result, many IT departments have to make an educated guess about required regression tests instead of following a professional, risk-based identification of test scopes.

Business Process Change Analyzer (BPCA) is a new capability in SAP Solution Manager 7.0 EhP1 that significantly reduces the time and resources required for regression tests after SAP change events. Basic and advanced analysis options enable IT and QA departments to understand the effects of planned changes to SAP system landscapes with high precision, and thus support a better dialogue between IT and business departments. I’ll describe a change impact analysis, and then show you how BPCA can perform an impact analyses for a variety of different changes.

Performing a Change Impact Analysis

A change impact analysis is performed by first selecting the SAP objects that have been changed and then identifying business processes that use these changed objects. To perform this analysis, you must have detailed technical knowledge about both the business processes and the software changes that are deployed in your SAP landscape.

SAP software changes are handled via transport requests and provide you with a piece list of changed objects. This is a good starting point for your change impact analysis. Software changes can include code changes, user interface changes, and configuration changes, which can in turn alter the business logic, flow of screens, and appearance for the end user. Software changes are triggered by SAP through Support Packages and EhPs, or triggered by SAP users via configuration changes and custom code developments.

The identification of business processes that uses a changed object is a more complex task. Two general approaches are available: static analysis and dynamic analysis.

Static Analysis

Static analysis takes place when a where-used analysis is executed on all SAP programs to check whether a changed object is part of these programs. It involves the identification of business processes affected by software changes via code analysis during design time. A business process is flagged as impacted when a changed SAP object is part of the code line of the associated transaction or other executable. You can perform this analysis without in-depth knowledge of how your company executes its business processes, because it involves simply looking at the code line of the SAP module pool (i.e., the program behind a transaction code). You can derive the assigned transaction codes or executables to identify the list of affected business processes.

Several third-party products are available that follow this basic approach. Most of them provide additional logic (besides the identification of transactions that include changed objects) to help you find out whether your company is using the changed object transactions and their importance, as well as the associated regression tests. The advantage of a static analysis is that you can apply it to a wide range of business processes to check whether they are affected. However, this approach includes a few disadvantages:

• Many business processes are flagged as impacted when they are actually not. This is because only a subset of the code is used during client-specific process execution. The changed objects might be part of a transaction, but the individual execution of this transaction might not process this part of the coding at all.
• Not all impacted business processes are flagged as impacted. This is because dynamic calls, which are performed from one program to another at the business process runtime, cannot be identified using static analysis. Dynamic behavior can result from the programming style or the client-specific configuration of the business processes. This is a significant disadvantage of the static approach and leads to less precise results.

Dynamic Analysis

To increase the precision of your analysis and avoid the disadvantages of static analysis, you can use a different approach called dynamic analysis. This approach involves the identification of business processes affected by software changes via comparison of changed SAP objects against dynamically created object usage lists traced at runtime.

During preparation phases, users execute important business processes while a background program traces all SAP objects used during the execution. The trace result is called Technical Bill of Material (TBOM) and it contains all SAP objects (e.g., programs, function modules, customizing tables, and authorization objects) required to perform a business process execution. The TBOM is stored as part of the Business Blueprint. During an analysis phase, the change impact analysis compares the list of changed objects of one or multiple transport requests against TBOMs of selected or all business processes of the business blueprint. The dynamic approach provides several advantages:

• High precision. Business processes are flagged as impacted only for circumstances in which changed SAP objects are used during business process execution. Objects that are changed but not used during execution do not cause a business process to be flagged as impacted.
• There are no restrictions for dynamic calls branching from one program to another program during process execution, which results in more accurate analysis results
• Users with modified or extended SAP applications can use this approach with the same precision
• The TBOM for each business process includes information about all SAP objects used during process execution, ranging from code objects and user interfaces to configuration and master data tables. This allows for new, additional verification of configuration changes that affect mission-critical business processes that was never available before.

You can use BPCA to perform both static and dynamic analysis for ABAP-based business applications.

Preparing to Use BPCA

The following preparations are required for the change impact analysis performed by BPCA.

It is recommended that you document at least basic information about critical business processes using the Business Blueprint functionality in SAP Solution Manager (transaction SOLAR01) as shown in Figure 1. You can also document business processes manually, through their selection from the Business Process Repository, or semi-automatically with usage statistics analyzed by the Solution Documentation Assistant. Business processes in a Business Blueprint are used as anchor for storing the BPCA TBOM (i.e., the trace result of the used SAP objects for a particular business process).

Figure 1

Business process documentation in the Business Blueprint

Users can check the availability and status of the TBOMs for business processes using standard reports provided by SAP Solution Manager. Use transaction SOLMAN_WORKCENTER to reach the new HTML-based Test Management Work Center (Figure 2). Here you can apply filters to check the availability of TBOMs, especially for mission-critical processes.

Figure 2

Status report to check availability of TBOMs for Business Blueprint

Most users without extensive technical skills can create TBOMs by executing business processes. To start the trace, select the business processes within the Business Blueprint. I used the example of a sales order. By clicking the attribute icon (highlighted in Figure 1), you can view the content of existing TBOMs or directly start the business process execution in the assigned SAP system in trace-creation mode, which is accessed using the attribute icon.

During business process execution, all used SAP objects are collected via a background trace. At the end of the execution, the trace is stored and assigned to the business process as a TBOM.

The TBOM acts as the foundation for subsequent change impact analysis. You can view existing TBOMs by clicking the attribute icon for a selected business process within the Business Blueprint transaction (SOLAR01). Each TBOM contains the technical information found in Table 1, though I have not included a complete list of the possible attributes. Figure 3 shows an example of a TBOM and its contents.

Figure 3

TBOM for the Sales Order business process

You can apply TBOM filters (globally for all analysis runs or at the process step level) to reduce the list of identified business processes based on client experience, as each client can work with BPCA and turn filters on or off to note how the analysis results differ. Based on the client’s risk-approach, they can use the filter in a stronger or weaker way. These filters can be used to restrict the BPCA results to configuration changes or changes to software component SAP_APPL, for example. These are common restrictions because too many red lights can have the opposite effect — they are just not helpful anymore. The BPCA user wants precise information, but does not want to be overwhelmed with impacts that don’t really matter or significantly alter the results or appearance of a business process. For example, many changes to SAP objects in the SAP_BASIS layer do not affect business transactions. Therefore, you have the option to filter out all objects that belong to SAP_BASIS.

In addition, you can apply TBOM criticality settings to classify particular changes as more or less critical when viewing the BPCA analysis results. For example, you might want to set configuration changes or changes to objects of software components to the highest criticality.

BPCA Change Impact Analysis

You can launch the BPCA change impact analysis in the Test Management Work Center in SAP Solution Manager. In the Test Management tab, select BP Change Analyzer from the menu on the left (Figure 4).

Figure 4

Change impact analysis in the Test Management Work Center

On the left side of the Change Impact Analysis selection screen under the Change Event Scope section, enter the change events that need to be analyzed. For example, you can search for all transport requests for a specified SAP system and time interval. On the right side of the selection screen under BP Hierarchy Node Scope, select the business processes for which the change impact analysis should be performed. If these fields are all left blank, the system performs the analysis for all business processes. You can execute the analysis immediately by clicking the Run button or schedule the analysis as a background job. The system then displays BPCA analysis runs with a result ID that all users with appropriate authorizations can review.

Although multiple types of software changes (e.g., code and customizing changes) can occur during one change event, I’ll describe the various change types separately.

Example: Customizing Changes

In the following example of a sales order type, customizing changes were applied to the Sales document type field and access sequence of conditions (Figure 5). You can reach this screen by entering transaction SPRO and following menu path Sales and Distribution > Sales > Sales Documents > Sales Document Header > Define Sales Document Types.

Figure 5

Customizing change applied to Sales document type

Start the change impact analysis with the following settings in the BPCA selection screen: System, Client, Transport Requests, and Project ID (Figure 6).

Figure 6

BPCA selection screen with values selected

After the execution of the analysis run, the BPCA overview screen shows projects or solutions with affected business processes (Figure 7). In my example, two business processes in the order-to-cash scenario are identified as impacted by the customizing change: Sales Order and Outbound Delivery. The business process title, transaction code or executable by type (e.g., Transaction) and value (e.g., VA01), and the availability of assigned test cases are displayed.

Figure 7

BPCA results overview

For each identified business process, you can display details on the changed SAP objects that caused the business process to be impacted by the change. In the case of my example, the Sales Order business process was identified as impacted by customizing changes. The detail screen, which you can access by clicking the Display Intersection button, reveals the changed customizing tables that are used by the business process (Figure 8). Based on these analysis results, you should include the identified business processes in a regression test to verify correct behavior and execution results.

Figure 8

Details for customizing changes

Example: Code and User-Interface Changes

For my second example, say that code changes are applied to programs SAPMV45A and Dynpro 101 (which is found within SAPMV45A), as shown in Figure 9.

Figure 9

Transport request for code and user-interface changes of program SAPMV45A

When performing a change impact analysis, BPCA identifies the Sales Order business process as affected because program SAPMV45A and its screen SAPMV45A0101 were changed and deployed to the system via a transport request. The change criticality was indicated as Critical based on user settings for software component SAP_APPL (Figure 10). Again, based on the analysis results, your regression tests should include the identified business processes to verify correct behavior and execution results.

Figure 10

BPCA results for code and user-interface changes

Example: Changes Through SAP Support Package

In my third example, imagine that a set of SAP Support Packages has been deployed to the SAP system landscape (Figure 11).

Figure 11

SAP Support Packages

BPCA identifies multiple order-to-cash business processes as impacted when it performs change impact analysis. The BPCA details screen in Figure 12 shows the changed SAP objects that affect the Sales Order business process. As you can see, all changed SAP objects used by the business process belong to software component SAP_BASIS and their criticality were derived as Normal based on user settings. For this change, your organization may decide to exclude these processes from a regression test (see my earlier comments on SAP_BASIS).

Figure 12

BPCA results for deployed SAP Support Packages

Risk-Based Test Scope Identification

Test coordinators who must define the scope of regression tests after change events can also benefit from the BPCA because it includes a feature that can directly generate a test plan that contains all test cases assigned to business processes affected by the change.

To enable this functionality, you must assign manual or automated regression tests to the business processes of the Business Blueprint using transaction SOLAR02. In the review of the BPCA results on the overview screen, click the Create Test Plan button to enable the generation of a test plan in the Test Workbench (Figure 13). The screen shown in Figure 14 appears, allowing you to create a test plan based on test cases assigned to impacted business processes. Subsequently, testers can be assigned to manual tests followed by the execution of manual and automated tests.

Figure 13

BPCA result screen, the starting point to create a risk-based test scope recommendation

Figure 14

Test plan creation based on test cases assigned to impacted business processes

The Future of BPCA

BPCA will provide enhanced functionality with SAP Solution Manager 7.0 EhP2. The following features are planned (but subject to change before the official release):

• Cross-system trace allowing TBOM creation for complex business processes that span multiple systems and user interfaces
• Workflow to enable TBOM creation by business users in production systems
• Automatic TBOM creation via automated test cases
• Extended classification of SAP objects contained in TBOM, which helps clients achieve a more detailed insight into the types of SAP objects used by a business process. This helps bridge the technical view to the business process view. Users can also better apply filters and criticality settings based on this detailed information.
• Advanced functionality to derive business processes impacted by planned activation of business functions delivered in SAP EhPs
• Automatic creation of static TBOMs through a background job to reduce manual effort

Marcus Wefers

Marcus Wefers, senior director of Solution Management, is responsible for SAP's Test Management strategy, including positioning and future development of products and capabilities to support test and quality management, such as SAP Solution Manager, SAP TAO, and SAP Quality Center by HP. Focus areas of his 26 years at SAP include software development, project management, quality management, and solution management for SAP applications in the areas of Financial Consolidation, Profit Center Accounting, SEM, Analytics, Performance and Strategy Management, Business Planning, Corporate Governance, and Application Lifecycle Management. He worked on international SAP customer projects in Europe, the Americas, and APJ. In addition, he is a regular speaker at ASUG conferences, SAPPHIRE, and SAP TechEd.

You may contact the author at marcus.wefers@sap.com.

If you have comments about this article or publication, or would like to submit an article idea, please contact the editor.