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

- How To Install Windows Server 2012 On VirtualBox
- How To Bypass Torrent Connection Blocking By Your ISP
- How To Install Actual Facebook App On Kindle Fire

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 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 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.
  •  Exchange Server 2010 : Outlook Integration (part 7) - Document Library Integration
  •  Exchange Server 2010 : Outlook Integration (part 6) - Alert Integration
  •  Exchange Server 2010 : Outlook Integration (part 5) - Task Integration
  •  Exchange Server 2010 : Outlook Integration (part 4) - Contact Integration
  •  Exchange Server 2010 : Outlook Integration (part 3) - Creating a Meeting Workspace
  •  Exchange Server 2010 : Outlook Integration (part 2) - Calendar Integration
  •  Exchange Server 2010 : Outlook Integration (part 1) - Integration Overview
  •  LINQ to Objects : How to Group Elements (part 6) - ow to Use Grouping Results in the Same Query
  •  LINQ to Objects : How to Group Elements (part 5) - Projecting Grouped Elements into a New Type
  •  LINQ to Objects : How to Group Elements (part 4) - Specifying Your Own Key Comparison Function
    Top 10
    - Microsoft Visio 2013 : Adding Structure to Your Diagrams - Finding containers and lists in Visio (part 2) - Wireframes,Legends
    - Microsoft Visio 2013 : Adding Structure to Your Diagrams - Finding containers and lists in Visio (part 1) - Swimlanes
    - Microsoft Visio 2013 : Adding Structure to Your Diagrams - Formatting and sizing lists
    - Microsoft Visio 2013 : Adding Structure to Your Diagrams - Adding shapes to lists
    - Microsoft Visio 2013 : Adding Structure to Your Diagrams - Sizing containers
    - Microsoft Access 2010 : Control Properties and Why to Use Them (part 3) - The Other Properties of a Control
    - Microsoft Access 2010 : Control Properties and Why to Use Them (part 2) - The Data Properties of a Control
    - Microsoft Access 2010 : Control Properties and Why to Use Them (part 1) - The Format Properties of a Control
    - Microsoft Access 2010 : Form Properties and Why Should You Use Them - Working with the Properties Window
    - Microsoft Visio 2013 : Using the Organization Chart Wizard with new data
    - First look: Apple Watch

    - 3 Tips for Maintaining Your Cell Phone Battery (part 1)

    - 3 Tips for Maintaining Your Cell Phone Battery (part 2)
    programming4us programming4us
    Celebrity Style, Fashion Trends, Beauty and Makeup Tips.