Technology Blogs by Members
Explore a vibrant mix of technical expertise, industry insights, and tech buzz in member blogs covering SAP products, technology, and events. Get in the mix!
cancel
Showing results for 
Search instead for 
Did you mean: 
Former Member

Last month we introduced and discussed several critical success factors in ensuring success of the N+1 architecture. This month we discuss the value change control software technology can provide in managing change by releases including managing change across N and N+1 SAP landscapes.

Costs and risks: Key elements of change

The costs and risks associated with managing change are directly proportional to three key elements of change and as each element increases, so do the associated costs and risks.

These key elements include:

       
  • The volume of change being managed,
  •    
  • The complexity of the processes being used to manage the change (including landscape complexity), and
  •    
  • The degree of control required over each change

When an organisation moves to a formal change release program, often as a result of increasing volumes of change, it is quite normal for the complexity of process and the degree of control to automatically increase. Complexity due to there being a need to separate and manage independently standard BAU fixes, emergency changes and release changes, often by deploying an N and N+1 architecture, and control due to the need to ensure the separation of change and to ensure change control processes for each is adhered to and followed. See figure 1 below.

       

Figure 1: Release management and change control technology requirements

Change control software technology

A change control technology that has been appropriately deployed and configured can significantly reduce the costs and risks of managing change throughout an SAP environment. Human effort is significantly reduced, process complexity is simplified and control is automatically enforced, all three being important benefits when it comes to managing change by release.

For example, in order to prevent non-urgent problem resolutions or portions of small enhancements sneaking into PRD via the BAU path, enforced allocation of changes into the correct stream, e.g. BAU or Release steam, by change request type enforcement can prevent this from occurring.

Enforced process will not only ensure the correct approval for each status each change passes through is received and recorded, but also manage the various statuses each change will pass through, manage potential conflicts within the release and govern management of the individual transports containing the changes.

When it comes to managing releases using an N and N+1 architecture the costs and risks can be further reduced through the automation of particular change control requirements such as parallel development management, overwrite alerting and protection and the automatic capturing of all BAU change for reapplication into the Release stream.

Labels in this area