SAP Change and Release Management: Best Practices in 2020

6 ideas to help improve your requirement-to-deploy processes

‘New year, new me!’. Well, not actually me. I didn’t say that. I’m not big on Arbitrary Resolutions.

One of my colleagues did voice the sentiment earlier a few days ago though. OK, their version came with more of a ‘…’ and a sigh than an exclamation mark and enthusiasm, but the sentiment was real enough.

It’s clear a new calendar year gives a lot of people the nudge they need to start doing some things differently so in the spirit of self-evaluation and making changes for the better, here are 6 best practice ideas that could improve your SAP change and release management processes in 2020.

Let your developers own it

Step one is to start thinking about how you can shift the responsibility for quality as far left in the software development lifecycle as possible. You need to let your developers own it. Or perhaps even make your developers own it.

Getting things right first time (or as close to that as you can) has a myriad of benefits. It’s going to help you eliminate technical errors, reduce the burden of testing, shorten cycle times from development to delivery, get rid of pointless code rework. All of that is going to mean faster deployments with fewer production issues, which, let’s be honest, is all the rest of the business cares about.

How can you do it? There is a range of possibilities. Simple peer reviews are a good start, so that the thinking behind every new piece of code is shared and discussed. Unit testing is going to help. And so on all the way to a real DevOps approach, which typically has cross-functional teams and ‘shift left’ right at its heart.

Change and release automation isn’t a prerequisite here but whichever approach you choose, it’s going to help. As one of our customers, Honda Europe, noted, “A developer today can run nearly all the [quality] analyzers … in the development environment. So he can never complain to the BAU team at a later stage that he was not aware of any issues.”

Define your workflows and responsibilities

Some of you might think this is stating the obvious. Surely every firm has a clear definition of who can sign off what, when, in which SAP systems, based on what criteria? Well, not necessarily, in our experience.

In some ways it’s understandable. Often the only evidence of change exists in a chain of emails and spreadsheets that are hard to track and even harder to parse. It’s messy. Plus there might be multiple different BAU and project developments going on at the same time, with different owners. And then hot fixes and security issues have to be dealt with, which can’t wait for people to be in the office. Do these all rely on the same approver, or can the process be different for each?

Many of you will have this covered but if not, maybe now is the time to change things. It won’t necessarily be easy and you’ll probably get plenty of pushback, especially if people in your team have been used to doing what they like when they like, but the effort is worth it. Ultimately you’ll see faster, better deployments of change and your audit process - that perennial time sink - will be far easier.

Another Basis Technologies customer, the UK retailer Dunelm, used change and release automation to support an exercise like this during a major SAP transformation project: “[we] needed to implement more governance around our processes to make sure the developers can’t just develop things, move them in transports, and change things in the QA system. So we developed new roles to ensure the developer access was the way it should be.”

Make 9-to-5 the new out-of-hours

For so many SAP teams, there’s an expectation that out-of-hours change is normal. That team members should be available in the evening or at weekends, because business-critical systems simply can’t be touched during the working day. Why? Well let’s be brutally honest: it’s because things do break too often when changes are made.

OK, sometimes out-of-hours deployments make sense, for example during a major project cutover. But for the most part, there’s no reason why SAP changes can’t be deployed safely and easily during a normal 9-to-5. You just might need to change the way you work to make it happen.

The steps I’ve already mentioned come into play, as they will help you to reduce production issues. Automation is really the key to this one though. Deploying on demand rather than in huge release cycles minimizes risk. Automated sequencing and deployment frees up the team for other work. The ability to back out changes virtually instantaneously if there are issues increases confidence. I could go on.

Ultimately it boils down to the fact that change and release automation isn’t only good for a firm’s bottom line. It helps their SAP teams to be happier and more productive. Sounds over the top? Not according to our customers.

“Me and my junior colleague always had to reserve our time at night to manually import approved transports … the strain on our team was really on a different level.”

“[without ActiveControl] you really need to do changes out of hours. You’re upsetting our business people because they need to stay up. Not only that, if there’s an issue they call the configurator, they have to re-package everything, and then basis consultant also has to be up - everybody’s going to be disrupted. [With ActiveControl] that is really eliminated.”

Base your decisions on data

Delivering changes in complex SAP systems is hard to get right. But it’s important - the business needs SAP to work properly - and failure can be really expensive.

That being the case, it’s a wonder that so many SAP teams still rely on manual methods and human experience when technology is available that can help. It’s all too common in spreadsheet-based change and release processes for deployments to be approved based on what teams think is going to happen rather than an empirical analysis of the actual impact.

Best practice is definitely to make data-driven deployment decisions based on technical analysis of code and transports. That could be anything from important but non-essential issues like code quality, to critical matters like identifying high risk objects and inter- or intra-system dependencies of each transport.

I’m sure you can guess what’s coming next. Yep. Automation is the only practical way to make data-driven change and release management a reality, especially in systems with large volumes of change. There’s simply no manual way to carry out the necessary analysis fast enough and comprehensively enough.

Another of our customers made this point very succinctly, saying, "ActiveControl just did in 5 minutes what took a full day to analyse manually yesterday.”

Reject ‘this is how we’ve always done it’

I hate to break this to you and I know you might not like hearing it, but it has to be said: SAP isn’t really that special.

Sure, we have to acknowledge that SAP is architecturally different. And over the years that has meant some things have to be managed in ways different from other IT applications. There are transports to consider. Shared development environments. Unique tools. The criticality of the systems. Etc.

But times have changed. Today it’s possible to use modern development techniques like agile and DevOps to manage even the most traditional ABAP-stack systems. If SAP applications need to be run more efficiently and deliver greater business value, then sitting with our arms crossed and saying ‘but we’ve always done it that way’ simply isn’t good enough. Or as Interpublic Group, another Basis Technologies customer, put it, “People think that agile and DevOps are not suitable for ERP. That’s a myth. It is possible [but] it’s a journey.”

Now is the time to consider doing things differently. Talk to your colleagues outside of SAP. Look at new tools and technologies. Take it step by step, but start making a plan for change in 2020.

Adopt change and release automation

If you’ve got this far, I’m sure the last recommendation will come as no surprise, but automating SAP change and release automation is definitely best practice, for all the reasons listed above and more.

If you’d like to learn more about how ActiveControl can change the way you manage your SAP systems, request a free demo from our team of SAP experts.