If you’ve taken the plunge (or are planning to upgrade) to Solution Manager 7.1, then you need to know how to manage your global templates, implementations, and solutions in 7.1.

I’ll explore how Solution Manager 7.1 has enhanced the transaction SA_PROJECT_UPGRADE and compare and adjust capabilities. The focus of the article is on those features that support the roll-in of process enhancements made in a solution during ongoing support, or in implementations in which enhancements made during localization are advantageous to other groups in the enterprise.

I’ll discuss the application of these features in a process to absorb these enhancements into the global template. For more information on the features specifically related to comparing projects and solutions, see “Discover the Compare and Adjust Functionality Changes in SAP Solution Manager 7.1” by Raquel Cunha.

First, I want to talk about the importance of good process design and development related to these features. The compare and adjust capabilities of Solution Manager offer you many options regarding timing of comparisons, references for comparison, and options for how to absorb changes. 

In the life cycle of performing compare and adjust, the adjust portion updates Solution Manager’s reference information on the project being adjusted. This occurs when you complete the adjustment for an individual identified change in a business process hierarchy. 

Since completing the adjustment on any particular identified change resets the baseline for future comparisons, it is worthwhile to invest some time into exactly how and when your organization performs the compare and adjust activities. 

Likewise, it is important to standardize and centralize the processing of the compare and adjust activities to a small group. This helps reduce the risk of process errors that could hide changes from future comparisons because the adjustment was incorrectly completed.

Take Advantage of a Process or Solution Enhancement Coming from Ongoing Support

During normal operational support, many changes are made to the solution to correct program errors, apply software patches, and deploy business process enhancements. This last group of changes needs to be monitored via a process that:

1. Alerts when a process has implications or opportunities as a process change in the global template
2. Provides a standard approach for accepting or rejecting the change as a candidate for the global template
3. Provides a standardized, repeatable way of incorporating those changes into the global template

For requirements 1 and 3, Solution Manager has advanced features that can provide high levels of automation. Requirement 2 relies more on the people who own and operate the processes, and the people who own and protect the global template.

1. Alerts When a Process Has Implications or Opportunities as a Process Change in the Global Template

The technical parts of this process are the same for virtually any organization. However, the evaluation of the information is subject to different scrutiny for each unique organization.

First I’ll look at how to identify changes in a solution relative to the global template. You won’t be able to cover every possible way a solution could have changed relative to the global template. My focus is to identify the changes and determine whether they should be incorporated into the global template.

The Compare Solution function shows that there has been a change between the solution and source project. From the Solution Directory (transaction code SOLMAN_DIRECTORY), select the solution and follow menu path Utilities > Compare Solution. Be sure to select the Solution radio button to compare changes in the solution (Figure 1).

Figure 1

Compare Solution: Indicator changes to this Project/Solution

In Figure 2, a new process step has been added in the solution as part of a business enhancements release (a minor release performed outside the scope of a project). The example I’m using is for a fictitious company called Child Management Services, Inc., which provides summer day camp for children and is explained in detail in my article “How SAP Solution Manager Can Lead Your Company to Business Process Excellence.” The process step Send Cust Sat Survey has been a step added to the business process Receive happy feedback from child and Parent in the BPH structure, and a transaction added to the step. This indicates that there was a process enhancement implemented since the original design was delivered to the solution.

Figure 2

Change to the process Receive happy feedback from child and Parent

Note in Figure 2 you can tell that something has changed in the business process, but it’s not obvious what has changed. You might infer that since the process step Send Cust Sat Survey has no value in the Source column that it was manually added to the solution. To be sure, click the compare and adjust icon  to illustrate the changes found by the Compare Solution function. Figure 3 shows the Compare and Adjust screen for the Receive happy feedback from child and Parent business process.

Figure 3

Compare and Adjust screen for the process. Note the new step Send Cust Sat Survey on the right side of the screen.

This is where Solution Manager really begins to show its stuff as a manager. The solution got its content for this process originally from the implementation project BPHDMOSMI. Therefore, as you determine whether to incorporate this change into the global template, you should take advantage of this opportunity to update the BPHDMOSMI project. This has the effect of cascading any changes to the affected projects, starting with the one that is the source for the process in the solution.

The compare and adjust function performed on the implementation project BPHDMOSMI identifies the context in the implementation where the change would logically go if there is not enough information from the context within the solution.

First, absorb the change into the implementation project. I recommend this as a standard protocol, not something to be discussed. This approach keeps the implementation documentation current as a side effect of evaluating changes to the solution for consideration of incorporation into the global template.

Run transaction SA_PROJECT_UPGRADE against the BPHDMOSMI project with the successor and the solution identified (Figure 4).

Figure 4

Transaction SA_PROJECT_UPGRADE on the implementation project checking against the solution

Click the compare and adjust icon on the affected nodes of BPHDMOSMI in transaction SOLAR01 to import the changes from the solution.

Cascade the Changes up to the Global Template

Once all the changes have been incorporated into the implementation project, repeat the process that you did for the implementation with the global template. 

Keep a log of the changes you accepted into the implementation project. When you run a comparison of the global template against the changes in downstream implementation projects, you are notified of all the changes that have occurred in the implementation relative to the global template, not just those that have occurred because you retrofit changes to the implementation from the solution. By keeping a log of the process changes you’re working with that are coming up from the solution, you can narrow the scope of your compare and adjust activity to just those processes.

You can use the history reporting capabilities of transaction SOLAR_EVAL to run the Structure History report to validate your log as to what changes you made relative to the BPH structure. Reporting on the other tabs can flush out the details of other changes absorbed in your compare and adjust activities. Use the Document History reports to help identify changes to document versions that have occurred since you created the project or since the last compare and adjust activity. A little diligence here goes a long way toward keeping Solution Manager as a reliable single source of truth for your organization’s business solution.

Run transaction SA_PROJECT_UPGRADE for the global template project with the comparison to the downstream implementation projects (Figure 5).

Figure 5

Compare the global template to changes in the downstream project

You can generate the changes made to the implementation project using Solution Manager’s history reporting capabilities via transaction SOLAR_EVAL. Remember to run both the tabs and the documentation history report. The tabs report gives the list of changes to the BPH structure by selecting the Structure tab check box.

Use caution when running the Documents report. There tends to be a large number of changes to documents, so the report can get very large very easily. Try limiting the document types or the date range.

A nice effect of following this process in this sequence is that by the time you get to the last compare (global template), all your implementation projects are made current relative the solution.

The compare on the global template shows all the process nodes on the BPH that have an opportunity for enhancement based on the changes made to the solution. (Be aware that there are also alerts for changes to the downstream implementation projects that were not a result of the solution import [e.g., project activity].)

Keep in mind that you’ll need to run transaction SA_PROJECT_UPGRADE for each of the implementation projects you modified based on your analysis of the solution. 

The usual rules and procedures of compare and adjust apply much as they did in Solution Manager 7.0. Reconciliation of content, especially process documentation, still requires a careful review and editing to incorporate these changes into the global template.

While this process may seem tedious, the payoff of having all your implementations kept current relative to changes in the solution as well as having clear visibility to all process changes that could affect the global template is worth the effort. Keep in mind the note I mentioned earlier about the project not being active. This applies to implementations that are still open. If your organization closes or locks implementations after go-live, you need to consider leaving the reconciliation of the implementation out of the scope of your processes.

Take Advantage of a Process Enhancements Coming from Ongoing Projects

Let’s look at an example: You have multiple projects in the works at various stages of completion. You’ve identified through process design sessions that there are one or more processes being enhanced as part of localization efforts that are a good fit for the enterprise as a whole and you’d like to make them part of the global template.

You can do this by using transaction SA_PROJECT_UPGRADE to identify changed processes and incorporate them as appropriate. The procedure for this is very much the same as the procedure described above with a few minor differences.

1. It is assumed that this activity would be done separately from incorporating changes from the solution, so transaction SA_PROJECT_UPGRADE identified changes found in downstream implementation projects that are open for consideration.
2. There really shouldn’t be any surprise process changes associated with this as the team that owns the global template should already have a pretty good idea of what processes are potential candidates for the global template as a result of the design sessions.

As of this writing, transaction SA_PROJECT_UPGRADE does not allow analyzing multiple downstream implementation projects against the global template. Therefore, you must repeat the analysis for each of the downstream implementation projects that are open for your enterprise.

Once you’ve cycled through all the implementations and absorbed all the appropriate changes into the global template from those implementations, you may wish to see what affects the changes to the template may have had on the downstream implementations. Figure 6 shows how this all comes together.

Figure 6

Change from the solution rolled to the implementation then up to the global template

These are just a couple of the circumstances in which changes could originate and ways you can handle them. However, I believe we’ve covered enough of the concepts to allow you to tailor their use for your unique circumstances.

As you can imagine, there are any number of variations to this life cycle and careful planning for when and how to incorporate changes is critical. Factors such as implementation go-lives, regression implications, business readiness, and others need to be taken into account when planning the migration of changes across projects.

D. Russell Sloan

D. Russell Sloan is a specialist in project and program governance for IBM. He focuses on the use of SAP Solution Manager for global rollout projects for IBM’s largest customers, having worked with SAP software since 1996. Russell has degrees in accounting and information systems and has been a team and project leader for SAP projects for more than 14 years. He has been developing and deploying software systems for over 30 years.

You may contact the author at solmanruss@gmail.com.

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