Software is vital to the success of businesses today. Quite simply, the speed at which you can change your software is the speed at which your business can innovate and compete. If you can’t change as fast as your peers, you’re giving them an opportunity to steal market share and competitive edge. This means there’s enormous pressure on IT teams to deliver applications, infrastructure, and services quicker than ever before.
However, an accelerated pace of delivery brings significant risk if your existing tools and processes don’t adapt at the same speed. In that case outcomes like unplanned downtime, critical application failure and a higher cost of delivery may be just as likely as greater business agility. For many organizations, agile development and/or DevOps are a solution to this problem. These new approaches provide the means to automatically deliver change at high speed (potentially thousands of times per day for some applications) and crucially, to do so with less risk than traditional processes.
So if that’s the case, you might well ask, why isn’t every firm already doing DevOps? Well, aside from the fact that changing the way you operate can be a very sensitive topic when you’re talking about business-critical systems like SAP, in part it’s simply because change is hard. It’s never easy to shift mindsets that have been entrenched over decades, not least because while the ‘downside’ of change is often relatively clear – particularly in terms of cost – the benefits are not always obvious before you begin.
With that in mind, a solid business case may be essential if you’re going to get the management buy-in and investment you need for the adoption of DevOps for SAP. It might be the difference between adopting a new approach and continuing with the status quo, so in this blog I’ll suggest some key steps that can help you to build a compelling business case and win you the support you need to modernize the way you manage SAP.
1. It’s not all about numbers
Qualitative descriptions can be useful in framing your proposal in a way that resonates with the stakeholders involved. DevOps is about modernization. It’s about optimization of resources, de-risking of change and increasing efficiency by employing automation and the principles of lean manufacturing. These terms might seem vague and perhaps irrelevant to the task at hand, but using positive, forward-looking language to position your proposal can help to set the right tone and bring people with you from the very start.
2. Define what you’re asking for
Realistically, adopting DevOps in your SAP environments will require some level of investment. That might be a direct cost – automation software designed to enable DevOps for SAP is essential for success, for example, or training team members in new ways of working – but could also be the ‘opportunity cost’ of reallocating people away from their normal daily work. Either way, being clear exactly what you are asking for will avoid difficult situations at a later stage and gives a starting point for any calculation of ROI.
3. Identify quantifiable outcomes
The broad principles of DevOps help to set the scene, but they won’t be enough to justify the investment you’re asking for. You need to define some tangible outcomes that you believe are relevant to your business and in particular your SAP landscapes, such as:
- Reducing the cost of downtime. DevOps for SAP can provide more rigorous processes and improve quality, stability, and risk controls, all of which combine to reduce production downtime by up to 70%. This has significant business impact – IDC estimate that critical application failure costs up to $1 million per hour, while Gartner use $5,600 per minute as a benchmark cost for ‘network downtime’.
- Delivering business value early. DevOps can decrease development cycles and enable you to deliver solutions faster, which increases revenue and strengthens your competitive edge. If you can estimate the potential value of a change (e.g. a new feature) then you’ll be able to indicate the additional income (or cost saving) that earlier delivery could generate.
- Eliminating expensive manual effort. DevOps helps to automate the end-to-end development and delivery process. In some cases we’ve seen firms automate 90% of the SAP development lifecycle cycle. That adds value in numerous ways, such as by reducing errors, increasing volume of change and freeing team members to do additional value-add work.
- Removing rework and waste. Endless loops of QA and development occur when solutions are deployed incorrectly or incompletely, or the requirements are ambiguous. DevOps shifts quality left and massively increases collaboration between teams to increase development and testing efficiency. Unnecessary Work In Progress may also fall into the category of ‘waste’. Do you know how many transports have been created in your SAP landscape but never deployed?
4. Add some data
To really cement your case, supplement these general outcomes with examples of what they might mean for your business. To do so you’ll need to identify appropriate KPIs that contribute to the cost and/or efficiency of your development and delivery processes. This may not be easy. Some data might be available in the tools you use today but much of it probably will be a ‘best estimate’ based on discussion with members of the team. That’s OK. It’s important to remember that this process is not a science. It’s unlikely that anyone is expecting an amazingly precise cost calculation. The goal is to create a credible, understandable view of the outcomes that DevOps could deliver.
Important metrics might include:
- What’s the volume and frequency of deployment (how many changes do you deliver, and how often)?
- What’s your cycle time (how long does it take to deliver a change from requirement to production)?
- How many cycles of rework does a typical change go through (how many loops from dev to QA to dev?)
- How long do approvals take on average?
- What percentage of deployments fail?
- How many critical production issues occur in a typical month/quarter/year?
- How quickly can you recover if something goes wrong?
Once you have this information you can start to quantify the improvement that DevOps may bring, e.g. how many developer hours does a 90% decrease in manual effort actually make available? Ultimately you may even be able to create an estimate of the cost of an ‘average’ change and therefore the overall financial savings that DevOps for SAP can deliver.
5. Be clear on scope and approach
It’s important to set expectations effectively regarding the scope of the project you are proposing. If your intention is to start small and evolve as you prove out the method, make sure that’s clear – you’ll be more likely to secure the approval you need. On the other hand if you’re starting with a large project or making a wholesale change in your team’s approach it’s important to make sure the implications are transparent, including short-term risks that may lead to long-term gains. It’s also worth looking beyond SAP. If there are DevOps initiatives in progress in other parts of your organization, you may benefit from aligning your proposal with those programmes to leverage positive sentiment and maybe even budget and resources that are already available.
Automating your way to success
Following this outline will help you to put together a story that justifies the adoption of DevOps for SAP in terms of business outcomes rather than purely technical benefits. But remember – the amount of work you need to put into your business case will vary. For example if you’re asking to start a small trial project in a company that has already adopted DevOps, maybe you won’t need all that detailed cost analysis to get management buy-in. Tailor your proposal to the people and circumstances you’re dealing with.
Once the business case is approved, you’ll be ready to start implementing the new tools and processes that will help you to successfully bring DevOps into your SAP environments. If you’d like to learn more about what that might look like check out my
A Practical Guide to DevOps for SAP here.
