Moving into SAP Functional Development : Gaining Control of Change Control - Change Management Best Practices and Approaches (part 2)

4. The Release Strategy Approach to Making Changes

One of the absolute best practices that should be embraced by every SAP shop is use of the release strategy—industry leaders running SAP have employed it for years. As opposed to implementing changes one at a time in an unorganized and less controllable manner, the release strategy seeks to bundle changes into a “release,” as you see in Figure 2. The release is tested as a unit of changes, and often implemented on a monthly or quarterly basis. Sometimes referred to as a “change wave” or simply a “wave,” releases facilitate better planning, scheduling, staffing, and testing, in addition to better controlling costs (that is, costs associated with planned downtime, after-hours hardware/software support, and economies of scale when it comes to unit testing). Although a release may consist of many changes at once (all tested in concert with one another), best practices dictate that you “layer” changes into your SAP environment, keeping most solution stack layers in a consistent state. For instance, changing firmware during one release, upgrading mySAP.com functionality in the next, and upgrading the OS during the following “wave” minimizes later support issues never uncovered during the promote-to-production testing process. The idea then is to generally focus a particular release on making large changes in only one layer at a time (when possible, of course), with smaller accompanying changes in other layers as necessary.

Figure 2. A change release strategy bundles multiple discrete changes into a change “package” or “release,” often also referred to as a “change wave.”

A release’s contents—the changes to be promoted eventually into production—should be clearly documented on a file share, Web site, or through another means accessible to everyone on the project team, the Change Management Support team, and all stakeholders. A release may consist of the following elements:

• A predefined group of business-process-oriented changes and enhancements approved by the business

• Cross-application components needed to provide integrated solutions in SAP

• Support packages, SAP Kernel upgrades, and other SAP updates needed to maintain a well-performing SAP system

• Incremental SAP Basis upgrades (that is, 4.6C to 6.20 planned release upgrades, for example)

• Modifications to SAP extracts and interfaces

• Updates or patches to the database and operating system layers of the SAP Solution Stack

• Firmware and other hardware updates required of the SAP Solution Stack hardware layers

Regardless of the contents of the release, remember that all releases must be promoted “up” the SAP landscape leveraging the change management process. No exceptions! In other words, as you can clearly see in Figure 3, no changes must ever be put straight into production without some kind of prior testing in another system within that particular landscape.

Figure 3. Promoting changes in any other manner than “up” the SAP landscape violates basic change management principles.

For SAP implementations with multiple productive instances, a similar though more involved strategy is deployed. A “global” development system is recommended, and through a well-managed client strategy, this single development environment services multiple Test/QA, Staging, and production environments. As you see in Figure 4, such an approach allows for master data to be managed in one system, while also supporting the diverse needs of different geographies, for example.

Figure 4. For SAP implementations that support different geographies, an approach like this “Global Path to Production” allows a single development instance and its associated master data to support multiple productive instances.

Exceptions to exclusively using a full-blown formal release strategy exist, however. For example, critical SAP updates needed to address “bugs and bombs” are often implemented in Emergency Change Releases. Similarly, critical changes may be put in quickly if data corruption or comparable risks are present. Such changes often include last-minute OS security patches, disk drive and disk controller firmware updates designed to prevent recently discovered data integrity issues, and so on. But these changes should still never be put directly into production; rather, they should instead be expedited through the change management process.

Finally, before we move on, it should be noted that a sound release strategy does not coincide with quarter-end or year-end processing. For example, if a company embraces a closing schedule based on the calendar year, the end of March, June, September, and December need to be “off limits” to change control waves. Similarly, month-end changes should be avoided as well. Instead, for my calendar-year customers I endorse the practice of promoting changes into production in mid-February, mid-May, mid-August, and mid-November.