You are on page 1of 53

Matthias Friedrich, Torsten Sternberg

Change Request Management with SAP Solution Manager

Bonn Boston

Contents
Preface ....................................................................................................... 11

Introduction ..............................................................................
1.1 IT Change Management and the Information Technology Infrastructure Library ................................................................... 1.1.1 Classification of IT Change Management ........................... 1.1.2 Definition of Concepts ...................................................... 1.1.3 Tasks of IT Change Management ....................................... 1.1.4 Success Factors for IT Change Management ...................... SAP Solution Manager and the Information Technology Infrastructure Library ................................................................... 1.2.1 SAP Solution Manager Functions ...................................... 1.2.2 Support of ITIL Practices Using SAP Solution Manager ...... Change Request Management with SAP Solution Manager ......... 1.3.1 Change (Request) Workflows ............................................ 1.3.2 Project Administration ...................................................... 1.3.3 Monitoring and Reporting ................................................ Summary ....................................................................................

15
15 15 18 19 20 20 21 24 28 29 30 31 31

1.2

1.3

1.4

Architecture of Change Request Management ........................


2.1 2.2 Elements of Change Request Management ................................. Project Administration in SAP Solution Manager ......................... 2.2.1 Solution Manager Project Types ........................................ 2.2.2 SAP Solution Manager Projects in Change Request Management .................................................................... 2.2.3 IMG Projects and CTS Projects .......................................... 2.2.4 Project Cycle and Task List ................................................ 2.2.5 cProjects .......................................................................... Transaction Types/Workflows ...................................................... 2.3.1 Service Desk Message ....................................................... 2.3.2 Change Request ............................................................... 2.3.3 Change Document ............................................................

33
33 35 35 39 41 45 50 51 53 54 58

2.3

C ontents Contents

2.4

2.3.4 Normal Correction/Development Activity ......................... 2.3.5 Urgent Correction ............................................................. 2.3.6 Administration Message ................................................... 2.3.7 Test Message .................................................................... 2.3.8 Job Request ...................................................................... 2.3.9 Change Transactions for Projects ....................................... Summary ....................................................................................

59 64 65 66 67 67 68

Configuration of Change Request Management ......................


3.1 Preparation ................................................................................. 3.1.1 Organizational Questions ................................................. 3.1.2 Technical Questions .......................................................... 3.1.3 Prerequisites ..................................................................... 3.1.4 Available Documentation and Resources .......................... Configuration of Change Request Management .......................... 3.2.1 Standard Configuration ..................................................... 3.2.2 Extended Configuration .................................................... Defining Projects and Systems in Change Request Management .............................................................................. 3.3.1 Defining Logical Components ........................................... 3.3.2 Creating a Solution Manager Project ................................. 3.3.3 Final Check ....................................................................... Summary ....................................................................................

69
69 69 70 70 71 72 73 85 102 102 107 108 109

3.2

3.3

3.4

Use of Change Request Management ...................................... 111


4.1 Roles and Activities ..................................................................... 4.1.1 Requester ......................................................................... 4.1.2 Service Desk Employee ..................................................... 4.1.3 Change Manager .............................................................. 4.1.4 Change Advisory Board ..................................................... 4.1.5 Developer ........................................................................ 4.1.6 Tester ............................................................................... 4.1.7 IT Operator ...................................................................... 4.1.8 Additional User Information ............................................. 111 112 113 113 114 114 115 115 116

Contents

4.2

4.3

4.4

4.5

4.6

Processes and Integration Examples ............................................ 4.2.1 Example of the Urgent Correction ..................................... 4.2.2 Retrofit Process ................................................................ 4.2.3 Hot News ......................................................................... 4.2.4 Structure Elements for Change Transactions ...................... Administration ............................................................................ 4.3.1 Task List ........................................................................... 4.3.2 Extended Configuration .................................................... 4.3.3 Change Tracking ............................................................... 4.3.4 Scheduling ........................................................................ 4.3.5 Project Logistics ............................................................... Reporting and Monitoring .......................................................... 4.4.1 Solution Manager Reporting ............................................. 4.4.2 Transaction Monitor ......................................................... Work Centers .............................................................................. 4.5.1 Change Management Work Center ................................... 4.5.2 Configuration of Work Centers ......................................... 4.5.3 SAP GUI for HTML Configuration ..................................... Summary ....................................................................................

116 117 134 140 142 148 148 162 163 166 167 169 169 171 175 175 179 180 181

Security in Change Request Management ............................... 183


5.1 Authorizations in the SAP System ............................................... 5.1.1 Authorizations in the SAP Solution Manager System ......... 5.1.2 Authorizations in Satellite Systems ................................... 5.1.3 Work Center ..................................................................... 5.1.4 Extended Authorization Checks ........................................ Cross-System Object Lock ........................................................... 5.2.1 Functionality .................................................................... 5.2.2 Required Settings ............................................................. Critical Transport Objects ............................................................ 5.3.1 Functionality .................................................................... 5.3.2 Required Settings ............................................................. 5.3.3 Modifications ................................................................... Project Intersections ................................................................... 5.4.1 Real-Life Example ............................................................. 5.4.2 Required Settings ............................................................. Summary .................................................................................... 183 183 184 185 185 186 186 189 191 191 193 194 195 196 197 198

5.2

5.3

5.4

5.5

C ontents Contents

Extensions of the Change Request Management Scenario ..... 199


6.1 Extended Transport Landscapes .................................................. 6.1.1 Three-System Landscape ................................................... 6.1.2 Four-System Landscape .................................................... 6.1.3 Parallel Phase Landscape .................................................. 6.1.4 Landscapes for Global Developments ............................... 6.1.5 Conclusion ....................................................................... Enhanced Transport Management ............................................... 6.2.1 Components ..................................................................... 6.2.2 TMS Configuration ........................................................... 6.2.3 Integration with Applications ........................................... 6.2.4 Landscape Scenarios ......................................................... 6.2.5 Integration of CTS+ and Change Request Management ..... 6.2.6 Conclusion ....................................................................... Extension Developments and Development Package ................... Customer-Specific Tab ................................................................. 6.4.1 Defining the Necessary Data Structures ............................ 6.4.2 Defining the Layout and Flow of the Dynpro .................... 6.4.3 Integrating the New Tab via the Screen Control ................ 6.4.4 Tabs in the Change Request .............................................. 6.4.5 Inserting the Calculation Logic .......................................... Extension of the Transaction Monitor .......................................... Extended Actions and Conditions ............................................... 6.6.1 Extended Check for Text IDs ............................................. 6.6.2 Extended Check for Partner Functions .............................. 6.6.3 Displaying Transport Requests .......................................... Summary .................................................................................... 199 199 201 203 205 206 206 208 210 214 217 225 227 227 228 228 232 235 236 237 239 241 242 247 251 255

6.2

6.3 6.4

6.5 6.6

6.7

Change Management in SAP Landscapes ................................ 257


7.1 Change Management Concept .................................................... 7.1.1 Maintenance Maintenance Optimizer .......................... 7.1.2 Technical Integration ........................................................ 7.1.3 Testing .............................................................................. 7.1.4 Analysis ............................................................................ Quality Management in SAP Solution Manager ........................... 7.2.1 Functional Scope .............................................................. 257 258 260 260 261 261 261

7.2

Contents

7.3

7.2.2 Prerequisites for Quality Gate Management ...................... Summary ....................................................................................

263 265

Technical Notes on Usage and Troubleshooting ...................... 267


8.1 8.2 8.3 8.4 8.5 8.6 Adding New Systems .................................................................. System and Client Copy .............................................................. Setting Up a Project Landscape ................................................... Repair Flag for the Import ........................................................... Urgent Corrections in Parallel Systems ......................................... Transports and SAP NetWeaver Business Warehouse ................... 8.6.1 Urgent Correction ............................................................. 8.6.2 Import All ......................................................................... Import Subset and Import Project ............................................... Error Analysis .............................................................................. 8.8.1 Application Log ................................................................ 8.8.2 Reports for Completing Project Cycles .............................. 8.8.3 Authorization Problems .................................................... SAP Notes .................................................................................. 267 268 271 274 275 276 276 276 277 278 280 280 283 284 285 287

8.7 8.8

8.9

The Authors ............................................................................................... Index .........................................................................................................

Architecture of Change Request Management

Change Request Management consists of a number of individual elements in SAP Solution Manager. To appreciate the full functional scope of Change Request Management, you therefore need to understand these elements and how they work. This chapter explains the various functional areas within Change Request Management and provides an initial insight into how Change Request Management fits into SAP Solution Manager.

2.1

Elements of Change Request Management

Change Request Management represents a core functional area within SAP Solution Manager. SAP Solution Manager provides a range of functions, information, and services to support the entire lifecycle of an application. Figure 2.1 shows the stages of this lifecycle and the corresponding functions for each of these stages that are provided in SAP Solution Manager.
Implementation of SAP Solutions
SAP Methods and Tools Global Rollout Customizing Synchronization E-Learning Management Test Management

Solution Monitoring
System Monitoring Business Process Monitoring Central System Administration EarlyWatch Alert Service Level Reporting Solution Reporting

Implem en

n tio ta

Op

at er

Upgrade of SAP Solutions


SAP Methods and Tools E-Learning Management Test Management

Core Business Processes

Service Desk
Best Practices for Incident Management Integration of 3rd-Party Help Desks

ions

Op

timiz ion at
Delivery of SAP Services
Onsite/Remote SAP Safeguarding

Solution Manager Diagnostics


Safe Remote Access Performance Measurements Logs and Dumps Traces Technical Configuration

Change Request Management


Follows ITIL Standards Maintenance Processes

Figure 2.1 Change Request Management in SAP Solution Manager

33

ArchitectureofChangeRequestManagement

Change Request Management is assigned to the optimization cycle. Within this cycle, required changes that have been detected during normal system operation (for example, corrections of program errors) are implemented, documented, and monitored. The elements of Change Request Management are illustrated in Figure 2.2.

SAP Solution Manager


Project Administration Business Blueprint Configuration Testing

System Landscape Maintenance

SAP Solution Manager Project Test Cases


Documentation

SAP Change Manager Task List System and Transport Configuration Transport Tracking

Training

cProjects

cProject

System Landscape

Service Desk

SN

Change Request Management

CR

CD

Transport Management System

DEV

IMG Project CTS Project

QAS

PRD

CTS Project

CTS Project

Figure 2.2
EE

Elements of Change Request Management

Project Administration allows you to structure and classify change activities and the associated technical changes. These technical changes result in transport requests, which are distributed within the system landscape using the Transport Management System. Information about the systems or system groups that require support is also maintained in Project Administration. System Landscape Maintenance provides information about the systems that are to be supported. The systems are defined, connections configured, and various systems grouped together in logical components as part of System Landscape Maintenance (see Section 3.3.1, Defining Logical Components). In Figure 2.2, the SAP Change Manager box represents the functions specific to Change Request Management. These include the task list and the various transport tracking options.

EE

EE

34

ProjectAdministrationinSAPSolutionManager

2.2

EE

The Change Request Management box represents the two main subprocesses that make up Change Request Management. The change request and the change document each describes an organizational and technical subarea within a change. Together, they represent the complete change request process.

The next section provides a detailed description of all of these areas and how they work.

2.2

Project Administration in SAP Solution Manager

Various project types are delivered as standard with SAP Solution Manager. These serve project-related objectives in a range of scenarios, for example, implementation, upgrade, or Change Request Management for project organization, documentation, and control.

2.2.1

Solution Manager Project Types

The project types available in SAP Solution Manager are listed below:
EE

Implementation project This project type is used to implement new business processes in an SAP landscape with SAP Solution Manager. Detailed information about a process can be mapped in the form of a project structure within the project. This information includes process steps, documentation, test cases, and configuration/ customizing. Maintenance project This project type is used to maintain live solutions and is used predominantly in Change Request Management. All maintenance activities for a solution are grouped together in this project type. If the use of check-in/check-out functions is enabled in the Solution Directory, where all live processes are documented, maintenance projects are used there also. Template project The structures of a project can be defined in a template project and then made available to other projects as templates. This means that you can define processes, process steps, documentation, or test cases, and then use these as a template for an enterprise-wide rollout. It is also possible to specify in the configuration that selected areas cannot be modified.

EE

EE

35

ArchitectureofChangeRequestManagement

Check-In/Check-Out Functions Check-in/check-out functions allow you to transfer a live business process from the Solution Directory to a maintenance project without any effect on the active process. After check-out, changes can be made to the business process in the maintenance project. For example, new process steps can be defined. You then use the check-in function to transfer the changed business process back to the Solution Directory.
EE

Upgrade project Configuration settings required as part of an upgrade are made in an upgrade project. Safeguarding project Safeguarding projects are used to analyze and subsequently eliminate the causes of critical situations. Optimization project An optimization project enhances business processes or the general operation of a solution. One possible area of application for these projects arises in the context of SAP Services.

EE

EE

Projects can be created quickly using a web-based wizard, which you can access with Transaction AI_SPS. This wizard is shown in Figure 2.3. Experienced users can also access Project Administration directly, which is briefly outlined below.

Figure 2.3

Quick Project Setup

36

ProjectAdministrationinSAPSolutionManager

2.2

Transaction SOLAR_PROJECT_ADMIN provides access to central Project Administration. 1. All existing projects in SAP Solution Manager are displayed on the initial screen, which is shown in Figure 2.4. You can also click on the Create Project button to create new projects or navigate to project analysis.

Figure 2.4

Project Administration in SAP Solution Manager

2. If you double-click on a project to select it, a detailed view of that project opens. Here you can maintain various types of information that are of relevance to the project. A range of tabs is provided for this purpose, the first of which is entitled General Data. A number of required entries need to be maintained on this tab, including Project Language and Project Description. Other information, such as status values and time values, are optional. 3. The other tabs, Scope, Proj. Team Member, Milestones, System Landscape, and Project Standards, contain various types of information that are not discussed in more depth at this point because, with the exception of the information on the System Landscape tab, these are not essential to Change Request Management (see Figure 2.5). You define the systems for a project on the System Landscape tab. Here you can choose a logical component in order to select the systems belonging to an SAP product and assign these to the project. 4. You define a logical component in System Landscape Maintenance (Transaction SMSY), where you combine logical systems in logical components that can then be used in various scenarios, such as implementation, testing, or Change Request Management (see Section 3.3.1, Defining Logical Components).

37

ArchitectureofChangeRequestManagement

Figure 2.5

Detailed Information About a Solution Manager Project

Figure 2.6 shows an example of a logical component, ZCHARM_LANDSCAPE, together with its assigned logical systems ST4:200, ST4:300, and ST4:400. The name of each logical system consists of the system ID and client. Here, the logical systems are the three clients of an SAP Solution Manager system that represent a three-system landscape. This configuration is often used during the initial setup of Change Request Management to verify locally that the setup is correct. It allows you to test all functions of Change Request Management, including change transports. Only the transport of Workbench objects cannot be simulated, owing to the cross-client validity of these objects. Before we discuss the additional configuration options and information about the System Landscape tab in more detail, we will briefly explain, in the next section, the fundamentals of the Change Request Management architecture. This section describes other types of projects in addition to the Solution Manager projects specified above. We will then return to the topic of Project Administration in the following sections.

38

ProjectAdministrationinSAPSolutionManager

2.2

Figure 2.6

System Landscape Project Administration

2.2.2

SAP Solution Manager Projects in Change Request Management

As mentioned above, Solution Manager projects provide a basis for various scenarios in SAP Solution Manager. Four of the project types described in Section 2.2.1, Solution Manager Project Types, can be used in the Change Request Management scenario; namely maintenance project, implementation project, template project, and upgrade project. However, some further classifications are required from the perspective of Change Request Management. A distinction is made among the four project types based on whether they are executed cyclically (recurring) or once only (nonrecurring). As shown in Figure 2.7, a maintenance project is defined as recurring because it is always started again after it has been successfully completed. Implementation projects, template projects, and upgrade projects, on the other hand, are nonrecurring. There is normally only a single project start and end date for these projects.

Maintenance Project

Recurring

Non-Recurring
Figure 2.7

Implementation Project

Template Project

Upgrade Project

Recurring and Nonrecurring Projects

39

ArchitectureofChangeRequestManagement

The reasoning behind this distinction has to do with the associated functional requirements of Change Request Management. A maintenance project involves maintaining processes or functions that are already used in production. The situation is different in projects of a nonrecurring nature, such as implementation projects. In this case, a new process or function is implemented for the first time and is only used in production after the project has been successfully completed. This fundamental difference gives rise to different functional requirements, which are discussed in more detail in Section 2.2.4, Project Cycle and Task List. Solution Manager projects are a prerequisite for using Change Request Management. You create and manage these projects in SAP Solution Manager. However, additional project functions are used in the managed systems and linked to the Solution Manager project to facilitate the monitoring of changes in these systems. The project functions used are the IMG (Implementation Guide) project and the CTS (Change and Transport System) project, which are discussed in more detail in Section 2.2.3, IMG Projects and CTS Projects. Both project functions are Basis functions and are therefore available in SAP NetWeaver or SAP Basis. If you activate Change Request Management for a Solution Manager project (see Section 3.3.2, Creating a Solution Manager Project), an IMG project is generated automatically in the development system (of the logical component), and the information in the Solution Manager project is stored there. If several logical components are assigned to a Solution Manager project, an IMG project is created in each development system defined. With IMG projects, you also have the option of creating a direct link to CTS projects. This option, in turn, allows you to assign all changes and therefore also all transport requests from CTS projects to the IMG project. Figure 2.8 illustrates the interaction between the various projects and the associated systems. Other functions in SAP Solution Manager are shown here alongside the projects described above; namely, the project cycle and task list, as well as the optional connection to cProjects, a project management solution. A detailed explanation of IMG and CTS projects is provided below, followed by a discussion of the functions that are fulfilled by the project cycle and task list. The section concludes by examining the option of integrating cProjects into Change Request Management.

40

ProjectAdministrationinSAPSolutionManager

2.2

SAP Solution Manager


Project Cycle Change Transaction

Development System

Logical System (System and Client)

Project Cycle Task List

Transport Requests

IMG Project

CTS Project

cProjects
Project (Created in cProjects) Solution Manager Project

D
IMG Project
CTS Project

D
Figure 2.8 Architecture of Change Request Management

2.2.3

IMG Projects and CTS Projects

As explained above, IMG and CTS projects represent Basis functions and are therefore available in any SAP NetWeaver system.
EE

IMG (Implementation Guide) projects allow you to coordinate customizing activities and save the resulting changes in a project. CTS (Change and Transport System) projects are parameters that can be used to group transport requests. CTS project functions for the project in question can be activated in an IMG project.

EE

In SAP Solution Manager, you can link Solution Manager projects with IMG projects to access the systems in the IMG projects. The option of assigning a CTS project to an IMG project means that the relevant information about transport requests can also be used in an IMG project and, ultimately, in the Solution Manager project. Figure 2.9 shows a Solution Manager project of the maintenance project type. The System Landscape tab shows several subcategories (you will recognize the Systems tab from Figure 2.6).

41

ArchitectureofChangeRequestManagement

Figure 2.9

Maintenance Project with Assigned IMG Project

1. If you select the IMG Projects tab, the assigned IMG project (CHARM01) is shown. Logical system ST4:200 is assigned to this IMG project. This corresponds to the development system of the demo landscape, which consists of the logical systems ST4:200 (development), ST4:300 (quality assurance), and ST4:400 (production). 2. If you select the IMG project and click on the Display button, you automatically access the IMG project view in the corresponding development system. Figure 2.10 shows the detail view of the IMG project in the development system.

Figure 2.10 IMG Project in the Development System

42

ProjectAdministrationinSAPSolutionManager

2.2

The structure and display of the IMG project are very similar to those of the Solution Manager project. The only indications that this is a different project type are the type description Customizing Project at the top of the screen and the number of tabs. 3. Next, select the Transp. Requests tab, which is shown in Figure 2.11.

Figure 2.11 Selecting the Transp. Requests Tab in an IMG Project

The Transp. Requests tab shows information about CTS functions. From here, you can also access information about the project data of the CTS project and information about the transport requests assigned to the CTS project (see Figure 2.12). 4. If you click on the Display CTS project data button, the screen shown in Figure 2.13 is displayed. Here you can see the CHARM01 IMG project and the corresponding ST4_P00001 CTS project. The other buttons, Assigned CTS Requests and CTS Project Piece List (see Figure 2.12), also display relevant information about transports.

43

ArchitectureofChangeRequestManagement

Figure 2.12 The Transp. Requests Tab in an IMG Project

Figure 2.13 CTS Project Data

5. The final screen element to describe in relation to CTS projects is the project status switches. The project status switches for CTS projects allow you to activate or deactivate various properties for the CTS project and for the corresponding transport requests. Figure 2.14 shows the project status switches for a CTS

44

ProjectAdministrationinSAPSolutionManager

2.2

project. Of particular relevance here are the switches for creating, releasing, and importing transport requests.

Figure 2.14 Project Status Switches of a CTS Project

6. If Change Request Management is active, it controls and monitors these switches. This means you can prevent the creation of transport requests in the supported systems for change activities that are not part of Change Request Management. You will find detailed information about configuration, in particular in relation to the mandatory assignment of requests to projects, in Define Project Assignment for Requests as Mandatory in Section 3.2.1. Now that you are familiar with the various project types and how they interact in Change Request Management, an introduction to the project cycle, task list, and integration of cProjects is provided below.

2.2.4

Project Cycle and Task List

Up to this point, we have described functions used by Change Request Management to gather information about changes in managed systems. To use this information for a wide range of operational activities, such as the distribution of transports, a functional basis for the execution of these activities is required.

45

ArchitectureofChangeRequestManagement

In Change Request Management, this basis is provided by the scheduling tool, which is based on the familiar Schedule Manager function for executing and monitoring recurring tasks. In Change Request Management, the Schedule Manager allows you to execute a variety of operational tasks, including the import of transports into target systems and the creation and release of new transport requests. This scheduling tool also allows you to control the lifecycle of a Solution Manager project. All projects have a certain lifecycle, referred to as the project cycle. There is always a 1:1 relationship between a project and project cycle, which is, in turn, divided into a number of phases. These phases reflect the individual steps involved in a project, such as the development phase and test phase. The scheduling tool maps project phases and the functions required during each of these. The possible phase values for a cycle, which are identical in all projects, are as follows: Created, Development without Release, Development with Release, Test, Emergency Correction, Go-Live, To be Closed, and Completed. The phase values that are relevant for daily system operation are Development without release, Development with Release, Test, Emergency Correction, and GoLive. Various activities are executed within these phases over the course of a project. Figure 2.15 shows the interaction between a project, project cycle, and the individual phases with the corresponding changes.

cProjects SAP Solution Manager Project (e.g. Implementation Project)

Development (without and with Release)

Project Cycle
Test Emergency Correction
Synchronization

Go-Live

Synchronization Development Activity

Synchronization

Figure 2.15 Implementation Project, Project Cycle, and Changes

46

ProjectAdministrationinSAPSolutionManager

2.2

From a technical perspective, the project cycle, as shown in Figure 2.16, is represented by a generated task list (Schedule Manager) and a change transaction (CRM document). The task list contains a list of activities and a representation of the systems supported within the project cycle, and it indicates the current phase of the project cycle. The task list is part of the working environment of the IT operator. The change transaction allows you to move from one project phase to the next and provides information about the transport requests belonging to the project. For more detailed information about the task list, see Section 4.3, Administration. Figure 2.17 shows an example of a task list.

Project Cycle
Change Transaction Task List

Figure 2.16 Project Cycle of a Solution Manager Project

Figure 2.17 Task List in Change Request Management

47

ArchitectureofChangeRequestManagement

The project cycle shown in Figure 2.16 could apply to an implementation project, template project, or upgrade project. It is useful to recall, at this point, the difference among these project types and maintenance projects (see Figure 2.7). Maintenance projects also have their own project lifecycle. However, in this case, it is referred to as the maintenance cycle. For example, a permanent maintenance project for a live solution may be divided into maintenance cycles of three months each. All necessary support and maintenance tasks are executed within these maintenance cycles. These include, most importantly, development and testing of corrections. These activities are divided into phases within each three-month maintenance cycle. For example, each cycle includes a development phase and a test phase. At the end of the three months, the maintenance cycle has reached the final phase and all of the changes from the cycle as a whole are imported into the production system. The maintenance cycle can be completed after a successful import into the production system, and a new maintenance cycle can then be generated to manage all changes that arise over the next three months. This continuous cycle is illustrated in Figure 2.18.

Maintenance Project

Maintenance Cycle with Phases

Change Transaction

Task List

Figure 2.18 Maintenance Project and Maintenance Cycle

Maintenance projects differ from other project types in one important respect. Within a maintenance cycle, it may be necessary to import an important change or correction into the production system as quickly as possible. In this case, the threemonth cycle is too long. A special change transaction is therefore provided for this very typical scenario. This change transaction is referred to as an Urgent Correction.

48

ProjectAdministrationinSAPSolutionManager

2.2

This change transaction is only available in maintenance projects, and enables an immediate transport of changes into the production system, independent of the phases in the maintenance cycle. This special feature of maintenance projects sets them apart from other project types. For a detailed description of urgent corrections, refer to Section 2.3.5, Urgent Correction. Figure 2.19 illustrates the various change types in a maintenance project. Here, once again, you can see the interaction between the maintenance project, maintenance cycle, and corresponding phases. This figure also indicates the phases in which normal corrections and urgent corrections can be made and executed within the maintenance cycle. As you can see, normal corrections for a maintenance cycle are only possible during the development phases (development with and without release). During subsequent phases, normal corrections can only be transported into the quality assurance system and, from there, into the production system. Urgent corrections, on the other hand, can be created up until shortly before the go-live to ensure their integration into the same maintenance cycle.

cProjects SAP Solution Manager Project (Maintenance Project)

Maintenance Cycle
Development (without/with Release)

Test

Emergency Correction Synchronization

Go-Live

Synchronization Normal Correction

Synchronization

Urgent Correction (Independent of Maintenance Cycle)

Figure 2.19 Maintenance Project, Maintenance Cycle, and Transactions

49

ArchitectureofChangeRequestManagement

As explained in the detailed discussion of normal corrections later in this chapter (see Section 2.3.4, Normal Correction/Development Activity), you can also create a normal correction after the development phases. However, these will then be part of the next maintenance cycle.

2.2.5

cProjects

Integration of the Collaboration Projects (cProjects) solution for project management into Change Request Management represents an optional enhancement. This integration establishes a 1:1 link between a cProjects project and a Solution Manager project, so that the Change Request Management process benefits from the advanced project management functions in the cProjects project. You can then use a range of functions (such as phase-based project management); define milestones, roles, and deliverables; and display projects in graphical form as Gantt charts. It is also important to point out exactly how cProjects and Change Request Management interact. If a cProjects project is assigned to a Solution Manager project, the cProjects project has the same phase values as the corresponding Solution Manager project. The following phase values are relevant in this case: Development without Release, Development with Release, Test, Emergency Correction, Go-Live, and To be Closed. If a new phase is selected during the Solution Manager project cycle for example, if the phase changes from Development with Release to Test a consistency check is run against the cProjects project to verify the phase value is also Test in that project. If not, a warning is issued in the task list, indicating an inconsistency with the cProjects project. The correct phase value must then be set in the cProjects project before it can be set in the task list or change transaction. This means that cProjects plays a leading role in terms of project organization. It therefore provides an effective working environment for project leads (see Figure 2.20). Before you can integrate cProjects, you require a Solution Manager project with Change Request Management activated. In addition, a task list must have been generated for the project.

50

TransactionTypes/Workflows

2.3

Figure 2.20

cProjects with Maintenance Project

2.3

Transaction Types/Workflows

In Change Request Management, various workflows are provided to fulfill diverse process requirements. These workflows are not to be confused with SAP Business Workflows. The relevant workflows were introduced in Section 1.3.1, Change (Request) Workflows. Here, we explain various workflows that are used either directly or indirectly in Change Request Management. From a technical point of view, all of these workflows represent various transaction types created in the CRM service process transaction (CRMD_ORDER). Transaction types are documents created in the CRM service process transaction. They can be used to represent a defined process flow, provided that the relevant Customizing settings are configured. The transactions can be opened and edited in the service process transaction.

51

ArchitectureofChangeRequestManagement

Various transaction types (such as Service Desk messages or change requests) can be linked together to unite different processes. You can display these links by checking the document flow in Transaction CRMD_ORDER, for example. Links between transaction types can be set by default or defined by the user in a selection field. In this way, follow-up documents and processes can be linked on the basis of the values in the selection field in the original document. Figure 2.21 shows the possible links.
Change Process

Urgent Correction Change Request Normal Correction

Service Desk Message

Administration

Test Message

Figure 2.21

Transactions in Change Request Management

The Service Desk message is not part of Change Request Management, but it often initiates actions in Change Request Management. The Service Desk is another functional area in SAP Solution Manager, which is used in the context of Incident Management. In a Service Desk message, you have the option of creating a linked change request. This option also represents an intersection with Change Request Management because the change request is the source document for all subsequent activities in Change Request Management. The change request may give rise to various follow-up transactions. These transactions are mapped by default by urgent corrections, normal corrections, and the administration message. Test messages represent a special case because they are issued without a change request. Information about the people and systems involved is stored in each transaction. This information is stored as master data, which must be maintained in SAP Solution Manager. Business partners need to be maintained for the people involved, whereas information must be maintained in the installed base (IBase) for the supported systems. For more detailed information about configuring Change Request Management, refer to Section 4.1.3, Change Manager.

52

TransactionTypes/Workflows

2.3

2.3.1

Service Desk Message

The default SAP transaction type for the Service Desk message, which has the technical name SLFN, represents a separate functional area in SAP Solution Manager. Service Desk functionality allows you to create problem messages in SAP Solution Manager directly or in a connected satellite system. This gives the end user the option of reporting errors or problems and storing this information centrally in SAP Solution Manager, where it can then be processed by the service organization. A web-based interface (the Work Center) allows end users to check the current status of their Service Desk messages at any time and to respond as appropriate. An example of a Work Center is provided in Figure 2.22. Service Desk functions include an option for switching among various organizational units, access to a separate solution database, a search function for finding SAP Notes, and a direct exchange with the SAP support organization. One advantage of using Service Desk functionality is the possibility of creating an SAP customer message for SAP from your own Service Desk. The reply from SAP is also replicated directly to the Service Desk in SAP Solution Manager and can be processed further there.

Figure 2.22

Work Center for Incident Management

53

ArchitectureofChangeRequestManagement

If the analysis performed within the Service Desk indicates that corrective action is required, the Service Desk employee can create a change request from the Service Desk message. Figure 2.23 shows how a change request can be created from a Service Desk message in the service process transaction CRMD_ORDER. Here you can call various functions from the action list. A change request can be created directly with the Create Change Document action.
Note The use of the term change document in this action is somewhat confusing because the action creates a change request. As we will see later, this change request subsequently results in a change document.

Figure 2.23

Creating a Change Request from a Service Desk Message

2.3.2

Change Request

A change request, which is referred to by the technical name SDCR in Customizing, represents the first subprocess of Change Request Management. Its main role is to document the request and all associated information, which can be classified as required or optional.

54

TransactionTypes/Workflows

2.3

Some information is essential to ensure that no errors occur during further processing of the request in Change Request Management. This required information includes a description of the request in the text field provided, and information about the systems and users affected (for example, the change manager). A change type must also be selected. This specifies the transaction that is to be used to implement the change. Here, you can choose between a normal correction and an administration message. In the case of maintenance projects, you also have the option of implementing an urgent correction. The optional information that can be specified in the change request includes dates, additional user information, categorizations, and additional textual information, such as a description of the effects on business processes or systems. You can also attach documents to the request. The purpose of the change request is to have a change approved or rejected. A status profile is provided to identify the various steps from the creation of a request to the final decision regarding the change. This status profile contains various status values, which are displayed in the change request as the user status. Figure 2.24 shows an extract from the service process transaction (CRMD_ORDER), which includes the user status.

Figure 2.24

User Status in a Change Request

The standard process delivered by SAP contains the following status values: To Be Approved, Rejected, Approved, Implemented, and Confirmed.

55

ArchitectureofChangeRequestManagement

If these status values cannot adequately map your change request process, the relevant status profile can easily be supplemented or modified. Customers tend to have their own specific process for handling a change request. In many cases, various departments or partners need to be involved to ensure that a sound decision can be made regarding the implementation or rejection of the change at the end of the change request process.
Tip: Changing the Status Profile Do not change the standard SAP status profile. Instead, copy the status profile (SDCRHEAD) to the customer namespace. Make any necessary changes in the copied profile and then assign the new status profile (for example, ZDCRHEAD) to transaction type SDCR. The SOLMAN_CM_GENERAL IMG activity similarly advises you to always use an SAP profile as a template if you want to define your own profile.

To conclude this section, we need to look again at the transaction type that must be specified in the change request. As stated above, the selection of a transaction type represents a required entry in a change request. If you fail to enter required information or if you enter information incorrectly, a red traffic-light icon appears in the top right of the screen in the service process transaction. You can click on this icon to display a description of the error. Figure 2.25 shows an example of an error message text that was issued because a transaction type was not specified in the change request.

Figure 2.25

Error Message in the Change Request

The change type is specified in the Subject field, where you can select from all available change types. We have already introduced you to these change types at the start of Section 2.3, Transaction Types/Workflows. In other words, the change types correspond to the transaction types Normal Correction, Urgent Correction, and Administration. For implementation projects, template projects, and upgrade

56

TransactionTypes/Workflows

2.3

projects, the term normal correction is replaced by the term development or development activity. This change is made only for the purpose of greater clarity because these projects result in new developments rather than corrections. From a technical perspective, this corresponds to the Normal Correction transaction type (see Section 2.3.4, Normal Correction/Development Activity). To summarize, the following change types are available:
EE

Implementation project, template project, upgrade project


EE EE

Development/Development Activity Administration

EE

Maintenance project
EE EE EE

Normal Correction Urgent Correction Administration

The selection menu for change types is shown in Figure 2.26.

Figure 2.26

The Subject Field in a Change Request

Once all of the required information has been entered in the change request, an action to reject or authorize the request can be executed. When you select one of these actions in the action list of the change request, the status value is set

57

ArchitectureofChangeRequestManagement

accordingly. Figure 2.27 shows the action list for authorizing or rejecting a change request.

Figure 2.27

Authorizing a Change Request

If the change request is rejected, the user status Rejected is set automatically and the document is closed. No further changes can be made to the document as of this point. If the change request is authorized, the user status is set to Approved. In this case, additional activities are executed in the background. First, a follow-up transaction is generated for the change request in the same way as for the activity between the Service Desk message and the change request. The transaction generated depends on the selection made in the Subject field; for example, it may be an urgent correction. Change Request Management then searches for a project or maintenance cycle for the system specified in the change request. If only one project or maintenance cycle exists for the system, this is automatically assigned to the follow-up document. However, if several project or maintenance cycles exist for a system, the system prompts you to select a project or maintenance cycle from a selection menu. Once all of these actions have been successfully executed, the status of the change request is set to Authorized. Once it has this status, no further activities can be executed in the change request. The Change Request Management process now continues in the follow-up transaction; that is, in the change document.

2.3.3

Change Document

Change document serves as an umbrella term for the transaction types for Urgent Corrections, Normal Corrections, Administration, and Test Messages. As illustrated

58

TransactionTypes/Workflows

2.3

in Figure 2.28, it consists of all transaction types used for the technical implementation of a change request.

Change Process

Urgent Correction

Service Desk Message

Change Request

Normal Correction

Administration

Test Message

Figure 2.28 Change Documents

This clearly indicates once again the general division of the Change Request Management process into sub-processes. Change requests are used to document and organize requests. The focus here is on information gathering and documentation, followed by authorization or rejection of the request. Change documents, meanwhile, implement an approved change request. Because various processes can be used to implement a change, you can choose here between the familiar transaction types Normal Correction, Urgent Correction, and Administration message.

2.3.4

Normal Correction/Development Activity

A normal correction, which is also referred to as a development activity as part of an implementation, template, or upgrade product, represents the typical process used for new or change implementations. Most changes should be executed with this transaction type. The technical name of the transaction type is SDMJ. The technical name SDMI indicates another transaction type called Normal Correction in SAP Solution Manager. This is the initial version of this transaction, which can still be used. Enhancements of the process and functions have given rise to the new version SDMJ, which is the standard version now recommended and maintained by SAP.

Change Documents

59

ArchitectureofChangeRequestManagement

Differences Between SDMI and SDMJ The main difference between these two transaction types concerns the transfer of the correction from development to testing. In version SDMI, the relevant transport request is released after the development activity is completed, and can then be imported into the quality assurance system. If testing in the quality assurance system results in errors, the developer must create a new transport request in the development system and repeat the procedure. If several transport requests are created in this way, the mechanisms of the Transport Management System give rise to a situation where all test transports into the quality assurance system are also contained in the import buffer of the production system. If the correction cannot be tested without errors by the time the project or maintenance cycle comes to an end, the developer may be forced to import the defective developments into the production system at the end of the cycle. Version SDMJ bypasses this problem because only one transport of copies is executed between the development and quality assurance systems. Copies of the changes are therefore transported in a new transport request. This transport request is imported only into the target system and not into the production system. As a result, the original transport request remains in the development system until the correction has been tested successfully. The original transport request is only released after successful testing and can then be imported into the quality assurance system again, where an integration test is subsequently performed during the test phase for the entire project.

Various users may be actively involved in a normal correction as part of the Change Request Management process. These are normally the change manager, developer, tester, and IT operator. For detailed information about roles in Change Request Management, see Section 4.1, Roles and Activities. During the course of a normal correction, these users (for example, the developer) can set the correction to In Development (see Figure 2.29) and then generate transport requests in the development system, to which the change will be added later. You can navigate directly from the Normal Correction document to the development system and implement the correction or development activity there. Changes can then be saved directly in the existing transport requests. After the development activities have been completed, the normal correction can be transferred to testing. The change is automatically released in the development system and can then be imported into the quality assurance system. Once the correction or development is ready for testing, you can navigate directly from the

60

TransactionTypes/Workflows

2.3

Normal Correction document to the quality assurance system and conduct testing there. Testing can then be evaluated as successful or unsuccessful in the normal correction.

Figure 2.29 Normal Correction

If testing is unsuccessful, the status of the change document is reset to In Development, whereas successful testing changes the status to Consolidated. This status indicates that testing has been successful and enables an import of the change into the production system. This import normally occurs at the end of the project or maintenance cycle, together with the import of all other change documents, and should be executed by an IT operator. When all changes have been successfully imported into the production system, the individual change documents can be completed by setting the user status from Consolidated to Production. This can be done manually or with a report.
Note For detailed technical information about the administration and use of Change Request Management, refer to Chapter 5, Security in Change Request Management, and Chapter 8, Technical Notes on Usage and Troubleshooting.

61

ArchitectureofChangeRequestManagement

The various user statuses that represent the individual steps involved in a normal correction are as follows: Created, In Development, To be Tested, Consolidated, Production, and Withdrawn. These status values map the various steps in a normal correction, provide a general overview for users, and facilitate navigation. Figures 2.30 and 2.31 show the activities that are possible in a Normal Correction document during the various phases of a project or maintenance cycle. Figure 2.30 demonstrates that a normal correction can only be created and transported during the development phases of a project (implementation, template, or upgrade project). Once the project has entered the Test phase, any necessary improvements or corrections can be executed using a test message (see Section 2.3.7, Test Message). All corrections must be released or withdrawn in the development system when the project passes into the Test phase. Any necessary corrective action can still be implemented during the Test and Emergency Correction phases. However, transport requests can only be created centrally in the project task list at this point. This figure also shows that an import into the production system can only occur during the Go-Live phase.
Projects (Implementation, Template, and Upgrade Project)
In Development Finish Development Production Import Approval
Normal Correction

Request

Release

Phase

Created Development without Release Development with Release Test Emergency Correction Go-Live Being Completed Completed

O O O X X X X X

X O O X X X X X

X O O X X X X X

X X O X X X X X

X X O X X X X X

Pass to Test

X X O X X X X X

X X X X X O X X

Figure 2.30

Project Phases and a Normal Correction

62

TransactionTypes/Workflows

2.3

Figure 2.31 shows a normal correction in a maintenance project. In this case, a normal correction can be created and edited at any stage. However, once the maintenance reaches the Test phase, any normal corrections created during this or subsequent phases are not part of the current maintenance cycle. Instead, these corrections are integrated into the next cycle and can be transported into the production system as part of this cycle.
Projects (Maintenance Project)
In Development Finish Development Production Import
Normal Correction

Approval

Request

Release

Phase

Created Development without Release Development with Release Test Emergency Correction Go-Live Being Completed Completed

O O O O O O X X

X O O O O O X X

X O O O O O X X

X X O X X X X X

X X O X X X X X

Pass to Test

X X O X X X X X

X X X X X O X X

Figure 2.31

Maintenance Project Phases and a Normal Correction

An export of a normal correction is only possible within the document during the Development with Release phase. Once the project reaches the Test phase, normal corrections from the maintenance cycle can no longer be released from a document. This prevents the transport of changes into the quality assurance system during the Test phase and therefore during the integration test. The system behavior described here indicates the possible actions that can be executed in a normal correction document. The central task list of the maintenance cycle allows the IT operator or project lead to take corrective action. This means the task list can be used to create transport requests and transport these into the test system during the Test and Emergency

63

ArchitectureofChangeRequestManagement

Correction phases. This is an option to be used in exceptional cases only. However, it gives you the flexibility you need to implement essential corrections at the last minute. Note also that only the IT operator or project lead should be authorized to implement corrective action in this way.

2.3.5

Urgent Correction

Urgent Correction, which is only available in maintenance projects, is a transaction used when a change must be transported immediately into the target system. It therefore gives you the option of transporting a change into the production system before the end of a maintenance cycle. Later, we will show that no problem occurs with this procedure, particularly with regard to data consistency. The urgent correction, which has the technical name SDHF, is a partly automated transaction. Many activities are executed automatically in an urgent correction, in contrast to a normal correction, where a large number of activities depend on the specific selections made by the user. For example, transport requests are immediately generated after an urgent correction is set to In Development. In addition, an individual urgent correction can be transported into the production system within the document. In a normal correction, by contrast, an IT operator executes this final step centrally for all corrections at the end of a project or maintenance cycle. This flexibility is due to the individual task list of an urgent correction. As explained above in Section 2.2.4, Project Cycle and Task List, normally only project or maintenance cycles have a task list. If changes of the normal correction, test message, or administration type are executed in a project or maintenance cycle, the current phase of the cycle determines whether it is possible to release a normal correction or create a test message, for example. In this way, the phases of cycles determine the scope of permitted activities. An urgent correction therefore has its own task list, which allows it to take effect independently of these restrictions. Urgent corrections may have the following user statuses: Created, In Development, To be Tested, Successfully Tested, Authorized for Import, Production, Confirmed, completed, and Withdrawn. As shown in Figure 2.32, an urgent correction can be created and changed at any stage up to the Emergency Correction phase. In the Go-Live phase, an urgent correction can be created but cannot be exported.

64

TransactionTypes/Workflows

2.3

Projects (Maintenance Project)


In Development Release for Import into Production Approval Production Import
Urgent Correction

Request

Release

Phase

Created Development without Release Development with Release Test Emergency Correction Go-Live Being Completed Completed

O O O O O O X X

X O O O O O X X

X O O O O O X X

X O O O O X X X

Pass to Test

X O O O O O X X

X O O O O O X X

X O O O O O X X

Figure 2.32

Maintenance Project Phases and an Urgent Correction

2.3.6

Administration Message

The administration message (technical name SDAD) is used to document activities that do not result in a transport request; for example, changing number ranges or maintaining master data. Therefore, an administration message is only ever of relevance to a selected system, rather than to the entire system group (development, quality assurance, and production system), as is the case in normal or urgent corrections. The purpose of an administration message is to document these specific changes so that it is possible to track, at any point, which users have made which changes to the system. An administration message may have the following status values: Created, In Process, Completed, Confirmed, and Withdrawn. In principle, an administration message offers the same functionality as a normal or urgent correction. You can navigate directly from an administration message to the relevant system and enter the relevant documentation in various text types. The only functions not available in an administration message are those relating to the Transport Management System.

65

ArchitectureofChangeRequestManagement

Figure 2.33 shows the possible activities in an administration message in the various phases of the project cycle.
All Project Types
In Development
Administration

Release for Import into Production

Approval

Request

Release

Phase

Created Development without Release Development with Release Test Emergency Correction Go-Live Being Completed Completed

O O O O O O X X

X O O O

X O O O O O O X X

Pass to Test

X O O O O O X X

X X

X X

X X

Figure 2.33

Project Phases and an Administration Message

2.3.7

Test Message

As already stated in Section 2.3, Transaction Types/Workflows, the test message represents something of an exception. This transaction type (technical name SDTM) is created without reference to a change request. Test messages are used for troubleshooting purposes during the integration test and can therefore only be created during the Test phase of a project or maintenance cycle. Because a test message refers to the correction of a change that has already been approved, there is no need for a change request in this case. The users involved in a test message are the developer and the tester. A tester can create a test message in Transaction TEST_CREATE during the integration test. The developer can then create a corresponding correction in the development system and then transfer this to the tester for retesting. When the correction has been imported into the quality assurance system, the tester can conduct a new test to include the correction. If this test is successful, the test message is completed.

66

Production Import

X X

TransactionTypes/Workflows

2.3

A test message may have the following user statuses: Created, In Process, To be Retested, Confirmed, and Withdrawn. Finally, as shown in Figure 2.34, a test message can only be created and changed during the Test phase of a project cycle.
All Project Types
In Development Release for Import into Production Approval Production Import
Test Message

Request

Release

Phase

Created Development without Release Development with Release Test Emergency Correction Go-Live Being Completed Completed

O O O O O O X X X X O

X X X O X X X X

X X X O X X X X

Pass to Test

X X X O X X X X X X X X

Figure 2.34

Project Phases and a Test Message

2.3.8

Job Request

If you already use the enhancement Job Scheduling Management with SAP Central Process Scheduling by Redwood, you can also use it in conjunction with Change Request Management. This gives you the option of using the Service Desk message to document a job request and to process changes to job documentation in Change Request Management. A job request can be processed and approved as part of a change request. Corresponding job documentation is then edited and documented in a change document.

2.3.9

Change Transactions for Projects

The change transactions for project cycles and maintenance cycles are mapped with transaction types SDDV and SDMN. As explained in Section 2.2.4, Project

67

ArchitectureofChangeRequestManagement

Cycle and Task List, project cycles, regardless of project type, consist of a generated task list and a change transaction. The change transaction of a project allows you to transition from one phase to the next, following the now familiar sequence of phase values: Created, Development without Release, Development with Release, Test, Emergency Correction, Go-Live, Being Completed, Completed, and Withdrawn. The activities permitted during the various project phases can be deduced from the explanations provided above.

2.4

Summary

This chapter introduced you to the various elements of the Change Request Management functionality. It explained how these fit into SAP Solution Manager as a whole and explained the Project Administration function and the concept of a project cycle. The various transactions in Change Request Management were then described in detail. We will return again and again to these fundamental elements of Change Request Management and examine each in more detail over the course of this book.

68

Index
A
ABAP Dictionary object retrofit, 140 Action, 98, 99, 128, 241 definition, 96 list, 54, 58, 97, 119, 153 profile, 96 task list, 160 Activation cross-system object lock, 90 log, 76, 137, 146 Administration, 64 Change Request Management, 148 Administration message, 56 Change Request Management, 52, 55 transaction type, 59, 65 Administrator authorization, 82 Application log, 167, 192, 280 Application management, 21 Approval, 191, 194 critical transport, 156 Architecture, 33, 38 Attachment, 127 Authorization, 183 extended, 185 object, 105 reporting, 171 role, 183 user status, 129, 130 Availability management ITIL, 25 SOCM_PROCESS_ACTION, 252 BAdI enhancement action, 99 Basic configuration, 70, 72 Basic setting action, 99 consistency check, 100 BCOS_CUST, 189 BC set, 76, 101, 134, 136, 145 retrofit, 140 Bill of material, 197 Browser, 181 Build phase, 262 Business partner, 94 transaction monitor, 171 Business process, 22, 142, 146 Solution Directory, 144 Business process and interface monitoring work center, 175 Business Process Change Analyzer, 260 Business process monitoring, 23, 142 logical component, 102 Business scenario, 22, 146

C
Capacity management ITIL, 25 Catalog, 92 Categorization, 112 Category, 173 Change advisory board, 18, 19, 114 partner function, 111 Change Analysis, 261 Change document, 59, 61, 178 Change Request Management, 35 transaction type, 58 work center, 176, 178 Change Management, 113, 257 ITIL, 27 work center, 175

B
BAdI CRM_CUSTOMER_H_BADI, 229 CRM_DNO_MONITOR, 239 CRM_ORDER_AUTH_CHECK, 186 SOCM_CHECK_CONDITION, 245

287

Index

Change manager, 18, 19, 29, 60, 113, 118, 120, 131, 192, 194 partner function, 111 retrofit, 135 sample process, 133 Change request, 18, 20, 29, 35, 52, 54, 56, 58, 59, 67, 113, 119 authorize, 120 creation, 117 hot news, 141 management, 74, 99 process, 35 request for change, 18 work center, 176, 177, 178 Change Request Management, 18, 24, 28, 33, 45, 54, 69, 73, 225 configuration, 129 logical component, 103 process, 59, 60 project administration, 30 reporting, 170 transaction type, 98 Change tracking, 163 Change transaction, 47, 67, 117 partner function, 111 project cycle, 154 task list, 159 type, 90, 98 Check, 101 reporting, 31 task list, 160 Check-in, 146, 148 business process, 36 Check-out, 146, 148 business process, 36 Check report, 101, 108 Client logical system, 103 RFC connection, 105 Client copy, 268 Client setting, 162 Close coupling, 215 Code, 92 group, 92 group profile, 92 Completion task task list, 149, 159

Component configuration, 71 logical, 37, 102, 104, 105, 107, 139, 267, 272 Condition, 98, 241 action profile, 97 consistency check, 100 definition, 243 status value, 100 Condition editor action profile, 98 Configuration, 69, 72 extended, 85, 162 project, 154 Transport Management System, 77 work center, 179 Configuration management ITIL, 16, 27 Configuration node IMG, 72 Conflict analysis, 187 Conflict scenario cross-system object lock, 89 Consistency check, 99, 108 retrofit, 136 Context, 146 Control function change manager, 113 Copy control, 98, 101 Copying control, 251 Correction action, 62, 63 Change Request Management, 52, 55 change transaction, 48 normal, 50, 56, 62, 64 process, 116 processing, 122 synchronization, 159 test transfer, 126 transaction type, 59, 64 urgent, 49, 56, 120, 124, 131, 150 workbench, 134, 136, 140 cProjects, 40, 45, 50, 90, 91, 155 Critical transport object, 87 CRMC_MAP, 229, 231 CRMC_MSGC, 243, 248 CRMC_MSGS, 244, 248

288

Index

CRM_CUSTOMER_H_BADI, 229 CRM_DNO_MONITOR, 239 CRM_ORDER_AUTH_CHECK, 186 CTS+, 207, 213, 217, 223, 225 distributed landscape, 220 double stack landscapes, 219 CTSDEPLOY, 208 CTS project, 40, 41, 43, 83, 126, 159, 160, 161, 163 project assignment, 82 CTS Status switch project logistics, 168 Customer, 53 Customer namespace transaction type, 179 Customer-specific tab, 228 Customizing global, 206 regional, 206 request, 126 transport request, 124 Customizing distribution logical system, 102 Cutover, 134, 204, 205 Cycle completion, 160

number range, 84 package, 227 phase, 49 project cycle, 48 status, 130 system, 60, 66, 122, 133 Transport Management System, 77 user status, 128 Diagnostics root cause analysis, 175 Dictionary object, 134 Display list transaction monitor, 175 Document flow, 52, 120, 131, 160 Document management cProjects, 91 Domain controller, 71, 77, 79, 80 ABAP, 208 Domain link, 80, 217 transport domain, 80 Double stack, 207 landscape, 219 system, 210 target system, 213 Downgrade, 134, 195 Dual-control concept, 20, 115, 128 Duration type, 95

D
Daily overview task list, 153 Data collector, 170, 171 Data consistency, 64 Date profile, 95 Date rule, 95 Date type, 95 Default configuration, 73 Deploy phase, 263 Deploy service, 207 Deploy Web Service, 208, 209, 217, 221 Developer, 60, 114, 135 partner function, 112 sample process, 133 test message, 66 Development Change Request Management, 57

E
E-learning, 22, 142 material, 143 Enhancement package, 24, 258 Enterprise Edition SAP Solution Manager, 143 Error analysis, 278 Error solution ITIL, 25 Evaluation criterion, 169 Event management, 26 ITIL, 17 Execution option BC Set, 137 Execution time action, 99

289

Index

Export check, 193 critical transport object, 87

F
Fast entry text administration, 96 Flow logic, 234 Follow-up document, 121, 133 Four-level system landscape, 201 Functional tester, 115

G
Gantt cProjects, 50 Global customizing, 206 Global namespace, 206 Global template, 205

H
Hot News, 117, 140, 141, 179 work center, 176 HP Quality Center, 260 HTMLB, 180

I
IBase, 52 component, 71 ICF, 179, 180 IMG activity, 41, 55, 72, 73 number range, 84 IMG project, 107 Implementation documentation, 143 lifecycle, 22 user status, 130, 132 Implementation and upgrades work center, 175 Implementation project, 30, 35, 39, 40, 41, 42, 48, 57, 62

Import authorization, 82 error, 155, 274 IT operator, 115 project, 277 subset, 277 Inactive system, 270 Incident Management, 16, 17, 26, 52, 113 event management, 26 work center, 175 Information predecessor/successor, 195 Instance profile, 180 Integration test, 66, 115, 202, 204, 268 Interface setting partner determination procedure, 94 Internet service, 181 configuration, 180 Interval number range, 84 Issue management, 27, 71 IT Change Management, 15, 17, 19 monitoring, 20 ITIL, 15, 20, 91 change advisory board, 18, 19 change manager, 18, 19 change request, 18, 20 Incident management, 16 ITIL V3, 16, 17, 24 request for change, 18 IT operator, 60, 63, 115, 129, 130, 148 partner function, 112 sample process, 133 IT service continuity management, 25 ITSM, 15

J
Java stack system, 207 Job documentation, 67 Job request, 67 Job Scheduling Management, 67 work center, 175

290

Index

K
Knowledge Warehouse, 107, 143

Modification, 194 critical transport object, 87 Module, 234, 235 Monitoring, 20, 169 Change Request Management, 31

L
Landscape component, 104 global development, 205 Layout transaction monitor, 173, 175 License management, 178 work center, 176 Lifecycle, 16, 21, 27 project cycle, 46 SAP Solution Manager, 33 Lock entry cross-system object lock, 89 Lock information, 189 Logical component, 267, 272 logical system, 103 Logical system, 38, 42, 102, 103, 106 Loose coupling, 214

N
Namespace global, 206 regional, 206 Navigation area work center, 178 Non-ABAP object, 208, 209 Note implementation, 157 Number range, 84, 92 object, 84

O
Object critical, 163 extended configuration, 162 reporting, 31, 171 Object list, 191, 193, 195, 197 Object lock cross-system, 87, 89, 90, 163, 186, 188 information, 190 scenario, 187 update, 191 Object reporting reporting service, 88 Object version, 134 Operations lifecycle, 22 Optimization lifecycle, 24 Optimization project, 36 Order attribute, 83 Organizational Management, 172 Organizational structure, 69 Organizational unit, 172 reporting, 170 transaction monitor, 173

M
Maintenance activities, 258 Maintenance cycle, 48, 49, 58, 61, 63, 64, 160 completion, 159 retrofit, 138 scheduling, 166 urgent correction, 117 Maintenance documentation, 258 Maintenance landscape, 201, 204 Maintenance Optimizer, 258 work center, 176 Maintenance planning, 258 Maintenance project, 30, 35, 39, 40, 48, 49, 57, 63, 108, 139 number range, 84 Maintenance transaction Maintenance Optimizer, 177 Maintenance unit reporting, 170

291

Index

Overtaker, 165 Overview work center, 176

P
Package, 227 PAI, 232 module, 235 Parallel phase landscape, 203 Parallel project, 201, 203 Parallel system, 275 Parallel system landscapes, 130 Parameter transaction, 173 Partner determination procedure, 94 Partner function, 93, 94, 116 PBO, 232, 238 flow logic, 234 module, 234 Personalization filter work center, 175 Phase change, 151 control, 150, 151 Controller, 160, 273 maintenance cycle, 160 project cycle, 64, 68, 108, 151, 160 Phase landscape parallel, 203 Phase value cProjects, 50 project cycle, 46, 68 Planning project logistics, 168 Port CTSDEPLOY, 208 Postprocessing assignment, 156 retrofit, 137 system, 138, 139 Preparation configuration, 69 Preproduction system, 202 Priority, 112, 178 transaction monitor, 173 Problem management, 17, 26, 27, 113

Process, 116 Process documentation, 143 Processor current, 116, 128 partner function, 112 Process step, 22 Production user status, 129 Production manager, 116 partner function, 112 Production system, 49, 61, 62, 64, 133, 134, 138 Transport Management System, 77 Profile generator, 137 Profile parameter, 180 Project Change Request Management, 102 parallel, 201, 203 work center, 176 Project administration, 28, 30, 34, 107, 149, 154, 162 SAP Solution Manager, 37 Project analysis, 163, 165 Project assignment, 82, 163 Project category scheduling, 166 Project cycle, 30, 40, 46, 50, 58, 61, 67, 108, 148, 152, 273 administration message, 66 complete, 280 completion, 159 Project header reporting, 170 Project intersection, 195 Project landscape, 204 setup, 271 two-level, 134 Project lead, 63, 147 Project logistics, 167 Project monitor logistics, 168 Project phase project cycle, 68 Project planning cProjects, 91 Project status switch CTS project, 44

292

Index

Project structure logistics, 168 Project type, 35, 39

Q
Quality assurance system, 49, 60, 63, 128, 133 Quality gate, 263 Quality Gate Management, 178, 258, 261 phases, 262 Quality Management, 261 Quality manager, 263 Query work center, 176

R
Regional customizing, 206 Regional namespace, 206 Regression test, 200 Release, 138 Release landscape, 201 Release management, 17, 27, 258 Release manager, 114 Release package, 27 Repair flag, 274 Report work center, 177 Reporting, 169 Change Request Management, 31 SAP Solution Manager, 28 service, 87, 88 solution-independent, 177 Report on side-effects, 260 Request own, 125 Request analysis change tracking, 165 Requester, 112, 118, 131 partner function, 111 sample process, 133 Request for change change request, 18

Result list reporting, 170 Retrofit, 130, 134, 137, 156, 204 function, 130 object, 137 process, 134, 135, 138 system, 135, 136, 137, 138 RFC connection, 80, 81, 89, 104, 105, 139, 158 configuration, 75 RFC destination, 81, 104 configuration, 75 Role, 174 Change Request Management, 111 cross-system object lock, 89 type, 155 work center, 179 Role maintenance work center, 76 Root cause analysis, 23, 24, 175

S
Safeguarding project, 36 Sample process, 133 Sandbox system, 201 SAP Basis, 40 SAP Business Workflow, 51 SAP Download Manager, 259 SAP EarlyWatch Alert, 23, 25 SAP GUI, 178, 179 for HTML, 178, 179, 180, 181 setting, 179 SAP infrastructure, 21 SAP NetWeaver, 40 SAP NetWeaver Application Server, 71 SAP NetWeaver Business Warehouse transport, 276 SAP NetWeaver Development Infrastructure, 215 SAP NetWeaver Portal, 215 SAP NetWeaver Process Integration, 215, 216, 223 SAP note, 284 SAP product system landscape maintenance, 104

293

Index

SAP Service Marketplace, 72 SAP Solution Manager, 22, 25, 27, 28, 30, 37, 40, 52, 59, 107, 175 application, 117 application management, 21 change document, 35 configuration, 179 Diagnostics, 261 enterprise edition, 143 implementation, 22 ITIL, 20 lifecycle, 21 operations, 22 optimization, 24 reporting, 169 root cause analysis, 23 scheduling, 166 solution monitoring, 23 task list, 34 workflow, 29 SAP support organization, 53 SAPSYS, 283 SAP Transport Management, 206 SAP Tutor, 72, 116 SAP variant task list, 167 Satellite system Transport Management System, 76 Schedule condition action profile, 97 Schedule Manager, 46, 85, 86 task list, 47 Scheduling, 166 analysis, 165 project logistics, 168 task, 153 Scope phase, 262 Screen control, 235 Security Guide, 183 Selection criterion, 171 transaction monitor, 171 Sequence violation overtaker, 165 Service delivery work center, 175 Service Desk, 23, 29, 71 change request, 117

employee, 113 message, 53, 58, 67 partner function, 111 sample process, 133 SAP Solution Manager, 53 transaction type, 52 Service level, 23 Service-level management, 25 Service-level reporting, 23 Service lifecycle, 24 Service process monitor, 171, 173 Service process transaction, 51, 54, 55, 56, 141 CRM, 117, 118 Setting scenario-specific, 73 Side effect, 260 Single transport transport strategy, 78 SMSY_SETUP, 272 SOCM_CHECK_CONDITION, 245 SOCM_PROCESS_ACTION, 252 Software lifecycle, 142 Software Lifecycle Manager, 259 Software status change tracking, 164 Sold-to party, 116, 118 partner function, 112 Solution database, 26 reporting, 170 Solution Directory, 35, 142, 143, 144, 146, 147, 257 Solution landscape and operations setup work center, 175 Solution monitoring, 23 Solution reporting, 23, 170 service level, 23 Source system, 138 Split screen editor, 136 SPPFCADM, 253 Stakeholder, 18 Standard profile configuration, 92 Start condition action profile, 97

294

Index

Status transaction monitor, 172 Status display retrofit, 135 Status management, 94 Status profile, 55, 94 Status property, 98 profile, 94 Status switch, 151 Status value administration message, 65 status profile, 55 transaction monitor, 172 Steering committee change advisory board, 114 Structure element, 142, 144 Subject, 56, 120 profile, 92 Subject area, 173 Support Desk logical component, 103 Support package, 24, 258 import, 158 System add, 267 inactive, 270 logical, 38, 42, 102, 103, 106 parallel, 275 virtual, 269, 271 System administration, 23 work center, 175 System analysis, 163 change tracking, 164 System change option, 90, 162, 163 extended configuration, 162 project logistics, 168 System comparison, 270 System copy, 268 System data reporting, 170 System ID, 102 System landscape, 139 Change Request Management, 41 configuration, 70 four-level, 201 maintenance, 34, 37 project administration, 37

retrofit, 134 SMSY, 139 three-level, 134, 195, 199, 203 System landscape maintenance IBase, 71 System logon, 155 task list, 156 System monitoring, 23 work center, 175 System role, 139 logical component, 106

T
Tab customer-specific, 228 Table BCOS_CUST, 189 Target system, 138, 149 Task release, 126 Task list, 50, 64, 86, 139, 148, 149, 152, 154, 268 Change Request Management, 34 creation, 108 lock, 153 number range, 84 Schedule Manager, 47 urgent correction, 150 Template, 205 global, 205 task list, 150 Template project, 30, 35, 39, 48, 57 Template report task list, 86 Test management, 260 person, 128 phase, 262 plan management, 154 project cycle, 48 test case, 142, 143 test instructions, 127 transport, 269 user status, 129 Test Data Migration Server, 269

295

Index

Tester, 60, 115 functional, 115 partner function, 112 sample process, 133 Test message, 64, 66 Change Request Management, 52 transaction type, 66 Test Workbench, 260 Text administration, 95 Customizing, 96 determination procedure, 95 history, 124 object, 96 text type, 96 Three-level system landscape, 134, 195, 199, 203 TMSADM, 185 TMWFLOW/CHARMCHK, 278 TMWFLOW/CMSCONF, 190, 193 TMWFLOW/LOCKMON, 189 Track task list, 149, 156 Tracking project logistics, 168 Transaction CRMC_MAP, 229, 231 CRMC_MSGC, 243, 248 CRMC_MSGS, 244, 248 SMSY_SETUP, 272 SPPFCADM, 253 TMWFLOW/CHARMCHK, 278 TMWFLOW/CMSCONF, 190, 193 TMWFLOW/LOCKMON, 189 Transaction data reporting, 170 Transaction header text administration, 95 Transaction monitor, 121, 171 extension, 239 my department, 172 my team(s), 172 Transaction type, 51, 52, 59, 60, 90, 91, 146 date profile, 95 Transport check, 158 copy, 60, 158

directory, 209 history, 271 log, 275 route, 213, 222 task, 155 task list, 160 Transport control, 77 configuration, 70 Transport domain, 71, 79, 80, 81 configuration, 70 Transport landscape extended, 199 Transport Management enhanced, 206 Transport Management System, 60, 65, 76, 77, 81 alert monitor, 155 authorization, 82 configuration, 210 import monitor, 155 Transport object critical, 87, 191 reporting, 171 Transport Organizer Web UI, 208, 210, 220 Transport request, 122, 131 creation, 156 import, 158 project assignment, 82 registration, 155 release, 158 reporting, 171 Transport routes Transport Management System, 77 Transport strategy, 78 Transport Management System, 78 Trusted RFC authorization, 283 connection, 185 Trusted service, 79, 283

U
Unit test, 202 Upgrade project, 30, 36, 39, 48, 57, 204 Use Change Request Management, 111

296

Index

User SAPSYS, 283 User group partner function, 111, 116 User status, 64, 121, 127, 128 Completed, 131 Confirmed, 131, 132 status profile, 55, 94 test message, 67

Versioning, 275 Virtual system, 269, 271 Visual Administrator, 215

W
Workbench object, 136 request, 126 transport request, 124 Work Center, 53, 76, 117, 118, 121, 175, 179 Workflow, 51 Change Request Management, 29

V
Validating and Testing, 27 Variant SAP0, 277 SAP1, 278 task list, 85

297