Considerations when selecting an SAP change control technology

Effective and efficient SAP change control has become a hot topic of recent days and so discussion around what is available by way of automated change control technologies is increasing. It was no surprise then that our TechEd experts lounge presentations last month attracted a number of attendees whose organisations were in the process of weighing up the value of a third party SAP change control technology.

When selecting an SAP change control technology there are two broad categories to bear in mind.

The first are the higher level strategic considerations around time frames, requirements and actual cost to implement (generic to almost any technology selection process) and the second are the finer detailed technical consideration around the technology that actually makes it work.

1. High level strategic considerations

Listed are four key strategic elements to think about. These relate to the not so obvious underlying costs of a technology that can be easily overlooked.

    1. Elapsed time to full productive use
    2. Cost to fully implement (internal resource days and external consulting days)
    3. Degree to which the final solution will meet requirements
    4. Ongoing costs such as user training and user acceptance

If a technology is required in order to deliver a major project, for example, and the project start date is fixed, then elapsed time to productive use will carry significant weight in the consideration process and may even rule out certain options.

2. Technical detail considerations

It’s not just about whether or not a technology can meet the technical requirement, it’s also about how the requirement is met. Listed are ten common SAP change control technical requirements to consider when evaluating the technical detail of a SAP change control technology.

1.    Degree and method of automation
   
    o Transport migrations (and underlying TMS configuration requirements)
    o Transport sequencing
    o Workflow alerts and notifications

2.    Configuration flexibility
   
    o Number and type of approval processes
    o Enforceability
    o Workflow notifications
    o User roles

3.    Overtaking and / or overwriting protection

4.    Methods of linking supporting documentation with the changes

5.    Ease of adding or subtracting SAP solutions landscapes or SIDS

6.    Ability to enforce use and/or compliance with process rules

7.    Support for N and N+1 landscape scenarios including procedures for:
    o Cross system locking (objects and configuration)
    o Auto N change capture for retrofit
    o Retrofit of N changes into the N+1 stream
    o Transport bundling for cut over

8.    Method of support for multiple solution environments

9.    Support for ABAP and non ABAP technology stack changes

10.    Transport dependency management techniques

Of course there are dozens of other considerations and depending on the nature of your SAP environment, complexity of landscape and volume of changes each will carry different levels of importance. For example, a significant difference between how one technology manages an N and N+ 1 landscape will carry little benefit for an organisation running a simple “N” three tier (e.g. ECC DEV/QAS/PRD) landscape.

‘Horses for courses’

SAP change teams have varying needs, wide ranging expectations and experiences and differing change control requirements. This means one technology solution suited to one organisation’s brief could be unsuitable for another’s. For many, SAP Solution Manager ChaRM may be a great fit for one organisation whilst for others something more of an out-of-the-box ready to run solution may be the better fit.