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.
Recently, I came across a post outlining the steps for development teams to successfully start a DevOps transformation. In his post, John Jeremiah, points out that for a successful proactive transformation certain stars need to align. That is a business need for velocity and speed and management’s impatience with the current pace of change.
However, in speaking with SAP IT teams looking at a DevOps transformation it almost always is in reaction to pressure from the business rather than a proactive change in approach. So how can an SAP IT team better anticipate the need for change and become a little more proactive?
In speaking with SAP IT teams who are successfully pivoting to agile SAP development, one theme continues to stand out. Control of the SAP change and release process needs to move from a single, centralized point of control to multiple, decentralized points of control.
After many years analyzing customers’ change control processes we’ve learned that no two processes are ever the same. However, I’ve noticed that when a company sets out to improve their change control processes, they tend to make them more complex than necessary. Particularly when attempting agile processes for the first time.
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.
Last week an Infographic landed on my desk illustrating recent RedHat sponsored UBM research around the future of business IT applications. What caught my eye was the way the Gartner Bi-Modal IT concept was used to describe the different kinds of IT applications in play, rather than focussing on the way the different application types were managed – perhaps the area we normally speak into.
During a recent webinar, we asked attendees to what degree their SAP IT organization were feeling pressure from the business to ‘speed up’. The results were telling.
Improving the outcomes of SAP change management processes has become increasingly important as SAP customers deal with higher change volumes and shift to more agile delivery methods. Developing that process can be challenging, especially if it’s the first time — at RSC, we’ve found that the most common areas of improvement measured by customers are…
The benefits of agile software development are well documented. A nice summary is provided by the global consulting firm PwC. However, established processes and innovation/agile processes are at odds – especially in the SAP change management world which is very much accustomed to a waterfall SDLC methodology.