The Information Technology Infrastructure Library (ITIL) and many others have much to say about change management and change management process but not so much on change control governing the actual technical change process. Finding ways to integrate the two can create a powerful, fully auditable end to end change control management process that both ensures only authorised changes are made to production systems and the associated risks are managed well.
Typically, the creating, testing and deployment of changes is invisible to business users and although a human error or mistake made can have dramatic business use consequences, interestingly, there is less likely to be a formal tool based change control process than for the higher level change management process.
Change control process
The process surrounding the Build – Test – Deploy phase is designed to control and manage the risks associated with introducing these technical changes into stable production systems and are often required to meet particular regulatory requirements, such as Sarbanes Oxley, Basil II (or III) or FDA CFR Part 11 regulations. The process will include activities such as development, unit testing, impact analysis, documentation completion, integration testing, business user acceptance and so on to the extent determined to best manage the risks associated with each particular change.
This means that change control is seldom a single process, but rather a set of processes designed to manage various change profiles according to risk, effort or some other criteria. It also means that various levels of signatory are required at each point, also based on risk, effort or some other criteria.
For example, a very basic process could look like the following:
1. Change approved for development
Once the change RFC is reviewed and approved a technical change is authorised and technical work can begin.
2. Development unit tested and approved for migration to QAS
Once development is completed and unit tested it can be signed off as ready for QAS integration testing.
Prior to introduction to QAS a business user approval is often sought in addition.
3. Technical impact analysed
At this step the technical changes are analysed for impact and QA testing and test scripts selected are approved as valid.
4. QAS Integration testing complete and development approved for deployment to PRD
Once integration testing and relevant documentation has been completed the change is approved for deployment into PRD. In most cases this step requires a both a technical and a business approval.
5. IN PRD
A final approval to document user acceptance of the change and to trigger the change management ‘Request for Change’ (RFC) review and closure.
Managing change control process
Managing SAP change control, even in relatively complex environments, is still largely achieved through manual processes consisting of a combination of manual control methods (paper) and a set of disconnected tools and systems. With the advent of extensive SAP environments consisting of any combination of complex system landscapes (N and N+1 Landscapes), multiple SAP solution landscapes or multiple technology stacks controlling change and the associated risks is challenging.
Unfortunately, to ensure an appropriate level of control and risk management in busy complex system and multi technology stack SAP environments most are finding the manual approach no longer adequate.
To manage change control adequately an automated technology can provide an excellent ROI. Not just by eliminating a range of manual tasks but by ensuring process is actually followed and risk adequately managed.
Higher level change management service desk type offerings, although sometimes used to track change control activity, are not purpose built for the task and so one should look further afield to products like Rev-Trac and other SAP certified change control tools and technologies.
New NetWeaver Information at SAP.com
Very Helpfull
