I had intended to wrap this series up with this post, but because I haven’t done much review of the SAP System Change Control Process, this post will address that topic in detail. The last few SAP critical success factors will have to wait for the next post.
Many of the steps, insight, techniques, and other suggestions I have made were gleaned from the SAP ASAP methodology and my experience with the various toolsets that SAP provides to their customers and vendors.
This post will address this SAP or ERP critical success factor about the SAP System Change Control Process from my experiences on SAP projects since 1994.
| No. | SAP or ERP Critical Success Factor | Company | Integrator |
| 5 | Experienced SAP consultants | A | |
| 7 | SAP implementation strategy | z | A |
| 8 | SAP project management | A | z |
| 9 | SAP tools, templates, and resources | A | |
| 10 | SAP scope development | z | A |
| 11 | SAP scope management | A | z |
| 12 | Strong SAP project and business communication (inward and outward) | A | z |
| 13 | SAP change management | A | z |
| 15 | Sufficient SAP training (user and project team training) | A | A |
| 16 | SAP system vendor and customer trust | A | |
| 17 | SAP system design decisions | z | A |
| 18 | Amount of custom ABAP or other SAP coding | z | A |
| 19 | Appropriate SAP software configuration (system settings) | z | A |
| 20 | SAP system change control process | A | |
| 21 | SAP data analysis and conversion | A | z |
| 22 | SAP test planning | A | z |
| 23 | SAP test development | z | A |
Legend
A = Primary Responsibility for the success factor
z = Shared but secondary responsibility for success
20. SAP System Change Control Process
When it comes to SAP system changes, the software is mature. Between the SAP Correction and Transport System (CTS) and more recently the Solution Manager options, SAP change control options are very robust. Because the landscape approach is mature, and because SAP provides most of the change tools for success, I have placed this item fully under SAP system integrator responsibility.
For the actual management of the system changes themselves, including gateway approval processes for moving changes, an SAP system integrator should have proven tools and methods for managing this entire process. What is critical for you as an SAP customer, or prospective customer, is to ask SAP system integrators for samples of their change control processes and their spreadsheets, approval templates, or other resources for managing SAP system changes.
Some Steps and Considerations to Defining an SAP System Change Control Process
- Determine the team members who have the authority and ability to create and then release SAP change requests.
- Define the details of how SAP change requests are created, the naming conventions used, and how they are released.
- Define the system change documentation requirements.
- Develop tracking tools and status monitoring resources for change control or ensure that your SAP system integrator has useful templates.
- Determine how to manage the transport sequence of system changes.
- Define the change control requirements for each part of the system landscape, the requirement for SAP Development changes, and the requirement for moving them to SAP QA for testing, and then finally the requirements to go to SAP Production.
- Develop change control “levels” or requirements for the different parts of the project. For example, depending on your industry regulatory requirements, you may have less strict approval and gateway requirements for early phases of the project, but as you get closer to going live and during the testing processes, they will become more strict. Once the system is live for a short period (generally one to three months), you may establish rigid change control requirements.
Poor SAP Change Control Processes Can Create Major Problems
Despite the normal three-tier system landscape SAP has proposed for years (Development – QA / Test / Training – Production), I am still amazed by how many times production systems are opened up for direct changes. With very few exceptions (such as number range changes), any developer or consultant who insists on a need to open the production system may need to be removed from the project. This is very high risk and can cause the system landscape to be out of sync. Any supposedly experienced consultant who does not understand the need to follow a properly defined change control and verification process should not be on an SAP project or near any business technology system.
An SAP system integrator should have proven tools and methods for managing the entire SAP System Change Control process.
Making direct production system changes creates inconsistencies in the SAP system landscape, which:
- damages testing results,
- creates system maintenance issues,
- and creates general instability in the overall landscape.
For example, you may test something in your QA system. Then, when you move the change to a production system that has been changed independently, your production system may fail. And that is just one example. Once the damage is done, it may be difficult to make the landscape consistent. Sometimes it may not be possible to make the SAP landscape consistent at all, depending on the types and quantities of changes.
The first step to a good change management program is the system landscape itself. This diagram shows a typical “best practice” SAP system landscape with transport paths– or how the SAP CTS (Correction and Transport System) should be set up to move changes.
SAP Landscape Configuration Assumptions / Decisions
An SAP system landscape has a ‘Configuration Master’ client on the Development box. This SAP Development Master Client contains only system changes and custom programs. Master data will generally not be there, except for the few items needed to directly support the system setup.
The SAP Development landscape change process has an SAP Development Sandbox for prototyping, concept checking, or testing various methods on setting up transaction processing. The initial prototyping and concept checking in the SAP Sandbox will not be directly transported.
Once SAP configuration is (1) set up in the Sandbox and appears to meet the requirement, it is (2) set up again in the SAP Development Test System to ensure that it works as expected (the Dev Test system is generally a much “cleaner” system than the Sandbox). After satisfactory results in the SAP Development Test System, the changes are recorded in the test system and then (2) copied to the data conversion and ABAP programming client.
This is a parallel activity to the SAP configuration activities taking place in the Dev Test environment. ABAP programming is generally considered “client independent,” which means that any code that is created is automatically generated in all of the associated clients. This is why a separate client generally has a separate transport path.
As ABAP coding or data conversions are completed enough to test, the underlying code is used to generate a transport request that is then (3) copied into the SAP Development Master Client. When this code is copied into the Master Client, it is automatically generated in the other clients in that landscape as well. From there, the coding can be tested and verified in the Dev Test client even though that transport was not copied into there.
As the SAP configuration and SAP ABAP development-conversion activities are completed and then copied into the SAP Development Master Client, they are then (4) moved into the SAP QA (Quality Assurance) Test system. At a pre-defined point in your SAP project, a Training client is created from the SAP QA Test System. Once that Training Client, training data, and training documentation are created, you will not generally move any new configuration or coding changes into that system unless absolutely necessary. The reason you stop SAP Training Client changes is that even if the training environment is not 100% perfect (generally +90% is sufficient), you need a stable environment to create your training data and documentation from. As necessary, you will create additional training clients as part of your overall training strategy.
For more information on the various types of training throughout your SAP project lifecycle, please see Change Management Strategies and Knowledge Transfer Processes for a Successful SAP Project 1 and the second part at Change Management Strategies and Knowledge Transfer Processes for a Successful SAP Project 2 .
Once the SAP QA testing is successfully completed, you will manually (5) move each of the QA CTS (Correction and Transport System) objects into the SAP Production System and into the SAP Pre-Production client [FN1]. You begin the process from the beginning if you need to make any adjustments, changes, or corrections during the SAP QA testing process. Once you are satisfied with the testing results, and the changes or corrections have been moved into the production system, you perform your mock go-live or mock conversions in the live production system or in the pre-production system (depending on your landscape design).
Conclusion on SAP Configuration, Correction, and Change Management Processes
Over the years, I have seen some well-done, carefully controlled, and well-managed system landscapes. The one thing that set them apart was how they managed the system change process. SAP itself provides a significant number of tools and resources, including BC Sets (Business Configuration Sets) which we don’t have time to address today. Most importantly, a properly constructed system landscape and change process is critical to a successful SAP implementation.
On the other hand, I have come onto other SAP sites at customers where their system integrator should have been sued into non-existence. SAP is not some new and unproven software application with experimental methods. As my friend and previous co-worker Michael Doane says (paraphrased), it is still shocking how many SAP implementations are done as if the application just came out yesterday.
Do not underestimate the importance of a well-thought-out and carefully controlled SAP system landscape and change control process. In the end, it can mean the difference between a smooth go-live with relatively few bumps (when taken in context with all of the other critical success criteria) and a complete disaster.
======================
[FN1] My personal experience as a “best practice” is that you are better to have a separate pre-production client available to do your Mock Go-Live testing in. An SAP pre-production client is useful for several reasons: You can quickly simulate live production processing. Additionally, if significant data changes are discovered at the last minute that can be remedied in the pre-production system with some of the mass change tools or other correction methods, you can easily ALE (Application Link Enabling) the master data from one client directly into the live production client. This provides another risk mitigation point for the live conversion.
I had intended to wrap this series up with this post, but because I haven’t done much review of the SAP System Change Control Process, this post will address that topic in detail. The last few SAP critical success factors will have to wait for the next post.
Many of the steps, insight, techniques, and other suggestions I have made were gleaned from the SAP ASAP methodology and my experience with the various toolsets that SAP provides to their customers and vendors.
This post will address this SAP or ERP critical success factor about the SAP System Change Control Process from my experiences on SAP projects since 1994.
| No. | SAP or ERP Critical Success Factor | Company | Integrator |
| 5 | Experienced SAP consultants | A | |
| 7 | SAP implementation strategy | z | A |
| 8 | SAP project management | A | z |
| 9 | SAP tools, templates, and resources | A | |
| 10 | SAP scope development | z | A |
| 11 | SAP scope management | A | z |
| 12 | Strong SAP project and business communication (inward and outward) | A | z |
| 13 | SAP change management | A | z |
| 15 | Sufficient SAP training (user and project team training) | A | A |
| 16 | SAP system vendor and customer trust | A | |
| 17 | SAP system design decisions | z | A |
| 18 | Amount of custom ABAP or other SAP coding | z | A |
| 19 | Appropriate SAP software configuration (system settings) | z | A |
| 20 | SAP system change control process | A | |
| 21 | SAP data analysis and conversion | A | z |
| 22 | SAP test planning | A | z |
| 23 | SAP test development | z | A |
Legend
A = Primary Responsibility for the success factor
z = Shared but secondary responsibility for success
20. SAP System Change Control Process
When it comes to SAP system changes, the software is mature. Between the SAP Correction and Transport System (CTS) and more recently the Solution Manager options, SAP change control options are very robust. Because the landscape approach is mature, and because SAP provides most of the change tools for success, I have placed this item fully under SAP system integrator responsibility.
For the actual management of the system changes themselves, including gateway approval processes for moving changes, an SAP system integrator should have proven tools and methods for managing this entire process. What is critical for you as an SAP customer, or prospective customer, is to ask SAP system integrators for samples of their change control processes and their spreadsheets, approval templates, or other resources for managing SAP system changes.
Some Steps and Considerations to Defining an SAP System Change Control Process
- Determine the team members who have the authority and ability to create and then release SAP change requests.
- Define the details of how SAP change requests are created, the naming conventions used, and how they are released.
- Define the system change documentation requirements.
- Develop tracking tools and status monitoring resources for change control or ensure that your SAP system integrator has useful templates.
- Determine how to manage the transport sequence of system changes.
- Define the change control requirements for each part of the system landscape, the requirement for SAP Development changes, and the requirement for moving them to SAP QA for testing, and then finally the requirements to go to SAP Production.
- Develop change control “levels” or requirements for the different parts of the project. For example, depending on your industry regulatory requirements, you may have less strict approval and gateway requirements for early phases of the project, but as you get closer to going live and during the testing processes, they will become more strict. Once the system is live for a short period (generally one to three months), you may establish rigid change control requirements.
Poor SAP Change Control Processes Can Create Major Problems
Despite the normal three-tier system landscape SAP has proposed for years (Development – QA / Test / Training – Production), I am still amazed by how many times production systems are opened up for direct changes. With very few exceptions (such as number range changes), any developer or consultant who insists on a need to open the production system may need to be removed from the project. This is very high risk and can cause the system landscape to be out of sync. Any supposedly experienced consultant who does not understand the need to follow a properly defined change control and verification process should not be on an SAP project or near any business technology system.
An SAP system integrator should have proven tools and methods for managing the entire SAP System Change Control process.
Making direct production system changes creates inconsistencies in the SAP system landscape, which:
- damages testing results,
- creates system maintenance issues,
- and creates general instability in the overall landscape.
For example, you may test something in your QA system. Then, when you move the change to a production system that has been changed independently, your production system may fail. And that is just one example. Once the damage is done, it may be difficult to make the landscape consistent. Sometimes it may not be possible to make the SAP landscape consistent at all, depending on the types and quantities of changes.
The first step to a good change management program is the system landscape itself. This diagram shows a typical “best practice” SAP system landscape with transport paths– or how the SAP CTS (Correction and Transport System) should be set up to move changes.
SAP Landscape Configuration Assumptions / Decisions
An SAP system landscape has a ‘Configuration Master’ client on the Development box. This SAP Development Master Client contains only system changes and custom programs. Master data will generally not be there, except for the few items needed to directly support the system setup.
The SAP Development landscape change process has an SAP Development Sandbox for prototyping, concept checking, or testing various methods on setting up transaction processing. The initial prototyping and concept checking in the SAP Sandbox will not be directly transported.
Once SAP configuration is (1) set up in the Sandbox and appears to meet the requirement, it is (2) set up again in the SAP Development Test System to ensure that it works as expected (the Dev Test system is generally a much “cleaner” system than the Sandbox). After satisfactory results in the SAP Development Test System, the changes are recorded in the test system and then (2) copied to the data conversion and ABAP programming client.
This is a parallel activity to the SAP configuration activities taking place in the Dev Test environment. ABAP programming is generally considered “client independent,” which means that any code that is created is automatically generated in all of the associated clients. This is why a separate client generally has a separate transport path.
As ABAP coding or data conversions are completed enough to test, the underlying code is used to generate a transport request that is then (3) copied into the SAP Development Master Client. When this code is copied into the Master Client, it is automatically generated in the other clients in that landscape as well. From there, the coding can be tested and verified in the Dev Test client even though that transport was not copied into there.
As the SAP configuration and SAP ABAP development-conversion activities are completed and then copied into the SAP Development Master Client, they are then (4) moved into the SAP QA (Quality Assurance) Test system. At a pre-defined point in your SAP project, a Training client is created from the SAP QA Test System. Once that Training Client, training data, and training documentation are created, you will not generally move any new configuration or coding changes into that system unless absolutely necessary. The reason you stop SAP Training Client changes is that even if the training environment is not 100% perfect (generally +90% is sufficient), you need a stable environment to create your training data and documentation from. As necessary, you will create additional training clients as part of your overall training strategy.
For more information on the various types of training throughout your SAP project lifecycle, please see Change Management Strategies and Knowledge Transfer Processes for a Successful SAP Project 1 and the second part at Change Management Strategies and Knowledge Transfer Processes for a Successful SAP Project 2 .
Once the SAP QA testing is successfully completed, you will manually (5) move each of the QA CTS (Correction and Transport System) objects into the SAP Production System and into the SAP Pre-Production client [FN1]. You begin the process from the beginning if you need to make any adjustments, changes, or corrections during the SAP QA testing process. Once you are satisfied with the testing results, and the changes or corrections have been moved into the production system, you perform your mock go-live or mock conversions in the live production system or in the pre-production system (depending on your landscape design).
Conclusion on SAP Configuration, Correction, and Change Management Processes
Over the years, I have seen some well-done, carefully controlled, and well-managed system landscapes. The one thing that set them apart was how they managed the system change process. SAP itself provides a significant number of tools and resources, including BC Sets (Business Configuration Sets) which we don’t have time to address today. Most importantly, a properly constructed system landscape and change process is critical to a successful SAP implementation.
On the other hand, I have come onto other SAP sites at customers where their system integrator should have been sued into non-existence. SAP is not some new and unproven software application with experimental methods. As my friend and previous co-worker Michael Doane says (paraphrased), it is still shocking how many SAP implementations are done as if the application just came out yesterday.
Do not underestimate the importance of a well-thought-out and carefully controlled SAP system landscape and change control process. In the end, it can mean the difference between a smooth go-live with relatively few bumps (when taken in context with all of the other critical success criteria) and a complete disaster.
======================
[FN1] My personal experience as a “best practice” is that you are better to have a separate pre-production client available to do your Mock Go-Live testing in. An SAP pre-production client is useful for several reasons: You can quickly simulate live production processing. Additionally, if significant data changes are discovered at the last minute that can be remedied in the pre-production system with some of the mass change tools or other correction methods, you can easily ALE (Application Link Enabling) the master data from one client directly into the live production client. This provides another risk mitigation point for the live conversion.
