Matthias Friedrich, Torsten Sternberg. Change Request Management with SAP. Solution Manager. Bonn Boston

Transcription

1 Matthias Friedrich, Torsten Sternberg Change Request Management with SAP Solution Manager Bonn Boston

2 Contents Preface Introduction IT Change Management and the Information Technology Infrastructure Library Classification of IT Change Management Definition of Concepts Tasks of IT Change Management Success Factors for IT Change Management SAP Solution Manager and the Information Technology Infrastructure Library SAP Solution Manager Functions Support of ITIL Practices Using SAP Solution Manager Change Request Management with SAP Solution Manager Change (Request) Workflows Project Administration Monitoring and Reporting Summary Architecture of Change Request Management Elements of Change Request Management Project Administration in SAP Solution Manager Solution Manager Project Types SAP Solution Manager Projects in Change Request Management IMG Projects and CTS Projects Project Cycle and Task List cprojects Transaction Types/Workflows Service Desk Message Change Request Change Document

3 Contents Normal Correction/Development Activity Urgent Correction Administration Message Test Message Job Request Change Transactions for Projects Summary Configuration of Change Request Management Preparation Organizational Questions Technical Questions Prerequisites Available Documentation and Resources Configuration of Change Request Management Standard Configuration Extended Configuration Defining Projects and Systems in Change Request Management Defining Logical Components Creating a Solution Manager Project Final Check Summary Use of Change Request Management Roles and Activities Requester Service Desk Employee Change Manager Change Advisory Board Developer Tester IT Operator Additional User Information

4 Contents 4.2 Processes and Integration Examples Example of the Urgent Correction Retrofit Process Hot News Structure Elements for Change Transactions Administration Task List Extended Configuration Change Tracking Scheduling Project Logistics Reporting and Monitoring Solution Manager Reporting Transaction Monitor Work Centers Change Management Work Center Configuration of Work Centers SAP GUI for HTML Configuration Summary Security in Change Request Management Authorizations in the SAP System Authorizations in the SAP Solution Manager System Authorizations in Satellite Systems Work Center Extended Authorization Checks Cross-System Object Lock Functionality Required Settings Critical Transport Objects Functionality Required Settings Modifications Project Intersections Real-Life Example Required Settings Summary

5 Contents 6 Extensions of the Change Request Management Scenario Extended Transport Landscapes Three-System Landscape Four-System Landscape Parallel Phase Landscape Landscapes for Global Developments Conclusion Enhanced Transport Management Components TMS Configuration Integration with Applications Landscape Scenarios Integration of CTS+ and Change Request Management Conclusion Extension Developments and Development Package Customer-Specific Tab Defining the Necessary Data Structures Defining the Layout and Flow of the Dynpro Integrating the New Tab via the Screen Control Tabs in the Change Request Inserting the Calculation Logic Extension of the Transaction Monitor Extended Actions and Conditions Extended Check for Text IDs Extended Check for Partner Functions Displaying Transport Requests Summary Change Management in SAP Landscapes Change Management Concept Maintenance Maintenance Optimizer Technical Integration Testing Analysis Quality Management in SAP Solution Manager Functional Scope

6 Contents Prerequisites for Quality Gate Management Summary Technical Notes on Usage and Troubleshooting 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 Urgent Correction Import All Import Subset and Import Project Error Analysis Application Log Reports for Completing Project Cycles Authorization Problems SAP Notes The Authors Index

7 2 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 Upgrade of SAP Solutions SAP Methods and Tools E-Learning Management Test Management Change Request Management Follows ITIL Standards Maintenance Processes Implementation Core Business Processes Optimization Operations Delivery of SAP Services Onsite/Remote SAP Safeguarding Solution Monitoring System Monitoring Business Process Monitoring Central System Administration EarlyWatch Alert Service Level Reporting Solution Reporting Service Desk Best Practices for Incident Management Integration of 3rd-Party Help Desks Solution Manager Diagnostics Safe Remote Access Performance Measurements Logs and Dumps Traces Technical Configuration Figure 2.1 Change Request Management in SAP Solution Manager 33

8 2 Architecture of Change Request Management 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 cprojects cproject SAP Solution Manager Project Test Cases Documentation Training System Landscape SAP Change Manager Task List System and Transport Configuration Transport Tracking Service Desk SN Change Request Management CR CD Transport Management System DEV IMG Project QAS PRD CTS Project CTS Project CTS Project Figure 2.2 Elements of Change Request Management E E 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. EE EE 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. 34

9 Project Administration in SAP Solution Manager 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 Solution Manager Project Types The project types available in SAP Solution Manager are listed below: E E E E E E 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. 35

10 2 Architecture of Change Request Management 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. E E E E E E 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. 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

11 Project Administration in SAP Solution Manager 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. You define a logical component in System Landscape Maintenance 4. (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

12 2 Architecture of Change Request Management 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

13 Project Administration in SAP Solution Manager 2.2 Figure 2.6 System Landscape Project Administration 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 typ es 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 Implementation Project Template Project Upgrade Project Figure 2.7 Recurring and Nonrecurring Projects 39

14 2 Architecture of Change Request Management 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

15 Project Administration in SAP Solution Manager 2.2 SAP Solution Manager Project Cycle Change Transaction Project Cycle Task List Development System Transport Requests Logical System (System and Client) IMG Project CTS Project Q P cprojects Project (Created in cprojects) Solution Manager Project D IMG Project CTS Project Q P D Figure 2.8 Architecture of Change Request Management IMG Projects and CTS Projects As explained above, IMG and CTS projects represent Basis functions and are therefore available in any SAP NetWeaver system. E E E E 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. 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

16 2 Architecture of Change Request Management 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

17 Project Administration in SAP Solution Manager 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 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 proje ct. The other buttons, Assigned CTS Requests and CTS Project Piece List (see Figure 2.12), also display relevant information about transports. 43

18 2 Architecture of Change Request Management 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

19 Project Administration in SAP Solution Manager 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 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 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

20 2 Architecture of Change Request Management 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 Go- Live. 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) Test Project Cycle Emergency Correction Go-Live Development Activity Synchronization Synchronization Synchronization Figure 2.15 Implementation Project, Project Cycle, and Changes 46

21 Project Administration in SAP Solution Manager 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

22 2 Architecture of Change Request Management 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 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

23 Project Administration in SAP Solution Manager 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) Development (without/with Release) Maintenance Cycle Test Emergency Correction Go-Live Normal Correction Synchronization Synchronization Synchronization Urgent Correction (Independent of Maintenance Cycle) Figure 2.19 Maintenance Project, Maintenance Cycle, and Transactions 49

24 2 Architecture of Change Request Management 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 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

25 Transaction Types/Workfl ows 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

26 2 Architecture of Change Request Management 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 Service Desk Message Change Request Normal Correction 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

27 Transaction Types/Workfl ows 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 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

28 2 Architecture of Change Request Management 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 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

29 Transaction Types/Workfl ows 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

30 2 Architecture of Change Request Management 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 (SDCR- HEAD) 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 Correct ion, Urgent Correc tion, and Administra tion. For implementation projects, template projects, and upgrade 56

31 Transaction Types/Workfl ows 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: E E Implementation project, template project, upgrade project E E Development/Development Activity EE Administration E E Maintenance project EE EE EE Normal Correction Urgent Correction Administration The selection menu for change types is shown in Figure 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

32 2 Architecture of Change Request Management accordingly. Figure 2.27 shows the action lis t 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 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

33 Transaction Types/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 Change Documents 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 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. 59

34 2 Architecture of Change Request Management 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

35 Transaction Types/Workfl ows 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

36 2 Architecture of Change Request Management 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. Phase Normal Correction Projects (Implementation, Template, and Upgrade Project) Request Approval In Development Release Finish Development Pass to Test Production Import Created O X X X X X X Development without Release O O O X X X X Development with Release O O O O O O X Test X X X X X X X Emergency Correction X X X X X X X Go-Live X X X X X X O Being Completed X X X X X X X Completed X X X X X X X Figure 2.30 Project Phases and a Normal Correction 62