Over the last few posts I’ve been discussing some of the things SAP IT teams will need to address on their journey to accelerated SAP change delivery. In my previous post I explained the need for process maturity and process automation. This time, we will look at the value of multi path development and release management.
A question our customers repeatedly ask is: “How can we effectively manage risk that change introduces to production? “. An excellent question to include in your current portfolio of areas to address with your change management process plan. To effectively manage risk, one must be able to identify and categorise risk. That is, could the change cause a problem, and what happens if it does (likelihood and impact)? For simplicity, I’ll cover two obvious categories, high risk and low risk.
The recent article Ringing Down The Curtain On Change Management Theater by Forrester analyst Charles Betz made me think about the future of SAP change management. What is it going to look like in 3, 5 or 7 years? One thing that is certain is that it won’t look the same as it does today. Over the years, I’ve seen SAP customers go from managing SAP change with spreadsheets, emails and ITSM tickets (and many still do it that way); to ITIL-based, semi-automated processes; and now towards business-driven automated Agile/DevOps practices.
I’d like to take credit for this, but can’t as I just heard it and I’m not even sure where I heard it, but it resonated with me…!
The gist of the article/conversation was that with more and more change automation being available to us, the desire for Agile change processes and the overall desire for speed of development, the comment was that going forward we should not be asking who is going to approve the change, but rather what is going to approve the change.
I very much doubt it, but with IT team’s inability to speed it up to the satisfaction of the business to meet the speed of change experience available from digital applications, the enterprise will look very different. In fact, it already does.
I’ve spent many years in the SAP Change Management Automation arena. In the early days, everyone was happy with just the concept of having an automated process, period. A method to facilitate all the various approvals and separation of duties required by the typical SAP Change Management process. Today, technology has brought us so many conveniences that were still science fiction only a decade or two ago.
I’ve had the pleasure of working closely with one of our larger Australian customers over the last few months. Getting insights and providing advise into their ongoing use of Rev-Trac to help them meet their development agility and their DevOps goals has been invaluable. Here is an example.
What do Basis teams do? In the SAP world, they are “above the law” so to speak with their high-levels of security and across the board access. They basically have the keys to the kingdom. They’re the main ones we depend on to handle issues as they arise and we trust them with our entire landscapes and the critical data is houses.
My career focus over the last 21 years has primarily been SAP technical change management consulting/development across many different types of companies and projects and one thing I can say for sure, is that there is no cookie cutter, pre-built, one size fits all, canned solution to meet the needs and desires of an average SAP using customer!
In travelling and meeting with customers, prospects and partners over the last two weeks the emerging top of mind topics seem to be around lowering the cost of managing SAP changes and how to go about implementing SAP ALM orchestration. Here are some thoughts as to why.