SAP Standard for Change Control Management

Transcription

1 SAP Standard for E2E Solution Operations Document Version: SAP Solution Manager 7.1

2 Typographic Conventions Type Style Example Description Words or characters quoted from the screen. These include field names, screen titles, pushbuttons labels, menu names, menu paths, and menu options. Textual cross-references to other documents. Example EXAMPLE Example Example <Example> Emphasized words or expressions. Technical names of system objects. These include report names, program names, transaction codes, table names, and key concepts of a programming language when they are surrounded by body text, for example, SELECT and INCLUDE. Output on the screen. This includes file and directory names and their paths, messages, names of variables and parameters, source text, and names of installation, upgrade and database tools. Exact user entry. These are words or characters that you enter in the system exactly as they appear in the documentation. Variable user entry. Angle brackets indicate that you replace these words and characters with appropriate entries to make entries in the system. E X A MPLE Keys on the keyboard, for example, F2 or ENTER SAP SE or an SAP affiliate company. All rights reserved. Typographic Conventions PAGE \*

4 1 SAP Standards for E2E Solution Operations Control Center Approach Overview of the Change Request Management Types of Change Release and Deployment Management Defining a Release Strategy Basic Architecture Tools for Managing Changes Tools for Increasing Business Flexibility Integration with Application Lifecycle Management Lifecycle of Change Control Management Plan Project-Related Aspects Organizational Aspects Technical Aspects Change Control Management Processes Build Solution Manager Landscape Functional Implementation Authorization Concept Testing, Bug Fixing, and Retesting Developing Templates in Complex System Environments Run Plan Build Run Optimize Optimize Method Monitoring and Reporting Driving Continuous Improvement Quality Assurance Tasks Quality Targets and KPIs Training Expert Guided Implementation Sessions Setup Support by SAP More Information SAP SE or an SAP affiliate company. All rights reserved.

5 1 SAP Standards for E2E Solution Operations IT organizations face new challenges every day as they attempt to remain effective and future safe while also keeping costs for day-to-day operations as low as possible. They are also being challenged more than ever to demonstrate their value to businesses. Therefore, it is important to optimize the day-to-day tasks that have less obvious business value and to use KPI and benchmark-based reporting to make IT processes more visible, demonstrating the real value that IT can provide. In order to minimize the costs of IT, it is necessary to standardize and automate IT processes end-to-end (E2E) without reducing the SLAs required by the business, such as stability, availability, performance, process and data transparency, data consistency, IT process compliance, and so on. Based on the experience gained by SAP Active Global Support (AGS) while serving more than 36,000 customers, SAP has defined process standards and best practices to help customers set up and run E2E solution operations for their SAP-centric solutions. The Build phase of SAP best practices supports a Build SAP Like a Factory approach, consisting of the following processes: Custom code management Change, test, and release management Incident, problem, and request management Solution documentation Remote supportability During the Run phase of a solution, adapting your IT infrastructure to a Run SAP Like a Factory operation impacts both application operations and business process operations. Therefore, operations processes, such as technical monitoring, end-to-end root-cause analysis, technical administration, and data volume management need to be optimized to achieve state-of-the-art application operations. In business process operations, the same applies to business process and interface monitoring (including performance optimization), data consistency management, and job scheduling management. Quality management processes and tasks need to be established throughout the lifecycle to guarantee continuous improvement of the end-to-end operations processes while simultaneously ensuring the flexibility needed to react to changing requirements SAP SE or an SAP affiliate company. All rights reserved. 5

6 Figure 1: Organizational model for solution operations This figure shows an organizational model for solution operations that aligns SAP best practice topics and E2E standards with SAP's control center approach. The Operations Control Center executes and controls the Run SAP Like a Factory processes, while the Innovation Control Center ensures optimal custom code management and a smooth transition to production with integration validation procedures. SAP connects to these control centers from the Mission Control Center to ensure that professional support is available to the customer. The following Application Lifecycle Management (ALM) functions are not provided directly in one of the control centers because they must be handled across different areas: Change, test, and release management Incident, problem, and request management Solution documentation Remote supportability The quality management methodologies are an essential part of SAP's Advanced Customer Center of Expertise (CoE) concept and ensure that the KPI-driven processes are continuously improved across all processes and teams. In addition, the quality manager roles ensure consistent and value-centric reporting to the business and management. This unified reporting platform is known as the Single Source of Truth. 1.1 Control Center Approach The Operations Control Center (OCC) is the physical manifestation of the Run SAP Like a Factory philosophy. The OCC allows for automated, proactive operations, which simultaneously reduces operational costs while increasing the quality of IT services, leading to improved business satisfaction. The OCC also drives continuous improvement of business processes and IT support. To achieve these goals, it relies on a close interaction with both the Innovation Control Center (ICC) and the SAP Mission Control Center (MCC) SAP SE or an SAP affiliate company. All rights reserved.

7 Figure 2: Interaction Between ICC, OCC, and MCC The OCC is a central IT support entity at the customer site, which monitors the productive SAP environment as well as important non-sap applications. During operation, the OCC requires a workforce of 2 full-time equivalent (FTE) per shift to ensure that incidents are detected and resolved as quickly as possible. The OCC is equipped with large screens that display the status of business processes, IT landscape components, as well as exceptions and alerts. If problems occur, you use a video link to get live support from SAP and partners. The customer usually sets up the room with assistance from SAP Active Global Support (AGS). The customer is responsible for managing the OCC and the team of technical and functional IT operators who act on the alerts. The OCC is most effective when closely integrated with other IT processes, such as IT Service Management (ITSM) and Change Management. Central monitors and dashboards based on application and business process operations display the current status of business and IT-related processes. This data can also be used to drive continuous improvement. An effective system monitoring and alerting infrastructure is fundamental to the success of an OCC SAP SE or an SAP affiliate company. All rights reserved. 7

8 Figure 3: OCC Concept The OCC is most effective when closely integrated with other IT processes, such as IT Service Management (ITSM) and Change Management. Central monitors and dashboards based on application and business process operations display the current status of business and IT-related processes. This data can also be used to drive continuous improvement. An effective system monitoring and alerting infrastructure is fundamental to the success of an OCC. For Job Scheduling Management, the OCC supervises all background monitoring processes, SAP controls and legacy background operations. It reacts to job monitoring alerts according to predefined error-resolution activities, and triggers follow-up activities for error handling if the relevant task are not completed within a certain timeframe SAP SE or an SAP affiliate company. All rights reserved.

9 2 Overview of the SAP Standard for Change Control Management In SAP Solution Manager, Change Control Management provides a number of tools for implementing and maintaining company-wide change control management processes. In addition, best practices for change and transport management within your organization help you to implement a well-defined process flow conforming to industry standards, such as the IT Infrastructure Library (ITIL). The Change Control Management portfolio in SAP Solution Manager consists of a number of tools, including Quality Gate Management, Transport Execution Analysis, Retrofit, and Change Request Management. It is designed to handle a wide range of tasks, providing everything from a technical overview of the Change and Transport System (CTS) to a full workflow-driven change management solution. The change management process is divided into two major areas in SAP Solution Manager, namely Change Control Management and IT Service Management. While Change Control Management deals with the technical aspects of change management, IT Service Management focuses more on the process-oriented and organizational aspects of making changes to your SAP solution landscape or any other part of your IT environment. The Change Request Management tool combines both of these areas. It is integrated into the technical environment of the CTS and provides a sophisticated process layer for running change processes and release and deployment processes within SAP Solution Manager. This document focuses on using Change Request Management to implement the best practices for E2E Change Control Management. For more information on other tools, see Basic Architecture. 2.1 Change Request Management SAP Solution Manager offers a set of preconfigured change management processes that you can set up with the help of a guided configuration procedure. Based on this ready-to-use configuration, you can adjust the tools to meet your individual business requirements. You can adapt workflow settings, service organization, user roles, automatic notifications, UI adoptions, and reporting capabilities. In addition, SAP Solution Manager offers many features as standard, for example, authorization management, different inbound and outbound channels, a post-processing framework, and an enhancement workbench for making adjustments to individual fields without the need for manual coding. One of the major benefits of this solution is that you can integrate it into the SAP environment and use it with deployment tools to help automate change processes across your SAP and non-sap landscape. Due to its open interfaces, you can integrate Change Request Management into non-sap technologies. The following table contains an overview of the main tasks related to Change Request Management and the features provided by SAP Solution Manager to support these tasks: 2014 SAP SE or an SAP affiliate company. All rights reserved. 9

10 Tasks Features Create, process, and review requests for change Sophisticated approval management Clearly defined responsibilities for each change phase Assess, evaluate, and authorize changes Close integration with release and deployment management Authorize and coordinate creation, testing, and implementation of changes Ability to create reports as follow-up documents from individual incidents and problems Review and confirm changes Integration with SAP Project and Portfolio Management (PPM) and Test Management Billing and chargeback based on actual effort Change Request Management uses the following types of transaction: Requests for Change Requests for change are created to request changes to your software or a company system, for example, an enhancement or to a function. End users and key users create requests for change to fulfill completely new requirements. If a change is necessary due to an incident or problem, service desk employees can also create requests for change. When creating the request for change, the requester provides information about the change, for example, impact, urgency and priority, category, required end date, and the affected system. Either a Change Manager or a Change Advisory Board checks, evaluates, and verifies this information based on predefined guidelines and then either rejects or approves the request for change. Change Documents After change approval, the system automatically creates a change document, which documents the activities of the users that are involved in the change process, for example, developers, testers, and system administrators. Everyone involved in the process is assigned a specific key task. The following table shows a list of roles and their key tasks: Role Change Managers Developers Testers System administrators Key Task Oversee the process Implement the change Verify the change Transport the change into the production environment As Change Request Management is so closely connected to backend systems, SAP Solution Manager triggers some processes automatically. In general, the process for Change Request Management is as follows: 1. The developer creates the transport request in the development system. 2. The change is handed over to the tester or a test team. 3. In the background, the change is transported to the quality assurance system. 4. After successful verification, the change can be transported to the production system by the system administrator SAP SE or an SAP affiliate company. All rights reserved.

11 Figure 4: Interaction Between Requests for Change and Change Documents Types of Change The type of change you want to implement influences when you import the change into the production system. The ITIL defines the following types of change: Change Type Preapproved changes Normal changes Emergency changes Description Standardized changes that occur regularly with limited risks and defined impacts. They are executed based on simplified guidelines and workflows and can go live whenever they are ready. Changes that are not too complex or urgent. They require good coordination and appropriate approval steps before they can be transported to the productive environment. Different normal changes are combined in a single release, which needs to pass several testing levels before it is imported into the production system at a well-defined point in time to decrease the impact on end users. Highly urgent changes to resolve serious issues that affect a high number of users or important service processes. You execute this type a change according to shortened workflows combined with high-level management supervision. The workflows in Change Request Management are based on procedures described by the ITIL. In addition to the workflow that supports executing a request for change, there are also workflows that help you to make the change itself. Workflows are available for the following changes: 2014 SAP SE or an SAP affiliate company. All rights reserved. 11

12 Emergency changes in SAP systems Periodic changes in SAP systems Administrative changes General changes Troubleshooting during integration testing Release and Deployment Management Change Request Management also contains features to support release and deployment management. The tool differentiates between the following main types of release: Releases related to SAP components Custom releases that can be assigned and related to any type of configuration item that has been defined in the system SAP Solution Manager also contains a project management suite that enables you to control and manage all release-related activities in detail. The following table contains an overview of the main tasks related to release and deployment management and the features provided by SAP Solution Manager to support these tasks: Tasks Features Create and process change documents Control your project phases, such as release and go-live, by using a task list Update the status of previous records, such as requests for change, problems, or incidents, following a successful change Deploy SAP-based changes (ABAP, Java) across your SAP landscape by using the Change and Transport System (CTS, ccts, and CTS+) Advanced CTS functionalities, such as Transport of Copies, which minimizes the number of transport requests, or Transport Collection, which groups together all changes belonging to one request for change Integration with SAP Project and Portfolio Management (PPM) Integration with Test Management (assigning test plans or test packages) Solution Manager Requirements and Release Management (for SAP MaxAttention customers only) Defining a Release Strategy Systems, configurations, and infrastructure changed frequently within companies, for example, due to legal changes or economic conditions. These changes can cause planned or unplanned interruptions in applications and business processes that cannot always be foreseen in heterogeneous and complex system landscapes. Therefore, Release Management has to minimize the risk of disruption to business processes when changes to the production systems are performed. This also reduces costs. There are many reasons for disruptions, but they are most often the result of insufficient planning or testing in the development system SAP SE or an SAP affiliate company. All rights reserved.

13 Release Management teams manage a high number of changes and aim to ensure that releases are implemented in the correct sequence. To avoid conflicts between releases, you need to define, plan, develop, test, and set all project requirements appropriately. There are two types of release. Major Release A major release takes three to six months. In a year, customers develop between two and four major releases. These releases include all types of changes, even those that affect core business processes. Therefore, a major release requires complete regression testing that goes above and beyond normal release testing. Minor Release A minor release has a substantially shorter duration of between one to four weeks. The goal of minor releases is to bundle bug fixes and minor enhancements, then move them to the production system at short-notice. For a minor release, testing is limited to the core business processes and the extensions provided. By following SAP's release management recommendations, you can achieve the following benefits: The frequency of changes in the production system is reduced. Imports into the production system occur at a predefined point in time. End user satisfaction is increased due to early communication and training. Each change is tested appropriately. Daily changes are restricted to emergency fixes. The risk of inconsistencies due to missing transports or transports imported with sequence violations is reduced. The administrative effort for transports is reduced when you import changes using SAP Solution Manager SAP SE or an SAP affiliate company. All rights reserved. 13

14 2.2 Basic Architecture Figure 5: Change Control Pyramid The change control pyramid shows how the different functions of SAP Solution Manager help support the change control management process. This section provides a brief overview of how you can use these tools and features to implement effective change control management processes. For more information on how they can be used to support Application Lifecycle Management, see Change Management and Application Lifecycle Management Process. You can seamlessly integrate Change Request Management into the change processes on any managed systems. In SAP Solution Manager, you can centrally create and release transport requests, and import them into subsystems. For all changes to ABAP stacks, you can integrate the system into the Change and Transport System (CTS). For changes in Java-stack systems, such as SAP Portal, or dual-stack systems, such as SAP Business Warehouse (BW), you have to configure the Enhanced Change and Transport System (CTS+) in the managed system landscape. Change Request Management also interacts with this infrastructure. You can even use it to manage non-sap environments, for example, AS Tools for Managing Changes Central Change and Transport System You need SAP Solution Manager Support Package 10 to access the central Change and Transport System (ccts). With this feature, you can cluster several system landscapes, which enables you to model system dependencies using the Transport Management System (transaction STMS). Example You cluster all of your landscapes according to system role, for example, one cluster for all development systems, one cluster for all quality assurance systems, and one cluster for all production landscapes. This enables you to manage cross-system changes, for example, when a certain requirement leads to changes in an ERP and BW system that need to be deployed at the same time. SAP Solution Manager and ccts ensure that both transports are synchronized in one change document SAP SE or an SAP affiliate company. All rights reserved.

15 Transport Analytics and Configuration Validation To measure the success of your Change Control Management implementation, you must be aware of every change that has been performed across your system landscapes. Transport analytics and configuration validation help you to view any changes to your system landscape and the related information. Transport analytics provide information about imported transport requests, compare the number of released and imported transport requests, and display any overtakers and imports with errors. In addition, you can see how long has been spent on the quality assurance system, which enables you to estimate the time spent testing and the efficiency of your tests. Configuration validation enables you to compare the current system configuration with a reference system configuration. The reference system configuration usually represents the system in a stable state. When an application becomes unstable, it can be compared with the reference system to identify changes that were performed between when the system was stable and the current state. Retrofit In addition to basic three or four-tier system landscapes, you can separate the development and maintenance landscapes to enhance the stability of the production system. This is known as a dual landscape. In dual landscapes, maintaining synchronization between the maintenance-production and development landscapes is essential in order to avoid overwriting maintenance changes when the project is transported to the production system. However, the time and effort spent synchronizing the landscapes often makes this option unappealing. Retrofitting the changes can help to synchronize your landscapes by automating the process as much as possible. SAP customers report around 85% to 93% of their objects can be automatically or semi-automatically imported using retrofitting. Objects that have been changed in the maintenance-production landscape but not in the development landscape can be automatically retrofitted. If the same object from the maintenance-production landscape has already been changed in the development landscape, you can decide which version to keep using SAP correction workbench. For objects that are not connected to the correction workbench, you need to perform the retrofit manually. Cross-System Object Lock If cross-system object lock is active, whenever you make a change in a managed system, an entry is made in the cross-system object lock table in the central SAP Solution Manager system. This entry contains information about where the object was changed, when it was changed, as well as other details such as the transport request number, transport number and object ID. This lock entry prevents changes being made to this object in any other transport requests. If a user tries to change a locked object, an error message is displayed. The lock is only removed when the changes are transported to the production system. This helps prevent overtakers in large landscapes or when working on parallel projects. You can use cross-system object locking either on its own or in conjunction with retrofitting. Quality Gate Management You can use Quality Gate Management (QGM) to manage changes in a heterogeneous system landscape. A project acts as the central entity and is divided into several phases by quality gates. By default, each project comprises four phases: scope, build, test, and deploy. If a change passes a quality gate, for example, because of certain authorizations and by applying the four-eyes principle, background activities are performed. For example, when a change passes the gate between the build and test phases, all changes are transported from the development to the quality assurance landscapes. Using Quality Gate Management, you can import these changes simultaneously for all landscapes in the project SAP SE or an SAP affiliate company. All rights reserved. 15

16 Change Request Management You can use Change Request Management to develop, manage, and optimize your change processes, including change execution. The Change Request Management tool actually supports the entire change management lifecycle from initiating the change to processing it and implementing it as part of release and deployment. Specifically, you can use it to manage the following processes: Initiating, documenting, and authorizing requests for change Viewing change impact analyses Approving or rejecting requests for change Monitoring and reporting on the implementation Deploying changes Tools for Increasing Business Flexibility Change Request Management offers many different ways of checking requests for change and change documents across various system landscapes. Different workflows enable you to fix bugs quickly and efficiently in production landscapes or to develop completely new features in a release project. SAP Solution Manager provides several functions that allow you to be more flexible when dealing with changes. Downgrade Protection Caution Before implementing any other tools mentioned in this chapter, you must have set up downgrade protection to ensure that your system is not accidentally downgraded. When you are working in a flexible and changing environment, changes often appear in different projects with different levels of urgency. The downgrade protection function tracks objects in transport requests, and reports conflicts in five scenarios when an object that is saved in two or more transport requests is released, reassigned, or imported. This applies to all managed development systems and clients for which the cross-system object lock is active, and the Change and Transport System plug-in is installed. Downgrade protection ensures that you do not downgrade your system. This means that you keep your test and production systems consistent. If you are working with flexible release management, you can keep your releases and their deployment consistent. This ensures a more stable production environment. In combination with a cross-system object lock, downgrade protection provides protection at every stage of a technical change. Preliminary Import If you cannot delay the development go-live until the full release, you can process a normal change separately so that it is imported immediately, irrespective of the full release. You can access preliminary import from the process flow of a normal change. The normal change is treated in the same way as an urgent correction. It is first imported separately from the other developments and the relevant transport requests are then kept in the import buffer of the production system so that you can run a consolidated import at the time of release SAP SE or an SAP affiliate company. All rights reserved.

17 Reassignment of Change Documents You may find that you cannot complete an enhancement in time, especially when implementing projects. As implementation projects have no recurring lifecycle, you perform checks to prevent a project from being completed until all transports have been implemented. As of SAP Solution Manager SP05, you can choose to delay the project, undo a specific change, or reassign a change document from one project to another. During a reassignment you can check whether the target project is being run in the same landscape. In SAP Solution Manager 7.1 SP05 to SP09, you can only reassign change documents with unreleased transport requests. As of SP10, you can reassign change documents with released transport requests and use the central Change and Transport System (ccts). Decoupling and Coupling Transport Requests When working in project cycles that have different phases, you may have to remove individual transport requests from the cycle or reassign transports to new change documents because of changing parameters from the business processes or incomplete developments. Change Request Management provides features to change the assignment of transports before the project is released, giving you the maximum flexibility with your releases and allowing you to perform detailed checks on transport requests. 2.3 Integration with Application Lifecycle Management You can integrate Change Request Management into a broad range of features and systems. Change Request Management comprises all of the integration scenarios shown in the following figure: Figure 6: Change Request Management Integration Scenario The following example outlines the interaction between IT Service Management (including Change Management) and Application Lifecycle Management SAP SE or an SAP affiliate company. All rights reserved. 17

18 Example 1. SAP Solution Manager monitors your company s business processes and its entire system infrastructure. You configure SAP Solution Manager to automatically generate an alert if one of your KPIs reaches a predefined threshold (Event Management). 2. The alert generates a dedicated incident record because you have integrated IT Service Management (ITSM) into your solution. 3. In SAP Solution Manager, a service desk employee uses ITSM to process this incident report and you perform a detailed root cause analysis with the help of other SAP Solution Manager applications and functions, such as trace, change, or exception analyses. You can then consider its relevance to other objects (Impact Analysis). 4. To examine the cause of the alert in more detail, the service desk employee creates a problem record from the incident report. This is created as a follow-up document. 5. This problem is forwarded to the Problem Management team, who are trained to further investigate the problem. 6. You integrate the Problem Management process into SAP support message processing (SAP collaboration). From here, you request support from SAP Active Global Support (AGS). 7. SAP AGS provides an SAP Note as a solution for your issue, which is ready to be implemented with the help of SAP Note Assistant. However, as this leads to a change in the production system, you create a request for change from the problem record (Change Management). 8. After the change has been approved, it is implemented in the development system and transferred to the production system (Deployment Management). 9. The incident record states which business process is affected by the change. You use this information to identify an appropriate test case using Solution Documentation. 10. You test the business process that is affected by the change either manually or automatically (Test Management). 11. The problem and incident records are closed and a knowledge article is generated. You use knowledge articles to document the solution method for the problem. If the same problem occurs again in another system you can access the knowledge article and fix the problem quickly and efficiently (Knowledge Management) SAP SE or an SAP affiliate company. All rights reserved.

20 3 Lifecycle of Change Control Management 3.1 Plan In this phase, you have to consider all of the aspects that might affect the implementation process. This is important because you need to perform the implementation in the same way as you would a project. The following chapter provides guidance on how to plan your implementation and fulfill the prerequisites Project-Related Aspects It is important to clarify the general aims for implementing Change Control Management in your company. For this you should apply both "as is" and "to be" analyses. You need to define the scope of the project, including which change management processes and functions should be deployed. At first, you will probably not need all of the processes or tools with specific functions. You need to identify business-critical core services and processes and focus on them. Think about what kind of project you intend to run. For instance, you might consider a rapid deployment solution if you are running a pilot or proof-of-concept or you might want to run a full implementation using a phase-based approach with well-defined milestones. The kind of project you are running also affects how you proceed with any subsequent planned activities. You need to start defining priority-based work packages and schedule required time frames for finishing them, calculate the effort, and plan your assets according to resources and capabilities. The following table lists examples of these factors: Factor Examples Resources Available staff Budget Current or planned infrastructure Access to information Existing applications Capabilities The structure of your organization Management responsibility Current documented processes and knowledge You need to evaluate which part of your IT landscape needs be covered by Change Control Management. You also have to decide if you need to include non-sap applications as well. The main difficulties in doing this are organizing and standardizing current live processes and ensuring cooperation between all stakeholders. You need to consider the following high-level work packages: Analysis of functional and organizational requirements Blueprinting and preparation of functional specifications Hardware setup SAP SE or an SAP affiliate company. All rights reserved.

21 Implementation (prerequisites, basic configurations, customizing, and migration) Preparation of master data (users, organizational units, technical systems, and authorizations) Preparation of documentation (configuration documentation, user manuals, and test cases) User and administration training courses Testing (functional tests, integration and acceptance tests) Bug-fixing Planning and preparation for go-live Performing go-live Project management Organizational Aspects In addition to the project-related aspects, you have to examine any organizational aspects. It is important to identify critical functions, roles, and responsibilities. Document this in a responsibility assignment (RACI) matrix and prepare a communication plan. This means that you have all the necessary contact details in place. You need to clearly assign all project members to the change management project and ensure that they are available for the duration of the project. First, you need to make sure that all project members have a general understanding of Change Control Management. If your staff are preforming the implementation, you need to train them appropriately. SAP offers several training courses and knowledge sources for this purpose. For more information, see Training and More Information. You can also get support from external resources responsible for various project-related activities such as project management, implementation, or development, for example, from the SAP Customer Center of Expertise (CoE). The Customer CoE improves transparency and quality management, aiming to resolve critical challenges across SAP Solution Operations. The CoE program provides information, methodologies, and tools to help you improve quality checks and continuously improve SAP Solution Operations. It verifies the processes that customers implement to perform these activities and ensures that the process is compliant with the SAP Standards for E2E Solution Operations. Be aware of any disagreements between your departments or employees regarding changes. In order to be successful, you need to have the acceptance and support of your management staff, affected process owners, and stakeholders. You also have to consider work spaces and grant access to buildings or other necessary areas for external employees during an on-site engagement Technical Aspects When planning an implementation of Change Control Management, you need to consider the following technical aspects: Hardware Sizing When sizing your hardware for Change Control Management, you need to consider the following KPIs: 2014 SAP SE or an SAP affiliate company. All rights reserved. 21

22 Number of documents (request for change, change documents) created per day Number of low activity users (10 dialog steps per hour or less) Number of medium activity users (2 dialog steps per minute, approximately) Number of high activity users (10 dialog steps per minute or more) Workdays per year, according to company policy When scaling your dedicated hardware, you need to consider the following KPIs: Average number of concurrent users during peak times Average number of queries per user in one hour Average number of high and medium connectors per query Total number of files to be loaded Total number of business objects to be loaded Number business objects increase per year For more information, see the SAP Solution Manager 7.1 Sizing Toolkit at Sizing SAP Solution Manager Configuration Before starting your Change Control Management implementation, you need to complete the System Preparation, Basic Configuration, and Managed System Configuration scenarios of SAP Solution Manager Configuration (transaction SOLMAN_SETUP). Master Correction Note and Change Request Management Master Note Make sure that the latest version of the Master Correction Note is implemented according to your SAP Solution Manager support package stack level. Check for updates regularly to ensure that bug-fixes are implemented. For every support package, there is also a Change Request Management Master Note which contains known bugfixes and the corresponding SAP Notes that solve this issue. You need to update this SAP Note regularly. System Access You need to grant system access, including Internet access or internal network connection, to everyone involved in the configuration in both SAP Solution Manager and the managed systems. In addition, do not forget to prepare SAP Solution Manager system users, including user names and passwords, with sufficient authorizations for all involved stakeholders. Requesting authorization objects can be time consuming and laborious during the implementation phase. If SAP staff are involved in the implementation, it is crucial that you enable the remote SAP R/3 and HTTP connection from SAP Service Marketplace to SAP Solution Manager. Change Control Management Process Implementing and customizing actions are stored in dedicated transport requests as workbench and customizing requests. Therefore, you need to think about your Change Control Management process for the implementation project. SAP recommends that you bundle all Change Control Management transports in one CTS project. SAP Connect You need to configure SAP Connect (transaction SCOT) to send s according to defined actions within IT Service Management SAP SE or an SAP affiliate company. All rights reserved.

23 Text Retrieval and Information Extraction To enable full-text searches within requests for change and change documents, you need to set up the Text Retrieval and information Extraction (TREX) search engine Change Control Management Processes Change Control Management processes require specific planning and design activities before you can start the implementation. Existing Processes You need to review all process documentation, for example, process flow diagrams or descriptions, particularly those relating to requests for change and change processes and check if you need to make any modifications. You use this documentation as a basis for the implementation. You must work with all process stakeholders, including the process owner, process manager, and practitioners to define process descriptions. In addition, you need to make sure that all of these stakeholders have been added to the RACI matrix and the communication plan. Functions Check whether your specific functional requirements are covered by SAP Change Control Management. You might find it helpful to build a requirement matrix to analyze whether key features are covered fully, partly, or not at all. You can also easily document necessary developments here. Later, you need to track any effort spent implementing key functionalities, such as customizing or development, in the project plan. You need to analyze the following core features: Automatic notifications in case of status changes Multilevel categorization Structure of your organization Support Organization You can build the basic structure of your individual support organization in SAP Solution Manager. You have to analyze and define the structure for your specific organization. You can base your structure on any kind of organizational structure. You can then assign team members, for example, developers, testers, system administrators, or change managers, to these teams. Setting up your support organization enables you to use several features in Change Request Management. For example, you can notify the responsible team via when a request for change has been automatically dispatched to this team or when the search filter for change records assigned to the team becomes applicable. Authorization Concept You must identify all user groups working with Change Control Management and define the related authorization roles. Documenting and setting an authorization concept is not simple and must be carefully considered. SAP Solution Manager allows you to define many authorization objects, for example, to view and use different UI components, set the visibility of text types, apply specific workflow statuses, or create and modify requests for change and change records SAP SE or an SAP affiliate company. All rights reserved. 23

24 3.2 Build Once you have completed the plan phase, you can begin to implement your solution. You need to make finance, IT, and personnel resources available from the start of the build phase. You must have set up a system landscape with a minimum of two systems for development and production. If you are performing a completely new implementation, you can use a sandbox environment. After implementing and successfully testing the sandbox, you can copy it to construct a maintenance landscape. After preparing the system and performing a basic configuration of SAP Solution Manager, you need to complete a configuration for managed systems. The following chapter provides guidance on how to implement your change management process Solution Manager Landscape SAP recommends that you set up a three-tier system landscape with a development, quality assurance, and production system. You begin your change management implementation on the development system. After finishing the implementation, you have to transport the changes to the quality assurance system which you use to run test cases. After a successful test, you can transport the Change Control Management implementation to the production system and activate it. Continuous improvements, for example, developments, implementing new features, bug fixing, and upgrades, should only be introduced in the development system. This protects your production environment against any unconfirmed and unsuccessfully tested changes. Figure 8: Recommended Three-Tier System Landscape If for any reason you cannot set up a three-tier landscape, you must establish at least a two-tier landscape for SAP Solution Manager. In this case, you use the non-productive system for both the pilot project implementation and for testing SAP SE or an SAP affiliate company. All rights reserved.

25 Figure 9: Two-Tier System Landscape You have to connect the non-productive SAP Solution Manager systems and the non-productive managed systems to the productive SAP Solution Manager system. You can use one of the following connection types: Connection via trusted RFC between productive and non-productive SAP Solution Manager systems Connection via trusted RFC between productive SAP Solution Manager system and managed systems TMW and READ RFC between productive SAP Solution Manager system and managed systems To evaluate change processes, it is essential that you set up an environment to create transport requests for testing purposes. You have several options for this. The following examples are typical options used by customers: Option 1: Separate Clients on Solution Manager Development or Quality Assurance System 2014 SAP SE or an SAP affiliate company. All rights reserved. 25

26 Figure 10: Example Environment Option 1 The three clients represent a classic three-tier system transport landscape. With these additional clients you can simulate your change processes by using customizing changes. Option 2: Separate Clients on Managed System Figure 11: Example Environment Option 2 The three clients in this scenario also represent a classic three-system transport landscape. With these additional clients, you can simulate your change processes by using customizing changes. The advantage compared to option 1 is that you have RFC connections throughout the system between SAP Solution Manager and the managed system Dual Maintenance In addition to the classic three or four-system landscapes in which maintenance and project developments are performed in parallel in the same track, more and more customers are splitting these activities by creating a separate track for implementation projects with a cycle longer than 3 months. This enables you to focus on emergency and minor changes, which can be tested independently from ongoing developments for major releases, in the maintenance track. Major releases can be tested more precisely in a stable environment before they are sent to the maintenance landscape. You need to implement a preproduction system, particularly if you are developing parallel releases because you have to test one release in isolation before transferring it to the maintenance landscape. Import from the project to the maintenance landscape is called the cutover SAP SE or an SAP affiliate company. All rights reserved.

27 You need to make changes to customizing and workbench objects if you use the production system to perform maintenance activities. These changes must be synchronized with the project landscape to avoid downgrading objects which were changed during the cutover process. This synchronization is supported within SAP Solution Manager using the retrofit function. For more information, see Tools for Managing Changes. Figure 12: Dual Landscape Parallel Development Note It is important to note that the there are also negative aspects to running parallel system tracks. Using a parallel development landscape can cause the following problems: Extra administration activities must be performed Extra retrofit activities that cannot be performed using tools must be preformed Additional cutover planning is required You must implement advanced security functions, such as downgrade protection or cross system object lock, to avoid overwriting or downgrading your systems, especially when you perform development activities that take place in several development systems. Any changes that are separate from workbench or customizing are stored in a central table in SAP Solution Manager SAP SE or an SAP affiliate company. All rights reserved. 27

28 If an object is changed multiple times, a warning or error message is raised depending on the central system object lock configuration. A warning message allows developers the option of continuing with the change, but this increases the risk of creating a downgrade. An error message is more restrictive. You need to evaluate customer requirements precisely to identify the best method, as different options are available. For example, you might decide to have multiple project changes return an error message while emergency changes only return a warning. When working with parallel development and projects two kinds of problems can occur: Object Conflicts Figure 13: Object Conflict In this scenario, the same objects are contained in different projects. The project that is imported last overwrites the objects in the other project. Therefore, the project that was imported first may no longer work after you have imported the second project. Object Dependencies Figure 4: Object Dependencies In this scenario, objects in different projects reference each other. For example, a program in project 1 calls an object included in project 2. If only one of the projects is imported into another system, it will fail. This problem is called cross-reference inconsistency. Object dependencies are not recognized by the cross-system object lock. Solutions To fix cross-referencing inconsistencies, you have to use a preproduction system. If the preproduction system's software and configuration are up to date, you can detect and fix the error in preproduction provided that you perform an isolated test of the project releases in the preproduction system. SAP recommends the following actions to avoid object dependencies: SAP SE or an SAP affiliate company. All rights reserved.

29 The responsible development teams estimate potential collisions (objects changed differently in several projects) before a project starts o If no collisions are expected, projects can run in parallel. o If collisions are expected, projects should be run in sequence or handled as one common project. o If possible, several small projects should be bundled into one big project with a single go-live date. Working with parallel projects requires a rigorous governance and process control. Ideally a quality manager should be responsible for checking collisions and defining workarounds. You need to implement the following procedures to mitigate the risk of undetected collisions: Release transport requests later to keep the object locked Lock objects that are identified as potential collisions in a dummy transport Put objects that are identified as potential collisions into the critical objects list Move long-running projects into separate environments Clearly assign transport requests to their project, either by using a CTS projects or by using a naming convention for the short text of the transport requests Functional Implementation The start point for your Change Control Management implementation is the Change Request Management scenario of SAP Solution Manager Configuration (transaction SOLMAN_SETUP). This includes a guided configuration procedure containing everything you need to do to set up Change Request Management. Figure 5: SAP Solution Manager Configuration for Change Request Management In addition to SAP Solution Manager Configuration, you can find advanced implementation activities and documentation in the Solution Manager Implementation Guide. To find this, in SAP Customizing, Execute Project (transaction SPRO) choose SAP Reference IMG SAP Solution Manager Implementation Guide SAP Solution Manager Capabilities (Optional) Change Request Management SAP SE or an SAP affiliate company. All rights reserved. 29

30 Adapting Change Management Workflows When you have completed the Change Request Management basic configuration, you can adapt the workflow for requests for change and change documents according to business needs by customizing dedicated transaction type profiles. You can use the BAdIs provided by SAP to enhance the processes. The web-based user interface can be adjusted using the Web UI configuration mode or the Application Enhancement Tool. Master Data Before you can create or process change records, you must prepare the master data. The master data contains the following objects: System User Business Partner Organization IBase-Components Multi Level Categorization Logical Components Business Partners In SAP Solution Manager, business partners guarantee effective and easy communication between all employees involved in change processes. All relevant information relating to business partner can be accessed from a central location. If you have a business role with the appropriate administrative authorizations, for example, SOLMANPRO, you can create individual business partners manually in SAP Solution Manager. In general, however, business partners are migrated from connected SAP systems with background processing. The report copies all or selected users (including their addresses) from other systems and generates all the necessary business partner functions in SAP Solution Manager, for example, contact, employee, or general. In addition, you can generate an SAP Solution Manager Login User and assign a template authorization role to the user. You can make the relevant settings in the implementation guide for SAP Solution Manager. Which part of a process the business partners are involved in does not matter. For example, a single employee can function as both a requester and tester. Therefore, you can use SAP Solution Manager to assign a business partner different roles and relationships to other business partners. In the standard configuration shipped by SAP, some partner functions have already been defined. The following table shows examples of some predefined business partners and their functions: Role Requester Change Manager Function Creates the request for change Approves or rejects the request for change Gives the authorization for production import of urgent changes Developer Tester Current Processor Implements the change Verifies the provided solution on quality assurance system Is the employee currently responsible for the change document SAP SE or an SAP affiliate company. All rights reserved.

31 Role IT Administrator Function Triggers the import into subsequent systems. The organizational schema in General Attribute Change tool (transaction PPOMA_CRM), must be up to date and accurately display the organization of the change department. You use this tool to define the various levels and assign employees to the various groups of experts. This is a prerequisite for activating automatic rule determination that finds a responsible group within your change organization based on document characteristics, for example, document category. IBase and Logical Component To use Change Control Management scenarios in SAP Solution Manager, you must first define the installation (IBase). You must create an IBase component for each component system used during the change process. Therefore, IBase components represent managed systems in your landscape. In a standard system, IBase components in SAP Solution Manager are managed in the SOL_MAN_DATA_REP installation IBase structure (installation 1) and are updated automatically when changes are made in the Landscape Management Database (transaction LMDB). A logical component is an administrative entity, which assigns logical systems to the system roles or phases in a project, system landscape, and across projects. System Settings and Transport Routes In addition to the connections between SAP Solution Manager and the managed systems, you also need to perform the following tasks on the managed systems in Transport Management System (transaction STMS): Activation of Extended Transport Control Activation of TMS Trusted Services Set up a single transport and no delivery after confirmation transport strategy. You also need to set up the following two transport routes. Route Transport layer Description Create a transport layer for your development client. A transport layer is assigned to each development class and to all objects in that class. The transport layer determines in which SAP system developments or changes to repository objects are made and where these objects are transported. Delivery route Create a delivery route from your quality assurance client to your production client. SAP Solution Manager Project SAP Solution Manager projects specify which landscape changes are performed. Logical components assigned to an SAP Solution Manager project represent the landscape. On the managed system, the SAP Solution Manager project is represented by an IMG project in the development system and by a CTS project in the development client. Transport requests created in Change Request Management for a specific SAP Solution Manager project are automatically assigned to this CTS project to enable you to distinguish between ongoing, parallel projects. The following figure illustrates SAP Solution Manager project architecture: 2014 SAP SE or an SAP affiliate company. All rights reserved. 31

32 Figure 15: Project Architecture Authorization Concept You have already created your authorization concept for your Change Control Management solution during the Plan phase. During the Build phase, you begin to create the user profiles for dedicated change management user groups. SAP provides predefined authorization composite-roles for each user group, which include individual roles for the entire change management process and each feature. For more information about implementing an ALM authorization scenario, see the Security Guide for SAP Solution Manager on the Service Marketplace at SAP Components SAP Solution Manager Release 7.1 Operations Testing, Bug Fixing, and Retesting Test packages with test plans must be available to perform an integration test that covers the entire change process together with other integration scenarios and systems. SAP provides tools for test management processes. These help you to store test sources for central access. For more information, see the SAP Standard for Test Management. Any issues are then sent to the relevant Change Request Management expert for correction. Bug fixing and retesting activities usually require a lot of time so you need to plan them carefully. In addition to testing activities performed on the demo landscape, you should perform a test on a real landscape, such as ERP, if possible. To do this you need to perform the following tasks: Set up RFC-connections and logical components Apply the necessary system settings on the landscape Create a Solution Manager project on the productive SAP Solution Manager system Execute any non-critical changes to verify that the change workflows also work in a true-to-life environment SAP SE or an SAP affiliate company. All rights reserved.

33 3.2.5 Developing Templates in Complex System Environments The release and project management concept of Change Control Management provides a structure to separate different types of changes. By using different project types as implementation or maintenance, changes within the same landscape can be separated and controlled individually. In combination with a dual landscape, an implementation landscape can be used to provide a template version of an application which will be distributed once or on a regular basis into one or more parallel maintenance landscapes. Supporting standards, such as the SAP Standard for Solution Documentation, can be used to define the business processes including configuration data and test cases. A template project function allows you to generate an individual implementation project when you roll out the application into one of the parallel landscapes. In addition, you can define, within the project, which objects can be changed locally. If an object is globally defined, you cannot locally change objects. Functions, such as retrofit, can be used to synchronize the template development with maintenance changes performed in a roll-out landscape. 3.3 Run After a successful integration test, you have to prepare and perform the transition phase. The production system is then ready for you to import Change Request Management transport requests. You have to perform any preprocessing activities before import, including, loading master data. During import, the SAP basic team and Change Request Management implementation team need to be available to fix import errors immediately. After importing Change Request Management transport requests, post-processing tasks are performed. This ends the transition phase. Change Control Management is an important solution across an organization. Therefore, you must inform all involved and affected partners about the implementation of the new processes. Ideally, you have provided training sessions before production usage starts. Your support organization must be ready to handle requests from end users, such as developers and testers. You should have a single point of contact to bundle different inbound channels for incidents that are caused by the new Change Control Management solution. During service operation, process owners have to monitor different change management aspects, including performance and feedback from end users. Change Request Management offers different reporting features that enable you to analyze the state of your implementation at any given time. You can make emergency modifications to your solution during maintenance activities to fulfill the change management process SLAs that you defined during the Plan phase. You perform any additional modifications or improvements, including implementing new features as part of Optimize phase. Change Control Management is not just one part of ALM, but plays a role across all phases of an application's lifecycle. Therefore, it is important to maintain a holistic view and understand how Change Control Management supports each of the Plan, Build, Run, and Optimize phases in the lifecycle of an application. The following sections provide an overview of a running Change Control Management implementation through each of the phases of the application lifecycle SAP SE or an SAP affiliate company. All rights reserved. 33

34 3.3.1 Plan The plan phase can be divided into the following sub-phases: Requirement: List the requirements for an application Design: Create a detailed specification for these requirements Requirement Sub-Phase In this sub-phase, you need to consider what kinds of changes need to be made. This decision will be based on your individual application. You might want to implement a completely new application or adapt an existing one. You need to differentiate between major changes, minor changes, and bug fixes, as this allows you to define the effort and impact associated with a change. You can document requirements by using either of the two following tools: IT Service Management provides the service request and incident features, which allow you to document incidents and problems. Change Request Management provides the request for change feature, which allows you to document any requirement that will lead to a change. Each of these features can be interlinked and used in a predefined way. For more information on ITSM, see the SAP Standard for IT Service Management. With Change Request Management, you can create a request for change as either a follow-up document for an incident or service request, or as a new document. For example, you can state the following information for the change: Detailed description Priority Impact Timeline Affected system This enables you to precisely document the requirement and describe the planned or requested change. Design Sub-Phase In this sub-phase, you need to create a detailed specification for any requirements identified in the requirements phase. You have to consider how to analyze and approve a change. You add details about the requirement to a request for change. In addition to the basic information, you have to add information describing the impact of the change on other business processes or systems. If the business processes are described within SAP Solution Manager, you can link related processes to the change management documents. You can also use multi-level categorization to specify the request in detail. Assigning an approval procedure enables you to define the approval workflow, which means you can set the following restrictions regarding your change approval process: Type of user Number of users Workflow sequence In a project assignment, you can determine in which context this change should be processed. According to the change type that you defined in the requirement phase, you can perform this change in either a maintenance or implementation project. The project assignment does not just define the context in which the change will be performed; it also lists the possible ways of transporting the change from the development system to the production system because each project has an individual timeline SAP SE or an SAP affiliate company. All rights reserved.

35 You can also link requests for change to a project in SAP Project and Portfolio Management (SAP PPM). This will exchange any relevant data between the request for change and the project. You can use this feature to reduce the workload of your project managers, as you can always clearly see the status of the request for change in the request for change project management environment. Effort stated in the request for change document is automatically synchronized to the corresponding PPM project. Caution Any changes that you make can affect multiple systems. To define the scope of your change, you can use a separate assignment block to maintain systems and clients on which changes need to be performed. You can then process the complete request for change. In addition to providing a definition for each system, you need to define which process should be followed to process the change on that system. You can define changes according to different categories. The following table describes the possible categories: Type Normal Change Urgent Change General Change Admin Change Use Standard changes Time-critical changes Changes that have no impact on a system, for example, changing a printer Changes in systems that you do not manage with the Transport Management (TMS), for example, a number range change If you have any external documents that help to specify a required change, these documents can be attached to the request for change. Instead of uploading the document, you can add a URL to the document. The SAP Standard for Solution Documentation describes how business processes can be documented in SAP Solution Manager. You can also add information to these business processes, for example, configuration documentation, development documentation, test cases, or user guides, and establish a link to a business process or document from the process repository in SAP Solution Manager. By doing this, you can reuse existing information to provide further details in the request for change You then need to decide if a change can be moved forward to the Build phase. Depending on your specific approval procedure, one or more people, for example, the Change Manager, need to give approval. Once the approval has been granted, the request for change will switch to the approved status, which enables you to move it to the follow-up process. This follow-up process is documented and controlled in a change document. The request for change is linked to the change document and information is copied from the request for change into the change document when the change document is created Build The build phase can be divided into the following sub-phases: Build: Process all data collected during the plan phase, and make the change in the development system Test: Verify this change in the development or quality assurance system 2014 SAP SE or an SAP affiliate company. All rights reserved. 35

36 Build Sub-Phase After you have identified and recorded all data relating to the change, you have to use this data to process the change itself. In Change Request Management, you use the change document to support this process. The change document itself is defined by the request for change. In the change document, you should store information about the following topics: System Client Specification Timeline Priority A developer processes the change document by setting an appropriate status, for example, In Development, and performs the change in the system or client indicated by the request for change. The developer can use functions in Change Request Management to present information and create a transport request from a change document on the managed development system. In addition, the developer can access the managed system by using the links provided in the change document. Functions such as a cross-system object lock can be used to support the Build phase by ensuring that only one person can work on certain objects at any given time. This ensures data control and consistency, especially in major projects or across several parallel projects. Changes to configuration can be documented in documents attached to the change document, including by copying them from a request for change, or documents linked via URL or a business process link. However, Change Request Management does not just document the workflow and all of its details. Integration with Transport Management System (transaction STMS) allows direct access to TMS functions from inside the change document. For example, you can create transport requests from managed systems. You can also export and import changes in managed systems. Status values indicate the progress of a change document right up to when you import it into the production system. After finishing the development, the change is ready for testing. Test Sub-Phase Once the change has been developed, you have to verify it in the development or quality assurance system. You can use different types of tests, for example, regression, integration, user acceptance, or performance, to do this. You can very closely integrate change request management with test management. You can link a test to your change in the request for change. This means, you can reuse test cases stored and used in test management. You can also use all of the functions available in test management to verify a change before moving it to the production system. Test cases can be rated after execution. If the test case is linked to a change, this result is shown in the change document and can be used to move forward or backwards if necessary Run The run phase can be divided into the following sub-phases: Deploy: Implement the change Operate: Manage the change as a project SAP SE or an SAP affiliate company. All rights reserved.

37 Deploy Sub-Phase Changes which have been tested successfully can be moved into production by using Change Request Management functions. A task list provides various functions for verifying and moving a project through the system landscape to the final production system. Importing a project into the production system ensures data consistency and guarantees that changes belonging to the same project are made consistently. You can use transport management to manage changes in complex system landscapes that use a different technological basis. CTS+, for example, allows you to manage non ABAP changes, such as Java or.net. Data consistency is a major topic across all ALM phases. Complex system landscapes and different activities in multiple projects, which might be performed in parallel, require strict control and documentation. You can use the concept of release management in combination with various functions in Change Request Management to do this. After successfully deploying your change, it becomes part of the live IT landscape. Operate Sub-Phase Different IT services ensure that business operation is not disrupted or that impact is minimized when changes need to be performed to the live landscape. You have to manage any change during the Run phase in the same way you would manage a project. A request for change defines the change, for example, as a hot fix or planned maintenance. You then assign this request for change to a project. You use maintenance projects to manage changes. These act as a baseline for Change Request Management support during the Run phase. A request for change contains all of the information required to approve a change. When approval is given, you use a change document to create any follow-up processes. You then use this as a basis for making the change. It is important for you to define the type of change. The urgent change type is particularly important during this phase. As all changes are managed like a project, you have to follow a project timeline. The urgent change process allows you to create and transport one change into the production system. This means you can move an urgent fix to the production system quickly and still follow and apply the Change Request Management guidelines. Monitoring and reporting functions help to identify and manage requests for change. You can raise these requests for change either directly or, more likely, as a follow-up process to an incident or service request made in ITSM Optimize The optimize phase can be divided into the following sub-phases: Analyze: Investigate and asses how well the change has dealt with any related problems. Improve: Use this information to identify how changes could be better implemented in the future. Analyze Sub-Phase To verify the data consistency within the IT landscape, you can use transport analytics to analyze changes you have already transported. This means that you can not only identify what has been transported using functions like Change Request Management or Quality Gate Management but you can also identify changes that were not transported to every system or changes that have been in a system for a long time. As any of these issues can lead to inconsistencies between systems, you need to be aware of them. The configuration validation function allows you to compare systems to ensure that they have, for example, the same software component level or the same type of system setting. You can also compare which SAP Notes are implemented in which system SAP SE or an SAP affiliate company. All rights reserved. 37

38 Improve Sub-Phase Once you have identified improvements, you can use them as requirements to start the cycle over again, beginning with the plan phase. You can also use the optimize phase to upgrade your systems, implement new software components, make changes to system settings, or add support packages. 3.4 Optimize The following chapter provides a method for identifying and applying aspects of your current Change Request Management implementation that could be improved. SAP Solution Manager provides features to help you do this Method An ideal method for implementing your Change Request Management is the Deming cycle. This is also called a Plan Do Check Act (PDCA) cycle. It is an iterative four-step management method used in business to check and continuously improve processes and products. The following table describes the aims of each step of the cycle: Step Plan Do Check Act Aim Prepare a project plan and a functional specification to establish the objectives and processes necessary to deliver results in accordance with the expected output. Execute the activities defined in the project plan and functional specification, and implement Change Request Management. Testing the implementation by executing your prepared test cases. Study the results and compare them to the expected results in the functional specification. Make corrective actions, for example, bug-fixing, where required, and highlight and eliminate significant differences between the implementation and the functional specification. Adapt new requirements, if necessary. After your Change Request Management implementation is complete, it reaches a level of stability called the baseline. This stable working configuration is then the starting point for the next iteration of the cycle. Performing the cycle a second time enables you to learn more about your implementation and make further improvements SAP SE or an SAP affiliate company. All rights reserved.

39 Figure 6: Deming Cycle You then consider the following activities when defining a starting point for the next plan phase: Implementing SAP Notes Implementing a new version of the central correction note Updating to a new support package stack level Implementing new features Meeting new requirements Automating manual activities ITSM monitoring and reporting Monitoring and Reporting SAP Solution Manager offers various reporting and monitoring capabilities, which help you to improve your change management processes Web UI Online Monitoring The Web UI Online Monitoring enables you to create snapshots of current change management records. An end user can define custom searches based on the concatenation of multiple parameters. These searches can be stored for later usage and shared with a broad range of users. You can also export the results list as an Excel spreadsheet and perform an advanced analysis of the data. You can apply a variety of filters to your analysis. The following parameters are the most useful for improving change management processes: 2014 SAP SE or an SAP affiliate company. All rights reserved. 39

40 Filter Category Text Ratio of Normal and Emergency Changes Use Filtering by category can be a useful way of measuring the effectiveness of your categories. If you find that people are assigning categories to changes, then your organization is using them effectively. If you find many records with non-specific or no categories, you may need to redefine your categorization schema. If users are not using categories effectively, it is more difficult and less beneficial to process new documents and search for previous solutions Filtering by ratios of changes can be a useful way of measuring the effectiveness of your application as a whole. A large number of emergency changes implies that your change management team has to continually apply quick changes in order to restore working systems. If you find that there are more emergency changes, you need to make appropriate adjustments to ensure that downtime is minimized. These two categories are examples and you can use many filters to come to a range of conclusions. However, further investigation is often required to get to the root of the issue. Note Concatenating multiple filter criteria provides valuable information for your specific scenario ITSM Business Warehouse Reporting You use ITSM BW Reporting to analyze historical data. The responsible analyst can select any period of time for reporting purposes. You can export the results in form of an Excel spreadsheet and perform an advanced analysis of the data. With ITSM BW Reporting, you can track the following KPIs: Average processing time Time recording analysis Workload Total amount New documents Status iteration analysis SAP SE or an SAP affiliate company. All rights reserved.

42 4 Driving Continuous Improvement 4.1 Quality Assurance Tasks You need to have a defined quality assurance procedure to make sure that you can continually improve your solution. When developing your procedure, consider the following tasks: Track the number of closed changes (periodically), changes executed as planned, and the number of failed transports Track Change Advisory Board (CAB) approval trends Ensure transport requests can be mapped to change requests Review the quality of change process, including, documentation, and the success of Incident Management and Transport Management integration Ensure the documentation, including the Operations Handbook, is updated following changes Analyze emergency changes to assess their urgency Determine the risk of emergency changes (sharpen Business awareness) Select suitable test cases (Change Impact Analysis) Include business-related operations personnel in test execution and signoff Report on management decisions to skip quality gates (correlate with occurring issues) 4.2 Quality Targets and KPIs To assess the quality of the Change Control Management process, you need to set clearly-defined parameters and measurable objectives. Key parameters should be collated and evaluated with regular reporting. The historical data that is created in this way can be used to identify trends and develop ways to improve your application. The following targets are important to ensure the maturity of your control management process and drive value recognition: Speed up responsiveness to business requirements Improve transparency and auditability for business compliance Reduce poorly controlled emergency changes to increase business continuity Reduce change-related effort by automating tasks and improving performance The following table describes the main challenges for each of these quality targets and which KPIs can be used to measure them: Target Challenges KPIs Speed up responsiveness to business requirements Speed up change request procedure Ensure sufficient information is Average time spent for approval (classified by priorities) SAP SE or an SAP affiliate company. All rights reserved.

43 Target Challenges KPIs provided Predict the impact of business requests on systems Number of delayed change approvals per quarter (classified by priorities) Percentage of requests for change confirmed or accepted by your organization Average time from request for change to implementation (classified by priorities) Number of routing activities between your organization and the IT department before requests for change are accepted Improved transparency and auditability for compliance Make legal and regulatory requirements transparent and auditable Set up Change Control Management processes and a central overview of processes, approvals and dependencies appropriately Percentage of unauthorized implemented changes Percentage of implemented changes without impact analysis Number of incidents related to transport errors, for example, missing transports or sequence errors Trend measured by time and effort for audit preparation Trend in numbers, for re-work items due to objections raised by auditor Increased business continuity by improving emergency changes Synchronizing and checking changes across platforms based on different types of technology Ensure that changes do not conflict with each other in projects of maintenance activities Percentage of changes that cause incidents Number of emergency changes Percentage of unplanned outage or unavailability due to changes Avoid disrupting ongoing business Reduce the number of emergency and failed changes Reduced effort by automation and better performance Deal with high manual effort when transporting to ABAP or a Java stack Apply expert knowledge Effort for testing measured in percentage. Effort should decrease, while the number of changes should be reduced SAP SE or an SAP affiliate company. All rights reserved. 43

44 Target Challenges KPIs Test systems manually and thoroughly Costs for change adoption in percentage. Trend in time spent for error analysis and production down situations FTE involvement in transports Percentage of unplanned outage/unavailability due to changes Percentage of effort to administer SAP SE or an SAP affiliate company. All rights reserved.

45 5 Training For implementing Change Control Management, SAP offers the following training courses: E2E200 E2E Change Control Management This course covers the following topics: Solution Documentation: o Introduction of System/Solution and Business Process Documentation in SAP Solution Manager Change and Transport System: o SAP NetWeaver development environments o Transport of Non-ABAP objects via Enhanced Change and Transport System Reporting and Analysis Tools/CTS Analytics o CDMC CTS Analysis for Risk Mitigation of transporting of new custom code before go-live o Impact analysis with the business process change analyzer and reporting on current system configuration o Configuration validation to compare multiple systems and using Transport Execution Analysis Self Service o Control Dashboard to control recent changes Software Change Strategies: o SAP best practices for transport landscape topologies and release strategies o Transport Management with SAP Solution Manager: o Project usage in SAP Solution Manager for Transports o Cross system object lock functionality o Retrofit Quality Gate Management: o Administration and grouping of transport requests into logical units o Controlling the quality of an implementation project at certain quality gates. Change Request Management: o Approval process including demand consolidation, prioritization, categorization and scheduling of changes o Tool based workflow for the execution of change requests from development to production Test Workbench Integration o Maintenance Management o Support packages and enhancement packages o Use cases of Maintenance Optimizer and System Recommendations in SAP Solution Manager SM200 IT Service Management Configuration This course covers the following topics: Overview of Change Request Management and Application Incident Management 2014 SAP SE or an SAP affiliate company. All rights reserved. 45

46 Basic setup steps for Application Incident Management and Change Request Management Master data Projects in Change Request Management The Application Incident Management process and its integration with Change Request Management The Change Request Management processes Monitoring Customizing IT Service Management 5.1 Expert Guided Implementation Sessions For Enterprise Support Customers, SAP offers Expert Guided Implementation Sessions (EGI). Expert Guided Implementation (EGI) sessions are a combination of remote training, live configuration, and ondemand expertise, which allow you to perform complex activities with the help of experienced SAP support engineers. The instructor will demonstrate what to do step by step. Afterwards, you can perform the relevant steps in your own version of SAP Solution Manager. If you have any questions, you can then contact an SAP expert via phone or . For Change Management the following EGIs are available: CTS+ (4 days) Quality Gate Management (4 days) Change Request Management Basic (4 days) Enhanced Change Request Management (3 days) More information regarding the content of the EGIs and time schedule can be found at the EGI calendar at Setup Support by SAP To assist customers in implementing the change processes, SAP offers MaxAttention, Safeguarding, and PSLE customers the Rapid Deployment Solution service for change control management. This RDS service is divided into four parts: basic setup, Retrofit setup, enhanced flexibility setup, and reporting and analysis empowering SAP SE or an SAP affiliate company. All rights reserved.