change request management

Matthias Friedrich, Torsten Sternberg

Change Request Management with SAP Solution Manager

Bonn Boston

261_Book.indb 3 7/8/09 5:01:45 PM

5Contents

Preface ....................................................................................................... 11

1 Introduction .............................................................................. 15

1.1 IT Change Management and the Information Technology Infrastructure Library ................................................................... 151.1.1 Classification of IT Change Management ........................... 151.1.2 Definition of Concepts ...................................................... 181.1.3 Tasks of IT Change Management ....................................... 191.1.4 Success Factors for IT Change Management ...................... 20

1.2 SAP Solution Manager and the Information Technology Infrastructure Library ................................................................... 201.2.1 SAP Solution Manager Functions ...................................... 211.2.2 Support of ITIL Practices Using SAP Solution Manager ...... 24

1.3 Change Request Management with SAP Solution Manager ......... 281.3.1 Change (Request) Workflows ............................................ 291.3.2 Project Administration ...................................................... 301.3.3 Monitoring and Reporting ................................................ 31

1.4 Summary .................................................................................... 31

2 Architecture of Change Request Management ........................ 33

2.1 Elements of Change Request Management ................................. 332.2 Project Administration in SAP Solution Manager ......................... 35

2.2.1 Solution Manager Project Types ........................................ 352.2.2 SAP Solution Manager Projects in Change Request

Management .................................................................... 392.2.3 IMG Projects and CTS Projects .......................................... 412.2.4 Project Cycle and Task List ................................................ 452.2.5 cProjects .......................................................................... 50

2.3 Transaction Types/Workflows ...................................................... 512.3.1 Service Desk Message ....................................................... 532.3.2 Change Request ............................................................... 542.3.3 Change Document ............................................................ 58

261_Book.indb 5 7/8/09 5:01:45 PM

6ContentsContents

2.3.4 Normal Correction/Development Activity ......................... 592.3.5 Urgent Correction ............................................................. 642.3.6 Administration Message ................................................... 652.3.7 Test Message .................................................................... 662.3.8 Job Request ...................................................................... 672.3.9 Change Transactions for Projects ....................................... 67

2.4 Summary .................................................................................... 68

3 Configuration of Change Request Management ...................... 69

3.1 Preparation ................................................................................. 693.1.1 Organizational Questions ................................................. 693.1.2 Technical Questions .......................................................... 703.1.3 Prerequisites ..................................................................... 703.1.4 Available Documentation and Resources .......................... 71

3.2 Configuration of Change Request Management .......................... 723.2.1 Standard Configuration ..................................................... 733.2.2 Extended Configuration .................................................... 85

3.3 Defining Projects and Systems in Change Request Management .............................................................................. 1023.3.1 Defining Logical Components ........................................... 1023.3.2 Creating a Solution Manager Project ................................. 1073.3.3 Final Check ....................................................................... 108

3.4 Summary .................................................................................... 109

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

4.1 Roles and Activities ..................................................................... 1114.1.1 Requester ......................................................................... 1124.1.2 Service Desk Employee ..................................................... 1134.1.3 Change Manager .............................................................. 1134.1.4 Change Advisory Board ..................................................... 1144.1.5 Developer ........................................................................ 1144.1.6 Tester ............................................................................... 1154.1.7 IT Operator ...................................................................... 1154.1.8 Additional User Information ............................................. 116

261_Book.indb 6 7/8/09 5:01:45 PM

7ContentsContents

4.2 Processes and Integration Examples ............................................ 1164.2.1 Example of the Urgent Correction ..................................... 1174.2.2 Retrofit Process ................................................................ 1344.2.3 Hot News ......................................................................... 1404.2.4 Structure Elements for Change Transactions ...................... 142

4.3 Administration ............................................................................ 1484.3.1 Task List ........................................................................... 1484.3.2 Extended Configuration .................................................... 1624.3.3 Change Tracking ............................................................... 1634.3.4 Scheduling ........................................................................ 1664.3.5 Project Logistics ............................................................... 167

4.4 Reporting and Monitoring .......................................................... 1694.4.1 Solution Manager Reporting ............................................. 1694.4.2 Transaction Monitor ......................................................... 171

4.5 Work Centers .............................................................................. 1754.5.1 Change Management Work Center ................................... 1754.5.2 Configuration of Work Centers ......................................... 1794.5.3 SAP GUI for HTML Configuration ..................................... 180

4.6 Summary .................................................................................... 181

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

5.1 Authorizations in the SAP System ............................................... 1835.1.1 Authorizations in the SAP Solution Manager System ......... 1835.1.2 Authorizations in Satellite Systems ................................... 1845.1.3 Work Center ..................................................................... 1855.1.4 Extended Authorization Checks ........................................ 185

5.2 Cross-System Object Lock ........................................................... 1865.2.1 Functionality .................................................................... 1865.2.2 Required Settings ............................................................. 189

5.3 Critical Transport Objects ............................................................ 1915.3.1 Functionality .................................................................... 1915.3.2 Required Settings ............................................................. 1935.3.3 Modifications ................................................................... 194

5.4 Project Intersections ................................................................... 1955.4.1 Real-Life Example ............................................................. 1965.4.2 Required Settings ............................................................. 197

5.5 Summary .................................................................................... 198

261_Book.indb 7 7/8/09 5:01:46 PM

8ContentsContents

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

6.1 Extended Transport Landscapes .................................................. 1996.1.1 Three-System Landscape ................................................... 1996.1.2 Four-System Landscape .................................................... 2016.1.3 Parallel Phase Landscape .................................................. 2036.1.4 Landscapes for Global Developments ............................... 2056.1.5 Conclusion ....................................................................... 206

6.2 Enhanced Transport Management ............................................... 2066.2.1 Components ..................................................................... 2086.2.2 TMS Configuration ........................................................... 2106.2.3 Integration with Applications ........................................... 2146.2.4 Landscape Scenarios ......................................................... 2176.2.5 Integration of CTS+ and Change Request Management ..... 2256.2.6 Conclusion ....................................................................... 227

6.3 Extension Developments and Development Package ................... 2276.4 Customer-Specific Tab ................................................................. 228

6.4.1 Defining the Necessary Data Structures ............................ 2286.4.2 Defining the Layout and Flow of the Dynpro .................... 2326.4.3 Integrating the New Tab via the Screen Control ................ 2356.4.4 Tabs in the Change Request .............................................. 2366.4.5 Inserting the Calculation Logic .......................................... 237

6.5 Extension of the Transaction Monitor .......................................... 2396.6 Extended Actions and Conditions ............................................... 241

6.6.1 Extended Check for Text IDs ............................................. 2426.6.2 Extended Check for Partner Functions .............................. 2476.6.3 Displaying Transport Requests .......................................... 251

6.7 Summary .................................................................................... 255

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

7.1 Change Management Concept .................................................... 2577.1.1 Maintenance Maintenance Optimizer .......................... 2587.1.2 Technical Integration ........................................................ 2607.1.3 Testing .............................................................................. 2607.1.4 Analysis ............................................................................ 261

7.2 Quality Management in SAP Solution Manager ........................... 2617.2.1 Functional Scope .............................................................. 261

261_Book.indb 8 7/8/09 5:01:46 PM

9Contents

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

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

8.1 Adding New Systems .................................................................. 2678.2 System and Client Copy .............................................................. 2688.3 Setting Up a Project Landscape ................................................... 2718.4 Repair Flag for the Import ........................................................... 2748.5 Urgent Corrections in Parallel Systems ......................................... 2758.6 Transports and SAP NetWeaver Business Warehouse ................... 276

8.6.1 Urgent Correction ............................................................. 2768.6.2 Import All ......................................................................... 276

8.7 Import Subset and Import Project ............................................... 2778.8 Error Analysis .............................................................................. 278

8.8.1 Application Log ................................................................ 2808.8.2 Reports for Completing Project Cycles .............................. 2808.8.3 Authorization Problems .................................................... 283

8.9 SAP Notes .................................................................................. 284

The Authors ............................................................................................... 285

Index ......................................................................................................... 287

261_Book.indb 9 7/8/09 5:01:46 PM

33

Architectu2 re 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 Man-agement, you therefore need to understand these elements and how they work. This chapter explains the various functional areas within Change Request Manage-ment and provides an initial insight into how Change Request Management fits into SAP Solution Manager.

Elements of Change Request Management2.1

Change Request Management represents a core functional area within SAP Solu-tion 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.

CoreBusinessProcesses

Impl

emen

tation

Optimization

Operations

Change RequestManagement

Follows ITIL StandardsMaintenance Processes

Service DeskBest Practicesfor Incident ManagementIntegration of 3rd-PartyHelp Desks

Solution MonitoringSystem MonitoringBusiness Process MonitoringCentral System AdministrationEarlyWatch Alert Service Level ReportingSolution Reporting

Upgrade ofSAP Solutions

SAP Methodsand ToolsE-LearningManagementTest Management

Implementation of SAP Solutions

SAP Methods and ToolsGlobal RolloutCustomizing SynchronizationE-Learning ManagementTest Management

Delivery ofSAP Services

Onsite/RemoteSAP Safeguarding

Solution Manager Diagnostics

Safe Remote AccessPerformance MeasurementsLogs and Dumps Traces Technical Configuration

Change Request Management in SAP Solution ManagerFigure 2.1

261_Book.indb 33 7/8/09 5:01:50 PM

34

ArchitectureofChangeRequestManagement2

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 moni-tored. The elements of Change Request Management are illustrated in Figure 2.2.

Project Administration Business Blueprint Configuration Testing

System LandscapeMaintenance

SAP Change Manager

Service Desk Change Request Management

Transport Management System

SN

cProjects

CR CD

SAP Solution ManagerProject

cProject

DEVIMG Project

CTS Project

Task List System and Transport

Configuration

TransportTracking

PRD

CTS Project

QAS

CTS Project

System Landscape

Test CasesDocumentation

Training

SAP Solution Manager

Elements of Change Request ManagementFigure 2.2

Project AdministrationEE 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 Trans-port 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 EE

are to be supported. The systems are defined, connections configured, and vari-ous systems grouped together in logical components as part of System Land-scape Maintenance (see Section 3.3.1, Defining Logical Components).

In Figure 2.2, the SAP Change Manager box represents the functions specific to EE

Change Request Management. These include the task list and the various trans-port tracking options.

261_Book.indb 34 7/8/09 5:01:50 PM

35

ProjectAdministrationinSAPSolutionManager 2.2

The Change Request Management box represents the two main subprocesses EE

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.

Project Administration in SAP Solution Manager2.2

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

Solution Manager Project Types2.2.1

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

Implementation projectEE This project type is used to implement new business processes in an SAP land-scape with SAP Solution Manager. Detailed information about a process can be mapped in the form of a project structure within the project. This infor-mation includes process steps, documentation, test cases, and configuration/customizing.

Maintenance projectEE 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 projectEE 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 pro-cesses, 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 con-figuration that selected areas cannot be modified.

261_Book.indb 35 7/8/09 5:01:50 PM

36


Check-In /Check-Out Functions

Check-in/check-out functions allow you to transfer a live business process from the So-lution 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 defi ned. You then use the check-in function to transfer the changed business process back to the Solution Directory.

Upgrade projectEE Confi guration settings required as part of an upgrade are made in an upgrade project.

Safeguarding projectEE Safeguarding projects are used to analyze and subsequently eliminate the causes of critical situations.

Optimization projectEE 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 briefl y outlined below.

Quick Project SetupFigure 2.3

261_Book.indb 36 7/8/09 5:01:51 PM

37


Transaction SOLAR_PROJECT_ADMIN provides access to central Project Administration .

All existing projects in SAP Solution Manag1. er 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.

Project Administration in SAP Solution ManagerFigure 2.4

If you double-click on a project to select it, a detailed view of that project 2. 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 fi rst 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 informa-tion, such as status values and time values, are optional.

The other tabs, Scope, Proj. Team Member, Milestones, System Landscape, and 3. 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 Manage-ment (see Figure 2.5).

You defi ne 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 defi ne a logical component in System Landscape Maintenance4. (Transac-tion 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, Defi ning Logical Components).

261_Book.indb 37 7/8/09 5:01:51 PM

38


Detailed Information About a Solution Manager ProjectFigure 2.5

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 confi guration 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 trans-ports. Only the transport of Workbench objects cannot be simulated, owing to the cross-client validity of these objects.

Before we discuss the additional confi guration options and information about the System Landscape tab in more detail, we will briefl y 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 specifi ed above. We will then return to the topic of Project Administration in the following sections.

261_Book.indb 38 7/8/09 5:01:52 PM

39


System Landscape Project AdministrationFigure 2.6

SAP Solution Manager Projects in Change Request 2.2.2 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 classifi cations 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 defi ned as recurring because it is always started again after it has been successfully completed. Implementation proj-ects, 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.

Recurring

ImplementationProject

TemplateProject

UpgradeProject

MaintenanceProject

Non-Recurring

Recurring and Nonrecurring ProjectsFigure 2.7

261_Book.indb 39 7/8/09 5:01:53 PM

40


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 situa-tion is different in projects of a nonrecurring nature, such as implementation proj-ects. 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 Manage-ment. 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 infor-mation in the Solution Manager project is stored there. If several logical compo-nents 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 proj-ects. 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 func-tions 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.

261_Book.indb 40 7/8/09 5:01:53 PM

41


Project (Created incProjects)

SAP Solution Manager

Project CycleChange

Transaction

cProjects

Project CycleTask List

IMGProject

IMGProject

DevelopmentSystem

CTSProject

Logical System (System and

Client)

CTSProject

TransportRequests

Q

Q P

P

D

D

SolutionManagerProject

Architecture of Change Request ManagementFigure 2.8

IMG Projects and CTS Projects2.2.3

As explained above, IMG and CTS projects represent Basis functions and are there-fore available in any SAP NetWeaver system.

IMG (Implementation GuideEE ) projects allow you to coordinate customizing activities and save the resulting changes in a project.

CTS (Change and Transport SystemEE ) 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 proj-ects 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).

261_Book.indb 41 7/8/09 5:01:54 PM

42


Maintenance Project with Assigned IMG ProjectFigure 2.9

If you select the IMG Projects tab, the assigned IMG project (CHARM01) is 1. shown. Logical system ST4:200 is assigned to this IMG project . This corre-sponds 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).

If you select the IMG project and click on the Display button, you automatically 2. 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.

IMG Project in the Development SystemFigure 2.10

261_Book.indb 42 7/8/09 5:01:55 PM

43


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.

Next, select the Transp. Requests tab, which is shown in Figure 2.11.3.

Selecting the Transp. Requests Tab in an IMG ProjectFigure 2.11

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).

If you click on the Display CTS project data button, the screen shown in Figure 4. 2.13 is displayed. Here you can see the CHARM01 IMG project and the corre-sponding 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.

261_Book.indb 43 7/8/09 5:01:55 PM

44


The Transp. Requests Tab in an IMG ProjectFigure 2.12

CTS Project DataFigure 2.13

The fi nal screen element to describe in relation to CTS projects is the project 5. status switches . The project status switches for CTS projects allow you to acti-vate or deactivate various properties for the CTS project and for the correspond-ing transport requests. Figure 2.14 shows the project status switches for a CTS

261_Book.indb 44 7/8/09 5:01:56 PM

45


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

Project Status Switches of a CTS ProjectFigure 2.14

If Change Request Management6. 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 fi nd detailed information about confi guration, in particular in relation to the mandatory assignment of requests to projects, in Defi ne Project Assign-ment 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.

Project Cycle and Task List2.2.4

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

261_Book.indb 45 7/8/09 5:01:57 PM

46


In Change Request Management, this basis is provided by the scheduling tool, which is based on the familiar Schedule Manager function for executing and moni-toring recurring tasks. In Change Request Management, the Schedule Manager allows you to execute a variety of operational tasks, including the import of trans-ports 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 proj-ect. Figure 2.15 shows the interaction between a project, project cycle, and the individual phases with the corresponding changes.

DevelopmentActivity

Synchronization

Project Cycle

Synchronization Synchronization

TestGo-LiveEmergency

Correction

cProjects

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

Development(without and with Release)

Implementation Project, Project Cycle, and ChangesFigure 2.15

261_Book.indb 46 7/8/09 5:01:57 PM

47


From a technical perspective, the project cycle, as shown in Figure 2.16, is repre-sented 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 sys-tems 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

ChangeTransaction Task List

Project Cycle of a Solution Manager ProjectFigure 2.16

Task List in Change Request ManagementFigure 2.17

261_Book.indb 47 7/8/09 5:01:58 PM

48


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 differ-ence 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.

ChangeTransaction Task List

Maintenance Project

Maintenance Cyclewith Phases

Maintenance Project and Maintenance CycleFigure 2.18

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 three-month 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.

261_Book.indb 48 7/8/09 5:01:59 PM

49


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 correc-tions, 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, main-tenance 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.

UrgentCorrection(Independent of Maintenance Cycle)

Normal Correction

Synchronization

Maintenance Cycle

Synchronization Synchronization

Development(without/with Release) Test Go-Live

EmergencyCorrection

cProjects

SAP Solution Manager Project (Maintenance Project)

Maintenance Project, Maintenance Cycle, and TransactionsFigure 2.19

261_Book.indb 49 7/8/09 5:01:59 PM

50


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.

cProjects2.2.5

Integration of the Collaboration Projects (cProjects) solution for project manage-ment into Change Request Management represents an optional enhancement. This integration establishes a 1:1 link between a cProjects project and a Solution Man-ager 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 Man-agement 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: Develop-ment 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 exam-ple, 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.

261_Book.indb 50 7/8/09 5:01:59 PM

51

TransactionTypes/Workflows 2.3

cProjects with Maintenance ProjectFigure 2.20

Transaction Types/Workflows2.3

In Change Request Management, various workfl ows are provided to fulfi ll diverse process requirements. These workfl ows are not to be confused with SAP Business Workfl ows. The relevant workfl ows were introduced in Section 1.3.1, Change (Request) Workfl ows. Here, we explain various workfl ows that are used either directly or indirectly in Change Request Management.

From a technical point of view, all of these workfl ows represent various transac-tion types created in the CRM service process transaction (CRMD_ORDER). Trans-action types are documents created in the CRM service process transaction. They can be used to represent a defi ned process fl ow, provided that the relevant Cus-tomizing settings are confi gured. The transactions can be opened and edited in the service process transaction.

261_Book.indb 51 7/8/09 5:02:00 PM

52


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 selec-tion 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

ServiceDesk

Message

ChangeRequest

UrgentCorrection

NormalCorrection

Administration

Test Message

Transactions in Change Request ManagementFigure 2.21

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 subse-quent activities in Change Request Management.

The change request may give rise to various follow-up transactions. These transac-tions 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 Solu-tion Manager. Business partners need to be maintained for the people involved, whereas information must be maintained in the installed base (IBase) for the sup-ported systems. For more detailed information about configuring Change Request Management, refer to Section 4.1.3, Change Manager.

261_Book.indb 52 7/8/09 5:02:00 PM

53


Service Desk Message2.3.1

The default SAP transaction type for the Service Desk message , which has the tech-nical 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 fi nding 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.

Work Center for Incident ManagementFigure 2.22

261_Book.indb 53 7/8/09 5:02:01 PM

54


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 Ser-vice 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.

Creating a Change Request from a Service Desk MessageFigure 2.23

Change Request2.3.2

A change request , which is referred to by the technical name SDCR in Customiz-ing, represents the fi rst subprocess of Change Request Management . Its main role is to document the request and all associated information, which can be classifi ed as required or optional.

261_Book.indb 54 7/8/09 5:02:02 PM

55


Some information is essential to ensure that no errors occur during further pro-cessing of the request in Change Request Management. This required informa-tion includes a description of the request in the text fi eld provided, and informa-tion about the systems and users affected (for example, the change manager). A change type must also be selected. This specifi es 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 specifi ed in the change request includes dates, additional user information, categorizations, and additional textual informa-tion, 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 sta-tus profi le is provided to identify the various steps from the creation of a request to the fi nal decision regarding the change. This status profi le 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.

User Status in a Change RequestFigure 2.24

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

261_Book.indb 55 7/8/09 5:02:02 PM

56


If these status values cannot adequately map your change request process, the relevant status profi le can easily be supplemented or modifi ed. Customers tend to have their own specifi c process for handling a change request . In many cases, vari-ous 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 Profi le

Do not change the standard SAP status profi le. Instead, copy the status profi le (SDCR-HEAD) to the customer namespace. Make any necessary changes in the copied profi le and then assign the new status profi le (for example, ZDCRHEAD) to transaction type SDCR.

The SOLMAN_CM_GENERAL IMG activity similarly advises you to always use an SAP profi le as a template if you want to defi ne your own profi le.

To conclude this section, we need to look again at the transaction type that must be specifi ed 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 traffi c-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 specifi ed in the change request.

Error Message in the Change RequestFigure 2.25

The change type is specifi ed in the Subject fi eld, 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/Workfl ows. 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

261_Book.indb 56 7/8/09 5:02:03 PM

57


projects, the term normal correction is replaced by the term development or develop-ment activity. This change is made only for the purpose of greater clarity because these projects result in new developments rather than corrections. From a techni-cal 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:

Implementation projectEE , template project , upgrade project

Development/Development ActivityEE

AdministrationEE

Maintenance projectEE

Normal CorrectionEE

Urgent CorrectionEE

AdministrationEE

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

The Subject Field in a Change RequestFigure 2.26

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

261_Book.indb 57 7/8/09 5:02:03 PM

58


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

Authorizing a Change RequestFigure 2.27

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 gener-ated depends on the selection made in the Subject fi eld; for example, it may be an urgent correction. Change Request Management then searches for a project or maintenance cycle for the system specifi ed in the change request. If only one proj-ect 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 Document2.3.3

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

261_Book.indb 58 7/8/09 5:02:04 PM

59


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

Change Process

ServiceDesk

Message

ChangeRequest

UrgentCorrection

NormalCorrection

Administration

Test Message

Cha

nge

Doc

umen

tsChange DocumentsFigure 2.28

This clearly indicates once again the general division of the Change Request Man-agement 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, mean-while, 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 Activity2.3.4

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 Man-ager. This is the initial version of this transaction, which can still be used. Enhance-ments of the process and functions have given rise to the new version SDMJ, which is the standard version now recommended and maintained by SAP.

261_Book.indb 59 7/8/09 5:02:04 PM

60


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 re-peat 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 as-surance 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 trans-port 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 develop-ment 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 cor-rection or development is ready for testing, you can navigate directly from the

261_Book.indb 60 7/8/09 5:02:04 PM

61


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.

Normal CorrectionFigure 2.29

If testing is unsuccessful, the status of the change document is reset to In Develop-ment, 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 Chap-ter 8, Technical Notes on Usage and Troubleshooting.

261_Book.indb 61 7/8/09 5:02:05 PM

62


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 trans-ported 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 devel-opment system when the project passes into the Test phase. Any necessary cor-rective 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.

NormalCorrection

Phase Req

uest

App

rova

l

In Dev

elop

men

t

Rel

ease

Fini

shD

evel

opm

ent

Pass

to

Test

Prod

ucti

onIm

port

Created O X X X X X XDevelopmentwithout Release O O O X X X XDevelopmentwith Release O O O O O O X

Test X X X X X X XEmergencyCorrection X X X X X X X

Go-Live X X X X X X OBeing Completed X X X X X X X

Completed X X X X X X X

Projects (Implementation, Template, and Upgrade Project)

Project Phases and a Normal CorrectionFigure 2.30

261_Book.indb 62 7/8/09 5:02:05 PM

63


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 pro-duction system as part of this cycle.

Projects (Maintenance Project)

NormalCorrection

Phase Req

uest

App

rova

l

In

Dev

elop

men

t

Rel

ease

Fini

shD

evel

opm

ent

Pass

to

Test

Prod

ucti

onIm

port

Created O X X X X X XDevelopmentwithout Release O O O X X X XDevelopmentwith Release O O O O O O X

Test O O O X X X XEmergencyCorrection O O O X X X X

Go-Live O O O X X X OBeing Completed X X X X X X X


Maintenance Project Phases and a Normal CorrectionFigure 2.31

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 docu-ment. 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

261_Book.indb 63 7/8/09 5:02:06 PM

64


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.

Urgent Correction2.3.5

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 immedi-ately 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 main-tenance 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.

261_Book.indb 64 7/8/09 5:02:06 PM

65


UrgentCorrection

Phase Req

uest

App

rova

l

In Dev

elop

men

t

Rel

ease

Pass

to

Test

Rel

ease

for

Impo

rt in

toPr

oduc

tion

Prod

ucti

onIm

port

Created O X X X X X XDevelopmentwithout Release O O O O O O ODevelopmentwith Release O O O O O O O

Test O O O O O O OEmergencyCorrection O O O O O O O

Go-Live O O O X O O OBeingCompleted X X X X X X X


Projects (Maintenance Project)

Maintenance Project Phases and an Urgent CorrectionFigure 2.32

Administration Message2.3.6

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 rel-evance 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 cor-rections. 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 Pro-cess, Completed, Confirmed, and Withdrawn. In principle, an administration mes-sage offers the same functionality as a normal or urgent correction. You can navi-gate 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.

261_Book.indb 65 7/8/09 5:02:06 PM

66


Figure 2.33 shows the possible activities in an administration message in the vari-ous phases of the project cycle.

Administration

Phase Req

uest

App

rova

l

In Dev

elop

men

t

Rel

ease

Pass

to

Test

Rel

ease

for

Impo

rt in

toPr

oduc

tion

Prod

ucti

onIm

port

Created O X X X X XDevelopmentwithout Release O O O ODevelopmentwith Release O O O O

Test O O O OEmergencyCorrection O O O

Go-Live O O O OBeing Completed X X X X X X X


All Project Types

Project Phases and an Administration MessageFigure 2.33

Test Message2.3.7

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 correc-tion. If this test is successful, the test message is completed.

261_Book.indb 66 7/8/09 5:02:06 PM

67


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 mes-sage can only be created and changed during the Test phase of a project cycle.

TestMessage

Phase Req

uest

App

rova

l

In Dev

elop

men

t

Rel

ease

Pass

to

Test

Rel

ease

for

Impo

rt in

toPr

oduc

tion

Prod

ucti

onIm

port

Created O X X XDevelopmentwithout Release O X X XDevelopmentwith Release O X X X

Test O O O O OEmergencyCorrection O X X X

Go-Live O X X XBeing Completed X X X X X X X


All Project Types

Project Phases and a Test MessageFigure 2.34

Job Request2.3.8

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.

Change Transactions for Projects2.3.9

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

261_Book.indb 67 7/8/09 5:02:07 PM

68


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.

Summary2.4

This chapter introduced you to the various elements of the Change Request Man-agement 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.

261_Book.indb 68 7/8/09 5:02:07 PM

287

A

ABAP Dictionary objectretrofit, 140

Action, 98, 99, 128, 241definition, 96list, 54, 58, 97, 119, 153profile, 96task list, 160

Activationcross-system object lock, 90log, 76, 137, 146

Administration, 64Change Request Management, 148

Administration message, 56Change Request Management, 52, 55transaction type, 59, 65

Administratorauthorization, 82

Application log, 167, 192, 280Application management, 21Approval, 191, 194

critical transport, 156Architecture, 33, 38Attachment, 127Authorization, 183

extended, 185object, 105reporting, 171role, 183user status, 129, 130

Availability managementITIL, 25

B

BAdICRM_CUSTOMER_H_BADI, 229CRM_DNO_MONITOR, 239CRM_ORDER_AUTH_CHECK, 186SOCM_CHECK_CONDITION, 245

SOCM_PROCESS_ACTION, 252BAdI enhancement

action, 99Basic configuration, 70, 72Basic setting

action, 99consistency check, 100

BCOS_CUST, 189BC set, 76, 101, 134, 136, 145

retrofit, 140Bill of material, 197Browser, 181Build phase, 262Business partner, 94

transaction monitor, 171Business process, 22, 142, 146

Solution Directory, 144Business process and interface monitoring

work center, 175Business Process Change Analyzer, 260Business process monitoring, 23, 142

logical component, 102Business scenario, 22, 146

C

Capacity managementITIL, 25

Catalog, 92Categorization, 112Category, 173Change advisory board, 18, 19, 114

partner function, 111Change Analysis, 261Change document, 59, 61, 178

Change Request Management, 35transaction type, 58work center, 176, 178

Change Management, 113, 257ITIL, 27work center, 175

Index

261_Book.indb 287 7/8/09 5:03:24 PM

288

Index

Change manager, 18, 19, 29, 60, 113, 118, 120, 131, 192, 194

partner function, 111retrofit, 135sample process, 133

Change request, 18, 20, 29, 35, 52, 54, 56, 58, 59, 67, 113, 119

authorize, 120creation, 117hot news, 141management, 74, 99process, 35request for change, 18work center, 176, 177, 178

Change Request Management, 18, 24, 28, 33, 45, 54, 69, 73, 225

configuration, 129logical component, 103process, 59, 60project administration, 30reporting, 170transaction type, 98

Change tracking, 163Change transaction, 47, 67, 117

partner function, 111project cycle, 154task list, 159type, 90, 98

Check, 101reporting, 31task list, 160

Check-in, 146, 148business process, 36

Check-out, 146, 148business process, 36

Check report, 101, 108Client

logical system, 103RFC connection, 105

Client copy, 268Client setting, 162Close coupling, 215Code, 92

group, 92group profile, 92

Completion tasktask list, 149, 159

Componentconfiguration, 71logical, 37, 102, 104, 105, 107, 139, 267, 272

Condition, 98, 241action profile, 97consistency check, 100definition, 243status value, 100

Condition editoraction profile, 98

Configuration, 69, 72extended, 85, 162project, 154Transport Management System, 77work center, 179

Configuration managementITIL, 16, 27

Configuration nodeIMG, 72

Conflict analysis, 187Conflict scenario

cross-system object lock, 89Consistency check, 99, 108

retrofit, 136Context, 146Control function

change manager, 113Copy control, 98, 101Copying control, 251Correction

action, 62, 63Change Request Management, 52, 55change transaction, 48normal, 50, 56, 62, 64process, 116processing, 122synchronization, 159test transfer, 126transaction type, 59, 64urgent, 49, 56, 120, 124, 131, 150workbench, 134, 136, 140

cProjects, 40, 45, 50, 90, 91, 155Critical transport object, 87CRMC_MAP, 229, 231CRMC_MSGC, 243, 248CRMC_MSGS, 244, 248

261_Book.indb 288 7/8/09 5:03:24 PM

289

Index

CRM_CUSTOMER_H_BADI, 229CRM_DNO_MONITOR, 239CRM_ORDER_AUTH_CHECK, 186CTS+, 207, 213, 217, 223, 225

distributed landscape, 220double stack landscapes, 219

CTSDEPLOY, 208CTS project, 40, 41, 43, 83, 126, 159, 160, 161, 163

project assignment, 82CTS Status switch

project logistics, 168Customer, 53Customer namespace

transaction type, 179Customer-specific tab, 228Customizing

global, 206regional, 206request, 126transport request, 124

Customizing distributionlogical system, 102

Cutover, 134, 204, 205Cycle

completion, 160

D

Daily overviewtask list, 153

Data collector, 170, 171Data consistency, 64Date profile, 95Date rule, 95Date type, 95Default configuration, 73Deploy phase, 263Deploy service, 207Deploy Web Service, 208, 209, 217, 221Developer, 60, 114, 135

partner function, 112sample process, 133test message, 66

DevelopmentChange Request Management, 57

number range, 84package, 227phase, 49project cycle, 48status, 130system, 60, 66, 122, 133Transport Management System, 77user status, 128

Diagnosticsroot cause analysis, 175

Dictionary object, 134Display list

transaction monitor, 175Document flow, 52, 120, 131, 160Document management

cProjects, 91Domain controller, 71, 77, 79, 80

ABAP, 208Domain link, 80, 217

transport domain, 80Double stack, 207

landscape, 219system, 210target system, 213

Downgrade, 134, 195Dual-control concept, 20, 115, 128Duration type, 95

E

E-learning, 22, 142material, 143

Enhancement package, 24, 258Enterprise Edition

SAP Solution Manager, 143Error analysis, 278Error solution

ITIL, 25Evaluation

criterion, 169Event management, 26

ITIL, 17Execution option

BC Set, 137Execution time

action, 99

261_Book.indb 289 7/8/09 5:03:24 PM

290

Index

Export check, 193critical transport object, 87

F

Fast entrytext administration, 96

Flow logic, 234Follow-up document, 121, 133Four-level system landscape, 201Functional tester, 115

G

GanttcProjects, 50

Global customizing, 206Global namespace, 206Global template, 205

H

Hot News, 117, 140, 141, 179work center, 176

HP Quality Center, 260HTMLB, 180

I

IBase, 52component, 71

ICF, 179, 180IMG activity, 41, 55, 72, 73

number range, 84IMG project, 107Implementation

documentation, 143lifecycle, 22user status, 130, 132

Implementation and upgradeswork center, 175

Implementation project, 30, 35, 39, 40, 41, 42, 48, 57, 62

Importauthorization, 82error, 155, 274IT operator, 115project, 277subset, 277

Inactive system, 270Incident Management, 16, 17, 26, 52, 113

event management, 26work center, 175

Informationpredecessor/successor, 195

Instance profile, 180Integration test, 66, 115, 202, 204, 268Interface setting

partner determination procedure, 94Internet service, 181

configuration, 180Interval

number range, 84Issue management, 27, 71IT Change Management, 15, 17, 19

monitoring, 20ITIL, 15, 20, 91

change advisory board, 18, 19change manager, 18, 19change request, 18, 20Incident management, 16ITIL V3, 16, 17, 24request for change, 18

IT operator, 60, 63, 115, 129, 130, 148partner function, 112sample process, 133

IT service continuity management, 25ITSM, 15

J

Java stacksystem, 207

Job documentation, 67Job request, 67Job Scheduling Management, 67

work center, 175

261_Book.indb 290 7/8/09 5:03:25 PM

291

Index

K

Knowledge Warehouse, 107, 143

L

Landscapecomponent, 104global development, 205

Layouttransaction monitor, 173, 175

License management, 178work center, 176

Lifecycle, 16, 21, 27project cycle, 46SAP Solution Manager, 33

Lock entrycross-system object lock, 89

Lock information, 189Logical component, 267, 272logical system, 103Logical system, 38, 42, 102, 103, 106Loose coupling, 214

M

Maintenance activities, 258Maintenance cycle, 48, 49, 58, 61, 63, 64, 160

completion, 159retrofit, 138scheduling, 166urgent correction, 117

Maintenance documentation, 258Maintenance landscape, 201, 204Maintenance Optimizer, 258

work center, 176Maintenance planning, 258Maintenance project, 30, 35, 39, 40, 48, 49, 57, 63, 108, 139

number range, 84Maintenance transaction

Maintenance Optimizer, 177Maintenance unit

reporting, 170

Modification, 194critical transport object, 87

Module, 234, 235Monitoring, 20, 169

Change Request Management, 31

N

Namespaceglobal, 206regional, 206

Navigation areawork center, 178

Non-ABAP object, 208, 209Note

implementation, 157Number range, 84, 92

object, 84

O

Objectcritical, 163extended configuration, 162reporting, 31, 171

Object list, 191, 193, 195, 197Object lock

cross-system, 87, 89, 90, 163, 186, 188information, 190scenario, 187update, 191

Object reportingreporting service, 88

Object version, 134Operations

lifecycle, 22Optimization

lifecycle, 24Optimization project, 36Order attribute, 83Organizational Management, 172Organizational structure, 69Organizational unit, 172

reporting, 170transaction monitor, 173

261_Book.indb 291 7/8/09 5:03:25 PM

292

Index

Overtaker, 165Overview

work center, 176

P

Package, 227PAI, 232

module, 235Parallel phase landscape, 203Parallel project, 201, 203Parallel system, 275Parallel system landscapes, 130Parameter transaction, 173Partner determination procedure, 94Partner function, 93, 94, 116PBO, 232, 238

flow logic, 234module, 234

Personalization filterwork center, 175

Phasechange, 151control, 150, 151Controller, 160, 273maintenance cycle, 160project cycle, 64, 68, 108, 151, 160

Phase landscapeparallel, 203

Phase valuecProjects, 50project cycle, 46, 68

Planningproject logistics, 168

PortCTSDEPLOY, 208

Postprocessingassignment, 156retrofit, 137system, 138, 139

Preparationconfiguration, 69

Preproduction system, 202Priority, 112, 178

transaction monitor, 173Problem management, 17, 26, 27, 113

Process, 116Process documentation, 143Processor

current, 116, 128partner function, 112

Process step, 22Production

user status, 129Production manager, 116

partner function, 112Production system, 49, 61, 62, 64, 133, 134, 138

Transport Management System, 77Profile generator, 137Profile parameter, 180Project

Change Request Management, 102parallel, 201, 203work center, 176

Project administration, 28, 30, 34, 107, 149, 154, 162

SAP Solution Manager, 37Project analysis, 163, 165Project assignment, 82, 163Project category

scheduling, 166Project cycle, 30, 40, 46, 50, 58, 61, 67, 108, 148, 152, 273

administration message, 66complete, 280completion, 159

Project headerreporting, 170

Project intersection, 195Project landscape, 204

setup, 271two-level, 134

Project lead, 63, 147Project logistics, 167Project monitor

logistics, 168Project phase

project cycle, 68Project planning

cProjects, 91Project status switch

CTS project, 44

261_Book.indb 292 7/8/09 5:03:25 PM

293

Index

Project structurelogistics, 168

Project type, 35, 39

Q

Quality assurance system, 49, 60, 63, 128, 133Quality gate, 263Quality Gate Management, 178, 258, 261

phases, 262Quality Management, 261Quality manager, 263Query

work center, 176

R

Regional customizing, 206Regional namespace, 206Regression test, 200Release, 138Release landscape, 201Release management, 17, 27, 258Release manager, 114Release package, 27Repair flag, 274Report

work center, 177Reporting, 169

Change Request Management, 31SAP Solution Manager, 28service, 87, 88solution-independent, 177

Report on side-effects, 260Request

own, 125Request analysis

change tracking, 165Requester, 112, 118, 131

partner function, 111sample process, 133

Request for changechange request, 18

Result listreporting, 170

Retrofit, 130, 134, 137, 156, 204function, 130object, 137process, 134, 135, 138system, 135, 136, 137, 138

RFC connection, 80, 81, 89, 104, 105, 139, 158

configuration, 75RFC destination, 81, 104

configuration, 75Role, 174

Change Request Management, 111cross-system object lock, 89type, 155work center, 179

Role maintenancework center, 76

Root cause analysis, 23, 24, 175

S

Safeguarding project, 36Sample process, 133Sandbox system, 201SAP Basis, 40SAP Business Workflow, 51SAP Download Manager, 259SAP EarlyWatch Alert, 23, 25SAP GUI, 178, 179

for HTML, 178, 179, 180, 181setting, 179

SAP infrastructure, 21SAP NetWeaver, 40SAP NetWeaver Application Server, 71SAP NetWeaver Business Warehouse

transport, 276SAP NetWeaver Development Infrastructure, 215SAP NetWeaver Portal, 215SAP NetWeaver Process Integration, 215, 216, 223SAP note, 284SAP product

system landscape maintenance, 104

261_Book.indb 293 7/8/09 5:03:25 PM

294

Index

SAP Service Marketplace, 72SAP Solution Manager, 22, 25, 27, 28, 30, 37, 40, 52, 59, 107, 175

application, 117application management, 21change document, 35configuration, 179Diagnostics, 261enterprise edition, 143implementation, 22ITIL, 20lifecycle, 21operations, 22optimization, 24reporting, 169root cause analysis, 23scheduling, 166solution monitoring, 23task list, 34workflow, 29

SAP support organization, 53SAPSYS, 283SAP Transport Management, 206SAP Tutor, 72, 116SAP variant

task list, 167Satellite system

Transport Management System, 76Schedule condition

action profile, 97Schedule Manager, 46, 85, 86

task list, 47Scheduling, 166

analysis, 165project logistics, 168task, 153

Scope phase, 262Screen control, 235Security Guide, 183Selection criterion, 171

transaction monitor, 171Sequence violation

overtaker, 165Service delivery

work center, 175Service Desk, 23, 29, 71

change request, 117

employee, 113message, 53, 58, 67partner function, 111sample process, 133SAP Solution Manager, 53transaction type, 52

Service level, 23Service-level management, 25Service-level reporting, 23Service lifecycle, 24Service process

monitor, 171, 173Service process transaction, 51, 54, 55, 56, 141

CRM, 117, 118Setting

scenario-specific, 73Side effect, 260Single transport

transport strategy, 78SMSY_SETUP, 272SOCM_CHECK_CONDITION, 245SOCM_PROCESS_ACTION, 252Software lifecycle, 142Software Lifecycle Manager, 259Software status

change tracking, 164Sold-to party, 116, 118

partner function, 112Solution

database, 26reporting, 170

Solution Directory, 35, 142, 143, 144, 146, 147, 257Solution landscape and operations setup

work center, 175Solution monitoring, 23Solution reporting, 23, 170

service level, 23Source system, 138Split screen editor, 136SPPFCADM, 253Stakeholder, 18Standard profile

configuration, 92Start condition

action profile, 97

261_Book.indb 294 7/8/09 5:03:25 PM

295

Index

Statustransaction monitor, 172

Status displayretrofit, 135

Status management, 94Status profile, 55, 94Status property, 98

profile, 94Status switch, 151Status value

administration message, 65status profile, 55transaction monitor, 172

Steering committeechange advisory board, 114

Structure element, 142, 144Subject, 56, 120

profile, 92Subject area, 173Support Desk

logical component, 103Support package, 24, 258

import, 158System

add, 267inactive

change request management

Documents

change management

change request workflows

sap solution manager

change transactions

change document

sap solution manager

solution manager project

job request