Use SAP Solution Manager Change Request Management to Support Your Implementation Project

  • by John Osburn, Principal Technical Consultant, SAP Consulting Services – Midwest, SAP America, Inc.
  • April 28, 2010
Manager
SAPexperts/Project Management
Learn how to deploy and manage change requests within an implementation project by using Change Request Management (ChaRM).
Key Concept
Change Request Management (ChaRM) helps support your implementation project by managing your changes within your SAP Landscape. It integrates with Service Desk for change requests and cProjects for project planning.

Many users know that they can use the Change Request Management (ChaRM) functionality for tighter control of their change management processes, more accurate reporting, and less risk during the life cycle of maintenance projects. What users might not know is that they can use ChaRM to manage changes for an implementation project from the planning phases to the physical deployment of those changes within your landscape.

Based on my experience, I’ll describe all the phases of a ChaRM implementation project cycle, including the actions that can be performed during each phase. I discuss the four relevant SAP Customer Relationship Management (SAP CRM) Service transaction types that are major parts of any ChaRM implementation. Particularly, I analyze the role that a normal correction, an SAP CRM Service transaction type, plays in a ChaRM implementation and the challenges it poses for every member of an implementation team. I finish with some ideas about how to support complex landscapes within ChaRM and the pitfalls that could arise during an implementation.

Even with the additional effort involved with the setup and maintenance of ChaRM, there are many benefits for using it to support your implementation projects. Using ChaRM, a developer or configurator can perform a test transport and then migrate this new transport to the test environment without releasing the original transport. In this case, the original transport has not been released. Therefore, it maintains the lock so that cross-project changes need to be coordinated.

Also, if defects are found during testing, the developer or configurator can make the necessary fix in the development system and store this change to the original transport under a new task. This reduces the overall number of transports for projects to make cutover for the projects easier and quicker. Having all of the fixes contained within the same transport helps to reduce the risk of migrating something out of sequence or missing something entirely. Tighter control over releasing and importing transports forces you to re-think bad habits and allows for easier tracking and reporting of what is in a release. Also, there is an extremely good audit trail on both the change document itself as well as the project.

John Osburn

John Osburn is a principal consultant who has worked for SAP America, Inc. for more than four years. He specializes in consulting services around Solution Manager, focusing on monitoring, diagnostics, Service Desk, and Change Request Management. He has been a part of multiple large-scale implementations of Change Request Management, including changes for both implementation and maintenance projects. Prior to joining SAP America, Inc., he spent three years as a Basis consultant with several full life cycle SAP implementations that required extensive experience around change management tools, process, and procedures. Also, he has more than two years of Basis administration experience as a customer of SAP.

See more by this author


Comments

No comments have been submitted on this article. 


Please log in to post a comment.

To learn more about subscription access to premium content, click here.