After you’ve gone live for the first time with an SAP solution, the work is far from over. Many organizations choose to reduce risk by rolling out incrementally. An extended rollout program presents many challenges, not the least of which is how to manage ongoing support and maintenance at the same time as your deployment activities. Even if you are not rolling out to a large multinational organization, managing just one project that will go live after your urgent corrections warrants a well-thought-out, systematic approach.

I’ll explain how SAP Solution Manager can help organize these complexities by addressing the following common questions:

• What can you use to track which parts of your solution have been implemented and where?
• What if I need to apply corrections to objects in production that are also in scope for a deployment project?
• How do you handle a situation in which two development and testing environments are delivering changes to a common production environment?
• Should I use the solution directory or a template project?
• How does the maintenance project fit in?

Keep an Indexed Repository of Documentation and Content

To keep complexity from degrading into chaos, it’s a basic requirement to have a system that structures and indexes your data. This sounds obvious in principle, but it can be difficult to implement in practice when it comes to SAP solutions. People rarely enjoy completing and updating solution documentation. Faced with time pressure and mounting workloads, fixing an issue in production is always going to take priority over updating the documents related to the last fix once it is working. That’s why it is important to be able to keep track of what has changed and match that to the related documentation.

There are multiple tools in SAP Solution Manager that you can use to detect, sort, and track changes in your solution. In effect, SAP Solution Manager serves as a configuration management database for the technical description of your solution. If you have multiple organizational entities sharing the same SAP platform but not necessarily an identical scope, you need to keep track of which components have been deployed where.

Here is a fictional scenario in which this type of tracking would be needed. Say that a company called Conglomerati SA, an apparel and footwear company headquartered in Milan, is in the midst of a global rollout program to all its divisions. Having grown through acquisitions, it has a mixture of companies. The Fabricoli division performs manufacturing and retail, Brandiola performs design and marketing, and Venti Venti performs wholesale distribution and retail. In addition, it also has a holding company (Mamma Mia) and a small confections business (Cioccopazzo). These divisions have operations across Europe, the Middle East and Africa (EMEA) and the Americas. So far, the solution has been rolled out to Mamma Mia and several company codes for Fabricoli in EMEA. A pilot (i.e., the first site to go live) has been completed in the US for the remaining divisions.

The board of Conglomerati approved a five-year global SAP rollout program. Its objective is to align business processes where it makes sense but also allow differentiation and localization according to each division’s business model. As a result, each division will have a different set of processes running on the SAP system with a certain amount of overlap depending on the nature of each division. Manufacturing processes are in scope for Fabricoli, retail processes are in scope for Fabricoli and Venti Venti, and variations of these processes will be deployed at Cioccopazzo.  

To make things more interesting (and realistic), several teams are responsible for deployments by region and a central support team in Italy coordinates with regional support teams. A virtual team called the template owners is made up of solution experts in each functional area taken from different teams depending on needs, availability, and aptitude. This team is responsible for the integrity of the global solution and its application worldwide.

In this kind of scenario, you need a chart or a Microsoft Excel sheet to get a handle on the high-level description of the program (Figure 1). When you consider how many change requests, documents, and test cases are involved in the program, you can see how it can start to get messy. A new feature in SAP Solution Manager called customer attributes can help you achieve this.

Figure 1

Sample company Conglomerati SA's deployment scope

Use Custom Attributes to Identify Potential Conflicts

To see how customer attributes can help, let’s take an example of a change request coming from a UK user in production. The user would like to reformat a custom export documentation program that Fabricoli uses. Before support team members located in Belgium can approve the change, they need to do an impact assessment. One of the first questions to answer is, “Who else is using this program?” How the support team obtains this information depends on the approach used to track the solution contents. There are several ways to do this:

1)     Keep people on board that remember all the deployment projects and maintenance changes

2)     Keep a deployment and change log in each specification document

3)     Define a custom attribute to track deployment scope of each process and solution component

The problem with the first option is that project team members don’t usually enjoy doing support and maintenance. As time goes on, fewer and fewer people will be around that can recall the history of the successive deployments. With the second option, you could open the document to see the list of entities that the particular function had been rolled out to. However, what if you need to produce a list of all solution components deployed for a specific entity? This isn’t possible with the second option unless you write a report that searches through the text of all the documents.

The third option is possible as of SAP Solution Manager 7.0 with Support Package 21. You can now define your own custom attributes on many types of objects in SAP Solution Manager. In my example, you could define two independent attributes: division and country. When the customs export documentation report went into production, this report would have been logged against the related sales business process on either the Transactions tab or on the Development tab in transaction SOLAR02. The custom attribute for this report (division) would be assigned the value of Fabricoli and the country attribute would have the value UK. When the support team looked up the report in SAP Solution Manager, it could check the custom attributes and, if other countries were listed, would immediately know whether to involve anyone else in the change request.

Prior to Support Package 21, you could have done something similar with the use of keywords. The advantage to using customer attributes is that you can define as many as you want and clearly distinguish between each one. With keywords, there is only one dimension to work with. Customer attributes allow you much more flexibility in filtering and reporting. For a global rollout, some suggested customer attributes are entity, country, or division.

Technical Background

You need to activate customer attributes in SAP Solution Manager via the IMG to use them.

Step 1. First, go to the SAP Solution Manager IMG via transaction SPRO and follow menu path Scenario-Specific Settings > Implementation/Upgrade > Blueprint and Configuration > Object Attributes > Definition of Customer Attributes for Object Types.

Step 2. In the next screen, define new customer attributes (Figure 2). Place the cursor on an empty line and click the New Entries button.

Figure 2

Add a new attribute

Step 3. In the next screen, enter an attribute name and description and save your work (Figure 3).

Figure 3

Add a name and description

Step 4. After you create the attribute, you need to set up some additional parameters. Select an attribute on the right side of the screen (Figure 4).

Step 5. Click the Attribute properties folder on the left side of the screen.

Figure 4

Maintain attribute properties

Step 6. If you want to restrict the possible selection values for a customer attribute, you must assign a table and field to the attribute (Figure 5). This can be a standard table that already contains a set of values (such as the Country field) or a custom table and field that you define in the ABAP Workbench. Enter a Table Name and the Field Name that will contain the entries for the customer attribute. For the Multiple Values field, select 2 Single-value Attribute if only one value can be saved at a time to any particular object using this attribute. Use the Multiple Values Attribute option in this field if more than one value can be saved to the object. For example, the attribute Ticket is maintained this way because a particular process may be modified by several tickets over the course of its lifetime. Select 1 Attribute is visible under the Visibility field.

Figure 5

Assign table and field values

Step 7. If you have assigned a custom table to the attribute, you also need to set up the possible values for the custom tables that are created. Go to transaction SM30 (Figure 6). Enter the custom table name (e.g., YSOLMAN_SCOPE) and click the Maintain button.

Figure 6

Maintain the values for the custom table

Step 8. Click the New Entries button, enter the relevant additional values, and save your work (Figure 7).

Figure 7

Maintain attribute values

Step 9. Next, configure the objects for which customer attributes will be used. Go back to the IMG and follow menu path Scenario-Specific Settings > Implementation/Upgrade > Blueprint and Configuration > Object Attributes > Assign Customer Attributes to Objects.

Step 10. In the screen that appears, click the New Entries button (Figure 8).

Figure 8

Assign attributes to SAP Solution Manager object types

Step 11. On the New Entries screen, select an object type from the list of available entries (Figure 9). For this example of a custom report, you should assign the customer attributes to workbench objects. This corresponds with the Development tab in transaction SOLAR02. Next, click the Assign Attributes folder on the left side of the screen.

Figure 9

Select BMWB Workbench-Object from the list

Step 12. Click the New Entries button again and select the custom attribute you created. Enter the appropriate entries for the remaining fields as shown in Figure 10. The 1 Check Value entry works only if you assigned a table to the customer attribute when you defined it (i.e., the table that contains the values against which user entries are verified).

Figure 10

Add an entry for the workbench object

Run the Compare and Adjust Program to Identify Documentation Updates

While customer attributes help you keep track of the deployment scope of each solution component, they do not address the challenge of managing concurrent updates to the same document or solution component. Once you go live with your pilot, you will likely deploy the same functionality to other sites while supporting the new users in production for the sites that are already live. Particularly during the early stages of the rollout, you will make many corrections to the solution in production. This presents a challenge to the deployment team because it is working with a moving target.

You may be familiar with a program in SAP Solution Manager that helps with this situation called compare and adjust. You can access it using transaction SA_PROJECT_UPGRADE. It allows you to compare template and implementation projects. If you create your deployment SAP Solution Manager project as an implementation project and copy the content over from a template project, this program identifies what has changed in the template project since the initial copy.

If you keep the template project up to date with all your production fixes and changes, you can also apply these updates to your deployment project using compare and adjust. You still have to decide what to do if the changes applied in production conflict with the design for the deployment site; there is no magic solution for merging two versions of the same document or object together. An SAP application expert still needs to do that. However, hopefully you will be able to identify potential conflicts early using customer attributes.

Another decision that you need to make is when to check for and apply production support changes to your deployment project. Typically, you should do this just prior to reaching strategic milestones in the deployment project — namely, before signing off on the solution design at the end of the Blueprint phase, before each testing campaign, and before going live with project changes. 

The Solution Directory and Maintenance Project

Several years ago, SAP introduced the solution directory and the maintenance project as the intended destination of solution documentation once a project went live. If you follow the recommended process — building your business process structure and attaching blueprint documentation in transaction SOLAR01, then completing your solution with a record of configuration and development in transaction SOLAR02 — the next step after go-live would be to move this content to the solution directory. You can easily copy business scenarios and the content attached from your implementation project to the solution. From there, you can check out components to the maintenance project for modification, review, and release to production.

There are several advantages to using these two project types, and you need to consider your own specific needs when you decide whether to use the solution directory or to stick with template and implementation projects. Specifically, you can benefit from integration with Change Request Management (ChaRM) and the check-out and check-in process is more advanced with the maintenance project than with compare and adjust. For example, you can configure workflow that requires approval before something can be checked out of the solution directory.

However, the solution directory and maintenance project scenario present some drawbacks as well. You can only define one maintenance project per solution, which does not allow a solution component to be checked out to more than one maintenance project at a time. This means ongoing project or deployment work cannot occur at the same time as production support. Updates to project documentation with changes that were made in the maintenance project have to be managed manually, and there is no automatic function to identify and resolve conflicts. This situation is particularly important if you have more than one development environment in which you could potentially make changes to the same configuration.

Some tools are available to help identify these potential conflicts at the technical level (e.g., ChaRM and Rev-Trac), but these do not deal with related documentation and only alert you to potential conflicts when you open a transport order for an object. Ideally, you should know that a solution component is undergoing maintenance before you get to the detailed design for the same object in the parallel environment.

In the end, if you have ongoing projects or deployments, I recommend using a template project to store your production documentation and updating this with modifications made as part of ongoing support and maintenance. You can use customer attributes to identify potential conflicts before change requests are approved. Then, you can use the compare and adjust program to deliver maintenance updates to your deployment SAP Solution Manager project.

Marcel van den Top

Marcel van den Top has 14 years of experience in analysis, design, and implementation of business information systems. Marcel has gained his knowledge about SAP Solution Manager through SAP projects in different industries — as an SAP ERP Financials consultant, integration manager, project manager, and advisor. He is a regular speaker at the SAP Solution Manager seminar, advising companies on how to improve their implementation, rollout, and upgrade projects, as well as their support processes.

You may contact the author at mvandentop@yahoo.com.

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