Moving into SAP Functional Development : Gaining Control of Change Control - Change Control Affects Everything

Changes to SAP can affect everything—the solution stack, system landscape, phases in the project, and so on. 

Change Control and the SAP System Landscape

One of the most basic tenets of sound change management or change control includes leveraging the SAP system landscape to test changes to the environment. One method often used is a Technical Sandbox Change Management Checklist. Such a checklist details exactly how changes are initially introduced to the landscape, and then how they are managed or “promoted up” the landscape, starting with the technical sandbox. A sample checklist can be found on the Planning CD.

As you have already read, sound change management practices are essential for maintaining a highly available and well-performing SAP deployment. Such a checklist approach to testing change helps ensure that nothing is missed and that all steps are actually completed successfully. Doing otherwise risks the success of the project and the integrity of the overall solution, as it impacts the entire end-user community, technical support organization, and more.

Change Control and the Phases of SAP Implementation

To understand the role that change management plays in an enterprise mySAP solution, it is important to understand the evolution of that solution in terms of phases of systems development—these phases tie nicely into the “SAP system landscape” previously discussed.

The solution phases described in the following list are based on a typical implementation of an enterprise SAP deployment, the beginning-to-end timeline of which consumes six months at best to perhaps two years or more:

1. Pilot Phase— This phase allows a prospective SAP customer to examine, test, evaluate, and explore the proposed mySAP solution. Here, it is “proven” that indeed SAP will solve the business problems at hand. It is also important in terms of ensuring that accurate training, development, and complete deployment plans can begin to be understood, and the enterprise project effectively estimated from a cost and time perspective. This phase may last from six to eight weeks to perhaps many months. A pilot phase for each mySAP.com component or area is common, as well. Note that in all cases beyond R/3, a “core” transactional system must be in place. Finally, a preliminary hardware sizing is beneficial at this point, to ensure that the pilot solution is configured adequately from the beginning, so as to best set the stage for the next phase.

2. Development Phase— Building upon the solution stack prepared in support of the Pilot Phase, this phase consists of customer and/or consulting personnel configuring and customizing the system for use in the target business areas. This phase occupies much of the overall project plan, and typically continues throughout the life of a solution (though perhaps less intensely on initial business areas, to focus on new business areas and mySAP.com components). Initial changes like maintenance upgrades and bug fixes are often performed during this phase as well, hopefully in a technical sandbox or similar system. Thus, within a few months of this phase, you tend to see a fairly stable environment for continued development, and a good foundation for moving into the next phase. During the development phase, it is also important to begin planning for the expected configuration testing and preproductive deployments to take place next—changes in business assumptions, implementation plans, and a company’s particular solution stack technology roadmap must be visited.

3. Training Phase— Like the development Phase, this phase also begins when the Pilot Phase ends. Training of the development team (many of these folks are already experienced SAP consultants) and the SAP Technical Support Organization occurs first. Training of end-user and other personnel begins when a preliminary level of configuration and/or customization has been completed. The real work of end-user training commences a few months prior to Go-Live, however, to help keep their knowledge fresh. After Go-Live, training continues to some extent for new users of the system. Therefore, like the development Phase, this phase is also ongoing in some capacity throughout the life of the solution.

4. Testing or Quality-Assurance Phase— Sometimes referred to as the “preproduction” phase, the Test/QA phase begins when the first promotion of code from development to test occurs. This phase is entirely devoted to configuration, integration, and quality assurance testing. Some time a few months before Go-Live, stress-testing should also take place. Note that the final production hardware sizing also takes place during this phase, typically completed as early as required to address hardware procurement and configuration/testing lead times. This phase does not end as long as the development phase still exists. From a change management perspective, the Test/QA phase therefore represents the culmination of individual and packaged change testing—all of the individual changes that make up a change release or wave are tested here as a single package, which will ultimately be promoted to production.

5. Disaster Recovery Phase— Often called the DR phase, this is the phase where disaster tolerance and contingency plans are identified. For the most mission-critical of systems, fully redundant data center facilities are staffed and trained. A cost-effective way I have seen this implemented is by locating an organization’s test or staging system in a different physical location from the production system. Then, assuming the system is sized appropriately and a disaster-recovery process is in place to allow for failover, the organization is well on its way to working through the remainder of the DR phase, including process testing, documentation, failover and fail-back testing, and so on.

6. Production or Production Roll-out Phase— This phase commences the day of “Go-Live” as the company and its organizations and business processes become dependent on the data being hosted or managed by SAP. Best practices strongly suggest not going “live” with multiple SAP components at once, unless they are tied together. In other words, there is usually little business reason (and much more to risk from a holistic perspective) to go live with both R/3 and APO on the same day, for example. On the contrary, though, it might make a lot of sense to go live with both R/3 and Enterprise Portal (or Workplace), as these products work hand-in-glove with each other.

Timelines typically overlap, as you see here in Figure 1. Throughout each of these phases, the impact upon the SAP Solution Stack is significant, too. The impact is so significant, and in such a fundamental way, that I have devoted the entire next section to this.

Figure 1. Note the overlap in phases—these timelines rarely support a finish-to-start approach to managing phases.