SAP change control automation software for even the most complex SAP environments
SAP change intelligence software providing instant visibility into SAP custom code changes
It’s a bit late for New Year’s resolutions already in the first half of February, but with 10 ½ months of 2018 left, here are three quick questions with corresponding resolutions to help simplify and improve your SAP change management processes
It can be difficult keeping SAP landscapes consistent. For example, as Quality Assurance environments are refreshed, over time systems can begin to get out of sync. The number of DEV system transports existing only in the development system, unlikely to ever be moved to Production, grows.
I’ve been spending the last week or so travelling and speaking with customers and potential customers. In two consecutive meetings, two SAP IT team leaders from two different companies told me the exact same reason for automating their SAP change control processes.
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?
The latest release is now out, Rev-Trac v7SPS03! A hidden gem that will convince you that it is high time to upgrade your Rev-Trac version, is the inflight parallel check report. This gem is related to the need to facilitate and manage parallel development, which is becoming a more common occurrence as you embrace DevOps and an Agile delivery methodology.
According to Forrester Research, 95% of organizations are moving to Agile and following suit with DevOps. (Forrester Research: Aligning Agile And DevOps Practices With Business Value). Likely then, your organization is too. In his white paper, “Drive business growth with agile processes through DevOps for SAP”, Pravas Ranjan Rout of Infosys speaks to the benefits of a DevOps approach for SAP teams and provides a suggested way for SAP IT organizations to progress forward.
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.
Recently at a customer site we discovered a great use case for the Project Release field when used in conjunction with Release Management. This organization required 2 different change types. Firstly, changes to be deployed in the morning. These changes having been assessed to not impact production stability. Secondly, other changes to be deployed in the evenings. Changes that couldn’t be introduced while the business is using the production system. In this case, the developer could determine whether the change required morning or evening deployment and could assign the schedule.
Last posting I mentioned some component areas, tenets for success, SAP IT teams will need to address on their journey to a fully implemented DevOps approach. In this post, I’ll elaborate on the first couple. To progress towards a DevOps approach, change control processes need to be robust and clearly understood by all involved. Development, QA, Testing, Business and the Functional teams. There are different types of change, and so changes will be processed in different ways. It’s not rocket science, but it is still surprising how many teams still struggle with this relatively simple concept. Managing change with a ‘one size fits all’ single process will not work in a DevOps / agile environment.