Standards and procedures are defined at a company’s discretion to help maintain consistency during projects. When a company’s standards and procedures are in place, all projects must follow the same standards. Various users and project team members need to complete certain steps in SAP Solution Manager when starting a new project. This is not always an easy task because project managers may vary in methodology, which is why you need to take company-wide standards into consideration.

After completing company standards and procedures, make sure to validate that what had been documented is defined well enough for everyone to understand. This document should provide the necessary setup steps for anyone to start and finish a project. Each company should have a group in place to review documentation for meeting project requirements and verify that the documentation is up to date. This ensures that the company’s time spent defining these standards and procedures is valuable for all projects. You will be required to spend some time initially to complete standards and procedures, but they help speed up projects when a clear direction is defined from start to end.

I will review some of the key project standards and procedures to consider for SAP Solution Manager projects. I break standards and procedures into different sections to give you a better understanding of how they both play an important part.

Standards

You can start with the Project Methodology standard. ASAP Methodology is an SAP standard methodology used by most SAP customers (Figure 1). SAP Solution Manager provides Roadmaps for reviewing methodology and to act as a guide through each project phase. Execute transaction RMMAIN (Roadmap) in SAP Solution Manager to access Roadmap content. Roadmaps provide well-documented help broken into project phases. Accelerators are also available and are helpful when looking for document type templates to use on projects. You can refer to my article “Speed Up SAP Projects with Roadmap Accelerators” for more information on Roadmap accelerators.

Figure 1

SAP Solution Manager Roadmap

The key to the project methodology standard is to define what parts of the methodology (and how much of these parts) will be used. It is important to clearly define the use before the project kicks off. Otherwise, the project will be live but the project management or the project team will not know what parts they should be using. This is one of the most important parts of a good standards and procedures document. It is also one of the most straightforward because Roadmaps are available as part of standard SAP Solution Manager content for review and ASAP Methodology is also available at the SAP Service Marketplace.

Next you should consider the project phase standard. This standard can help you throughout the project. Each project phase should clearly describe in detail what actions that involve SAP Solution Manager should take place. This standard gives you the chance to provide information on how different transactions (e.g., transactions SOLAR01 and SOLAR02) will be used in certain project phases and also how each tab in the project will be used. It’s a critical success standard to define how the project phases (Figure 2) should be set up and used so that when initial project teams start to use SAP Solution Manager, they can clearly navigate and understand the setup. This section is important for anyone who has not worked with SAP Solution Manager before because it can seem foreign in look and feel. Again, you can reference the Roadmaps if you have any confusion about which deliverables are for each project phase.

Figure 2

Transaction SOLAR01, the Business Blueprint

You should also consider a project naming convention standard (Table 1). Not only is a naming convention important for projects, it is also important for the Basis group when it names system landscape components and project documentation. A standard naming convention helps when someone is searching for system landscape items, SAP Solution Manager projects, and existing documentation. Keep in mind that the naming convention will be used on all projects going forward. Also, make sure others have reviewed the naming convention before documenting it as a standard and starting project.

Table 1

A sample naming convention for a system landscape

Next, a project standard is something you can do before a project starts — you identify what document types, status, and keywords will be used on the project. These should be listed in a document matrix (Table 2). This helps eliminate confusion around document types that are not in use. The status and keywords are particularly important because project management can use them to track the progress of each project phase. Keywords are not used by every organization because they have to be manually created for projects, but they can be useful during reporting.

Table 2

Document matrix example

Combination Standard and Procedure

Project roles fall under both areas: standards and procedures. Project roles help define project tasks and standardize SAP Solution Manager security roles (Table 3). Project roles also help when you are standardizing security roles for specific project roles. You can use the SAP Security Guide from SAP Service Marketplace to get started with standard roles. Your standards and procedures document should list the security roles that are assigned to SAP Solution Manager users depending on their project role. The keys to this procedure are defining the roles, determining the process for assigning roles to individuals, and making changes to roles (if needed).  

Table 3

SAP Security Guide with SAP Solution Manager composite roles

Procedures

Companies should always review each procedure covered in SAP Solution Manager even if the functionality is not used at the time (i.e., Business Process Monitoring). At least leave a brief description of what the functionality does and revisit this document with updates if anything changes. The section can also note that the functionality is not used at the current time. You should provide a date with the note. This allows project teams to evaluate and perhaps make a case for using more SAP Solution Manager functionality in the future. Here are two common examples of procedures that require much thought but can add instant value.

If you need to replace a legacy ticketing system, you might benefit from the Service Desk procedure. A well-thought-out process is required when you define Service Desk procedures, such as creating tickets (as shown in Figure 3), evaluating and troubleshooting tickets, and closing tickets. You should add process flow illustrations (if possible) to help define this section of procedures. You can ask your group questions such as: Who will be part of the support teams? How will we escalate issues? 

Figure 3

Support message in the Service Desk

Before you implement Change Request Management (ChaRM), you need a clear procedure in place to document all steps and approval processes. You likely have multiple procedures for processing normal corrections and urgent corrections because of the differences involved in processing each change request (Figure 4). Normal corrections differ in procedure from urgent corrections because normal corrections are managed in a maintenance cycle while urgent corrections are managed with a task list and do not interfere with the maintenance cycle. Like Service Desk, ChaRM has workflow involved and should have clearly defined procedures.

Figure 4

ChaRM normal correction

Finally, you need a sustainment procedure for when a project is completed. Here are some common questions you might find yourself asking: The project is complete, so now what do we do? Should we leave the project open so anyone can access the documentation? You should determine answers to these questions and define steps on how sustainment teams will maintain completed project documentation. In some cases, companies leave many projects open or do not hide them after completion. They are actually working out of multiple projects to gain access to all documentation from previous projects. Other organizations may choose to use the Solution Directory for all completed project documentation (Figure 5).

Figure 5

An example of a Solution Directory

Some organizations fail to consider sustainment. This means that teams can end up working out of multiple projects. When this is the case, project teams waste time looking in multiple projects for documentation. This is a problem because if the team has not worked on a previous project that has the documentation the team needs to use, it is often confusing to search through all the different projects. Ideally, your organization should keep re-usable documentation from past projects in a central location to avoid this kind of confusion.