You’re in a large and dynamic organization. You’ve been charged with owning the solution and making sure that your company has a consistent approach to process design, delivery, support, and continuous improvement. Further, your company has started off on a five-year plan to acquire 15 new companies across the globe with the intention of making them all work as one with standardized processes and industry-leading agility in response to rapid market change.

Congratulations — you’ve been asked to provide an environment that can change but also remain the same. These goals seem to be contradictory in terms of creating an environment in which they can coexist. However, SAP Solution Manager can provide you with a platform for delivering such an environment by using template projects, implementation projects, and solutions. Let’s look at each of these in more detail.

The Template Project

While complete descriptions of all the features of the template project are beyond the scope of this article, it’s important to understand a few key features:

1. The template project is not intended to go to production (more about that later)
2. The template project is the source of truth for standard business processes. These are the processes the enterprise deems mission critical enough to make every effort to keep them consistent across all aspects and geographies of the organization.
3. You can manage versions of business processes as scenarios by assigning scenario templates (more about this later)
4. Documentation on the General Documentation tab of a template project is made available to implementation projects as read-only reference documents
5. In the ideal world, you have business process owners that champion or own the template to ensure process consistency, identify when local rollouts are making changes that affect the template, and manage any changes to the global template.

The Implementation Project

Now let’s look at a few important features of implementation projects:

1. The implementation project needs to be viewed as a subordinate project to the template project. The processes in the implementation project begin by inheriting the processes from the global template.
2. The implementation project should only make changes to the template processes that are absolutely necessary for the target business area that receives the processes. For example, only legal and regulatory changes are allowed. The more closely the enterprise holds to the standardized process of the template, the more quickly the enterprise can affect organization-wide change.
3. The implementation must be reconciled to the template before going to production.
4. The group that owns the template must be aware of all process and technology changes being made in the implementation.

The Solution

Now let’s look at the features of a solution:

1. The solution represents the productive environment. It is an SAP Solution Manager entity that is used to house all the processes that have been delivered during all the go-live events that have occurred in the company. 
2. The solution is the sum of all processes and process changes that have been developed and delivered as a result of global design, implementation deployments or local rollouts, and changes made relative to production support. (Production support changes are beyond the scope of this article.)

In reading the lists above, you might have questions about the concepts described. So, let’s take a closer look so that you have the right understanding before going further.

I mentioned the concept of going to production. This is where you begin to better understand the solution. The way I like to describe this is by using a factory analogy.        

Imagine a factory building that has multiple production lines and an internal warehouse that stores finished goods. The factory makes two kinds of candy bars that are, for the most part, the same. The base ingredients list for the two candy bars is chocolate, coconut, and caramel. The difference is that one of the candy bars also has almonds, and the two candy bars have different wrappers. As the two production lines in the factory produce candy bars, they put the finished product into the warehouse.

What does this all have to do with SAP Solution Manager? In the example above, the common ingredients represents the global template. It is the part of the final processing output that is the same regardless of which candy bar is being made.

The production lines can be viewed as the implementation projects. They represent how the global template is modified slightly to meet local requirements. In practice, this could represent legal and regulatory variations required to perform the business processes in different countries.

The warehouse represents the solution. It holds the finished product. The difference between the warehouse described above and the solution is that the solution doesn’t house finished products, but rather finished processes. It holds the sum of all the variations of the processes needed by the production lines based on the global template.

In summary, the global template holds a common list of ingredients and processes to make the base candy bar. However, the base candy bar is not actually sold by the business, so these processes don’t go directly into the solution. The implementation projects start with the process from the template and modify it slightly to create unique processes for each different candy bar. These processes are how the individual production lines operate. It is these modified processes that go into the solution.

Let’s Get Real

Now that you know the basics, let’s complicate things to make them look more like real life.

Your enterprise has just gone through a thorough, comprehensive global blueprint. Now the organization has the core business processes identified and described in a way that allows process standardization across the enterprise. You need to build and deploy this across the many business units and geographies that make up the company as a whole.

It is generally unrealistic to build a solution and deploy it to the whole world all at once. So, you might plan to deliver the solution a piece at a time. This way, you can absorb the subtle process variations each of the business units or regions requires.

In SAP Solution Manager, the global blueprint is housed in a template project. For the purpose of this discussion, I’ll take on a small scope. This global blueprint template houses a single scenario, OTC- Scheduled Contract Sales (order to cash for contract sales). You can create this by using transaction SOLAR01 and entering the scenario manually (Figure 1). Then bring in processes and steps via a combination of content subsets from BPR and manual additions. Note that I have labeled different nodes on the left either as Scenario, Step, or Process. This is not common in systems; it is merely for illustrative purposes.

Figure 1

Example template structure with a single scenario

Let’s assume that the global template team has already developed these processes in the SAP development environment and has tested them in the quality assurance system to the point that if you were going to deploy them as is, they would be approved for production.

Now it is time to begin the delta blueprint to understand how a particular business unit needs to localize the processes in the global template. To do this, you need to build an implementation project to house the localizations.

The main concept of building an implementation is to inherit the processes from the template. Let’s take a brief moment to talk about how this is done using the scenario template.

Assign a Scenario Template to Scenarios in the Template Project

This approach provides a way to version the scenarios in the template project.

First you must create the names for the scenario templates to be assigned to your scenarios. Use transaction SOLAR_PROJECT_ADMIN. Choose your template project and go to the Templates tab. Enter the names of the scenario templates you want to use on the template project (Figure 2).

Figure 2

Scenario template ZST_OTC_CONTRACT created for the project in transaction SOLAR_PROJECT_ADMIN

You can see that the Visibility is red and set to Private. This means that at this time, any scenario in the template project assigned to this scenario template is not available to the implementation projects. This enables you to prevent an implementation project from importing a scenario that is still considered as work in process (WIP) by the global template team.

In Figure 3, you can see that the ZST_OTC_CONTRACT scenario template has been assigned to the scenario in transaction SOLAR01. This places this scenario under the control of the scenario template created in transaction SOLAR_PROJECT_ADMIN as described above.

Figure 3

Scenario template ZST_OTC_CONTRACT assigned to the OTC-Schedule Contract Sales scenario

You might have noticed the Global Attribute is populated. This attribute controls how much the implementation project can make changes when using this scenario from the template. A table from SAP Help describes the implications of using this attribute. The full details of this attribute are beyond the scope of this article.

The Global Attribute protection may be bypassed by a user that has the value GLOB for field FUNCTION of authority object S_PROJ_GEN.

When the global template design team has determined that the scenario is ready for use by implementation projects, one of its members versions the scenario and makes it visible to the implementation projects using transaction SOLAR_PROJECT_ADMIN and following this process. Choose the template project and go to the Templates tab. Select the scenario template you want to make available to the implementation projects and click the change visibility icon  at the bottom of the Template tab (Figure 4).

Figure 4

Visibility of the scenario template has been set to Public

When a scenario template is set to Public, it is available for selection in the Scope tab of the implementation project in transaction SOLAR_PROJECT_ADMIN. Let’s take a look at how this works for an implementation project.

In Figure 5, you see an implementation project in transaction SOLAR_PROJECT_ADMIN with the Scope tab selected. Note that the scenario template ZST_OTC_CONTRACT appears at the bottom of the list. (The other scenario templates listed have been delivered by SAP. The discussion of their content is beyond the scope of this article.)

Figure 5

Scenario template ZST_OTC_CONTRACT is available for selection

In Figure 6 you can see the implementation project in transaction SOLAR01 before you select the scenario template. In Figure 7 you see it after selecting the scenario template.

Figure 6

View of the implementation project before selecting the scenario template

Figure 7

View of the implementation project after selecting the scenario template

At first glance, you may think that Figure 7 is the same as Figure 1. Note that there are two key differences. First, there are different project names. Second, Figure 7 has a series of check boxes along the Business Process Hierarchy (BPH).

These check boxes allow the implementation team to mark out-of-scope processes or steps that may not be used by the target business unit for the implementation. (This is governed by the global attribute mentioned above.)

The ability to mark items out of scope provides the following key advantages:

• The ability to deploy a subset of an approved template scenario
• Preserving visibility to the scope of the scenario as intended by the global template
• The ability to plan for a phased rollout of a scenario to a particular business unit

Now the implementation team has the starting blueprint for the rollout. It can then move forward with identifying, designing, building, and testing the localizations required for the business unit.

During the implementation project, the global template may have changed for various reasons. As part of both ongoing governance and as part of go-live preparation for the implementation, the compare and adjust feature should be used to identify changes that have occurred during the implementation. Use transaction SA_PROJECT_UPGRADE and enter the implementation project (Figure 8). Enter the transaction. A background job is generated that compares the implementation to its source (in this case, the template project). See this SAP Help page for transaction SA_PROJECT_UPGRADE for more details about how the comparison can be used for comparing to the BPR, comparing solutions, and so on.

Figure 8

Enter the implementation project in transaction SA_PROJECT_UPGRADE

After the background job is complete, use transaction SOLAR01 for the implementation project. Follow menu path Utilities > Settings and make sure the Comparison Mode Active check box is selected (Figure 9).

Figure 9

Activate comparison mode

When you expand the BPH tree, you’ll see a comparison found changes icon  wherever there has been a change to the template project relative to the implementation and vice versa (Figure 10).

Figure 10

Implementation project after the compare function SA_PROJECT_UPGRADE

Now that the compare part is complete, it is time for the adjust part. Select the BPH structure with the comparison found changes icon and SAP Solution Manager highlights the tab in which the changes exist with the same icon (Figure 11).

Figure 11

Structure tab identified as the tab with changes

At this point, click the compare and adjust icon  to see the changes. This produces the Compare and Adjust pop-up screen in Figure 12.

Figure 12

The Compare and Adjust pop-up for selecting or accepting changes highlighted by the comparison feature

If you take a close look at the pop-up screen, you see on the left that the Release Orders step was added to the template after the implementation was created. On the right, you can see Unlock Blocked Orders was added to the implementation since it was created. 

This could be the same business process step, so it’s important that the implementation team confer with the global template team before accepting the change into the implementation. To reconcile the implementation with the global template, select the process step on the left (e.g., Release Orders) and click the adjust selected entries icon .

This brings the new step from the template project into the implementation project. By clicking the green check mark icon, you accept the change into the structure. The structure now looks like the screen in Figure 13. Note that the Source column on the Structure tab shows that all the steps except Unlock Blocked Orders came from the template.

Figure 13

New structure element accepted from the template

In similar fashion, the global template team can choose to bring process changes from the implementation into the global template project. This occurs if the change made by the implementation team is deemed to be relevant for enterprise-wide use.

This is but one of the types of changes that the compare and adjust feature can identify. Others include changes to structure names, adding or deleting transaction codes, configuration objects, documents, custom development, end user roles, and test cases.

Even though this has been a lengthy discussion, I’ve only begun to scratch the surface of the capabilities of SAP Solution Manager for global rollouts. Hopefully by covering the basics, some of the mystery is gone and you can experiment and discover the best features for your project.

Experimentation

I recommend that you set up a template project, two or more implementation projects, and a solution. Then create a scenario in the template, assign a scenario template name to it, and then select it into one or more implementation projects. Make sure when you set up the scenario in the template you make it robust. Add transactions to the Transactions tab, add documents on the General, Project, Development, Configuration and other tabs, add configuration objects to the Configuration Tab, and even add a custom program or two to the Development Tab.

Here are some suggestions for experimenting with changes to an implementation:

1. Add a new process or step to the implementation
2. Add and remove documents, transactions, and configuration elements
3. Version the scenario template so that its visibility is public
4. Run the compare and adjust

Did the structure elements that you expected have the comparison found changes icon?

Now experiment with changes to the template:

1. Add and remove process steps
2. Add and remove some documents
3. Change some documents
4. Run the compare and adjust

What was identified this time? How does the pop-up screen look different in the adjust feature?

Take the processes from the implementation to the solution. Then make some changes to the processes in the solution. Run the compare and adjust feature on the solution. How does it differ from running the comparison on a project?

By understanding how the template and implementation relate via the scenario templates, you begin to see how SAP Solution Manager can help you manage concurrent implementations based on a common enterprise design. 

Compare and adjust can help you monitor and manage the changes that are occurring across multiple projects within your enterprise. Hopefully you’ll be able to avoid those surprises when the team in the US rolls out a change that unknowingly affects the team in Germany. Also, by being able to analyze the changes being done by implementation teams, you can discover those really great process enhancements that could be advantageous for the entire organization.

Again, I urge to you to set aside some quality time to experiment with the many different ways the compare and adjust functionality can be used with template and implementation projects. Also, if you’re on SAP Solution Manager 7.1, expand your experimentation to include comparing solutions to your implementation projects so you can develop processes for identifying those changes that have occurred due to production support and non-project-related system enhancements.

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.