Automation is crucial for your business

Over the many years that I’ve been involved in SAP change control, it may sound like a bold statement but time and time again we have been able to automate 70-90% of the SAP change process. This is a bold claim that many people don’t believe at first glance.

The SAP change control struggle

SAP systems are notoriously hard to implement and maintain. I should know – I’ve been implementing and supporting them for over 15 years – and I have the grey hair to prove it!

Regardless of the size and scope of the team making SAP changes, the IT department is usually stretched doing numerous tasks. These tasks will vary dependent upon whether it is a green-field implementation of SAP or whether it is support work. Some tasks are done to differing extents and will also be determined by the resources and skills available.

So which tasks take up the majority of time? How difficult can it be to make configuration changes or build new functionality and deploy them to production?

Grab a coffee and I’ll talk you through the teams and tasks that are usually involved in the SAP change process – and show you how you can save valuable time and improve your development agility through automation.

1. Review of SAP changes

The team that reviews SAP change management requests is typically the senior SAP stalwarts that include Architects or Team Leads. They do many tasks including supporting the original design and impact assessment of a given change. Equally though, they are often involved in the technical or functional review of the change once complete.

Has it been completed to appropriate standards and quality? Is there a potential performance issue involved or inadvertent introduction of a security breach? Is there a dependency upon another, unrelated change? How dangerous is the change from either a technical or business perspective? Has appropriate design and unit-test documentation been included? These are all the key questions you are entitled to have answers for.

• Automate this entire workflow process – the handoffs, notifications and person-to-person collaboration.

2. Approval of SAP changes

Clearly, somebody needs to approve each change and this will sometimes include, if not be, the people performing the review above. We estimate every change made in a SAP system involves up to 20 people and 40 individual e-mails – clogging up inboxes and eating away at valuable time.

The typical SAP change process involves e-mails flying around requesting approval to migrate changes to the test systems. All highly manual, heavily reliant upon people, de-centralised and very, very time consuming.

• Why don’t you change to a system that provides contextual information that helps you consciously approve changes and automates the approval workflow? Life would be so much simpler.

3. Deployment of SAP changes for testing

More e-mails fly around requesting the physical import into the test system. It is usually the job of the SAP Basis Administration team to perform the actual deployment. And of course, this job cannot be passed to the development or applications teams. That would be far too simple!

This complex task involves running a few operating system commands and then hitting a “truck” icon in SAP – and is clearly a job only to be done by experts. If the change is deployed without issue, then sending out an “imported successfully” email is yet another manual step to this particularly redundant task. Nobody wants to control the laborious task of checking the transport logs as the import occurs and seeing errors occur either.

• Just automate this whole step. Seriously.

4. Testing of SAP changes

Once SAP changes have been deployed, the testing team is either last to find out about it or communication is carried out manually. Not only that, but testers barely have any control over the changes being deployed which can often invalidate their current rounds of testing.

Once testing is complete – either successfully or with defects, testers inform the SAP applications team to inform whether a new change is required or if the original transport can be promoted further.

• Another manual workflow process which can be automated.

5. Approval of SAP changes for production

This is the same as the previous approval point with a number of various scenarios including whether a pre-production system may exist, requiring an additional round of testing. And, there might be a whole host of different tasks done to decide whether to grant approval. Other, concurrent projects may be waiting on these changes and dependencies must be understood. Sequencing is therefore critical and a more in-depth investigation might be needed before approval is given. Also, at this point, understanding the risk level of a given change is crucial.

Since SAP systems are typically business critical, approval at this point has a much greater degree of importance than earlier in the process.

• Again – it is possible to automate this entire approval process and workflow change approvals to the relevant people including collecting an audit of approvals gained for compliance purposes.

6. Deployment of SAP changes to Production

This is the same set of tasks performed during deployment to the testing systems. Just much more critical to the business – the deployment into mission critical SAP systems must be managed much more carefully than deployment into earlier test systems.

• But it’s the same procedure – and the same Truck icon! And it can be automated.

7. Deployment of Production Support changes to Project Streams

If you run SAP parallel track development, the production support changes need to be incorporated into the project stream to ensure they are synchronized, compatible and regression tested. This is sometimes referred to as ‘retro-fit’. I’ve seen many customers do this in different ways over the years. One method is to manually re-key everything done in production support. Another option is to manually identify whether a production support change will overwrite a project change. Both options are fraught with danger.

• A much better option is to implement a change control tool that automatically does this for you. Performing an automated merge is vital to streamlining and simplifying your SAP change control processes.

When you consider all of the above steps in the process are all about validating the quality of changes being made and reducing the risk to mission critical operational systems, it’s no wonder that the whole process is bloated with inefficiencies.

Imagine if you could take these inefficiencies away and create a more agile development process by automation of significant elements of the process…

Automation is the way forward

Automation is crucial to a mature SAP change control process – and your SAP tooling should be doing this for you. Instead of performing code reviews and inspection for every single SAP change, multiple times, it can be done automatically at the appropriate point in the process. Your expensive SAP experts should only get involved in the small percentage of circumstances where a potential issue is found.

Similarly, laboriously drilling into every single change to identify potential sequencing issues during deployment is a complete waste of time when it can easily be automated.

As for the transport deployment process – is there honestly any real value when the Basis Administrators are given a list of transports to be deployed? They simply click a few buttons to do the deployment, sitting there staring at the screen and baby-sitting the process

Then at the end of it, manually putting together an email to the relevant parties specifying whether the deployment was successful or which transports failed. And having to do this for every single one of the hundreds, if not thousands, of SA transport requests created each year, and doing it multiple times – for every system in the path.

And that could be just for ECC. What about BW, CRM, XI/PI, and all of the other SAP systems in your landscape including Java stack or even non-SAP? The mind boggles at the amount of wasted effort across the world as 40,000+ SAP customers churn through this manual processes for every single SAP release..

There is a Faster, Better way..

Surely it is better to automate all of this and only get involved as and when there are issues detected?

We can automate at least 70% of your SAP change processes. I know that it’s a bold statement, but one that we have been able to prove time and time again for ActiveControl customers.

Join the revolution.