In today’s fast-paced digital economy, there is a growing movement towards agile methodologies and DevOps for SAP. Increasingly, businesses are demanding more changes, more frequently with no loss in quality to meet the needs of customers, suppliers and partners.
I’ve been briefing analysts these last few weeks, primarily those in the ALM, DevOps or ITSM practice areas. It’s an exercise I really enjoy. Not only does it offer an opportunity to find out what is top of mind for analysts (i.e. customers) but it also helps validate our approach to businesses and organizations.
A frequent exercise for many SAP organizations is to refresh SAP QA Systems from Production. This ensures that suitable and up-to-date data is available for testing. With testing becoming increasingly important the need to refresh QA Systems is also on the rise.
When it comes to managing SAP changes, things are beginning to look different for SAP IT teams. Building a DevOps capability is becoming important.
Reflecting the need to provide steady state, stable SAP enterprise systems, things like control, governance, cost reduction and stability have been important for SAP IT teams for a long time.
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.