Is your SAP platform flexible enough for your business strategy?
I met an old colleague at Waterloo station last week. It was great to catch up after so many years and as we were boarding the train we inevitably got onto the subject of what we’ve both been up to.
As a CIO of a large organization he was bemoaning the fact that after so much investment in SAP, the business still weren’t happy. Why? Because it’s just too painful and too slow to implement the changes they need to give them an edge.
This is no surprise to me. I’ve seen this time and again over the last 20 years or so.
There’s no doubt that SAP is great at running core business functions and operations but if you want to make changes and adapt to urgent business needs, it’s a complete pain.
This is where the growing trend for DevOps comes in.
Imagine being able to dynamically adapt to change and become more flexible so you can deliver functionality and enhancements to the business quicker to give them a competitive edge.
In the SAP world this doesn’t sound too easy, but it is possible to make SAP development more agile.
The organizations I speak to are crying out for a move to frequent, smaller releases. They don’t want to wait for 6-12 months for stuff they need now. By then it will be too late.
How do you achieve Continuous Delivery in SAP?
Continuous Delivery is commonplace for many of today’s IT platforms but it’s nirvana for the SAP world.
- Why wait for an entire project to be fully developed before anything can be tested?
- Why wait until the entire project is signed-off before deploying anything into to production?
- Why not test and promote to live as soon as self-contained elements are ready? Surely that’s a better way to give the business what they need ASAP?
Of course this requires a shift change in mentality and much improved business alignment with IT. The business needs to be involved in the development lifecycle and not just be a customer at the end of it.
Automation and collaboration are key along with a cultural change to break down barriers between teams who are often from different organizations and in far flung parts of the world.
Efficient testing is critical and testing silos should be avoided as they cause too much disconnection. Bring testers and developers together. Get QA teams and the business to work with each other. Shifting testing left in this way ensures that test activity is fully connected with development and delivery so there’s faster feedback and greater quality.
And of course, you need to ensure that your test environments work like production. Sounds simple and sensible, but if it’s not done, how can you know that what you’ve built and tested will work when it goes live?
It also provides a perfect opportunity to build bridges with operations, working together to create development and test environments that mirror production configurations.
Does your SAP change control tool support Continuous Delivery?
What underpins all of this is to have the tools to support these new processes and ways of working. Ask yourself if your current tools can support these key requirements:
- Support the late unbundling of changes to allow the stuff that’s ready to go live and the stuff that’s not to be left behind (and understand if there are issues or dependencies with doing that)
- Communication and collaboration on changes to bring teams together so they work end-to-end throughout the full lifecycle
- Automated deployments to reduce errors. Manual processes introduce errors, inconsistency and add lag. Automate as much as possible and coordinate any manual activities so they’re logged and not forgotten
- Shift quality left. Reduce rework and identify risks, issues and quality breaches early in the development process
- Shift testing left. Understand the impact that changes have on testing so effort can be targeted
- Test on production like data. You need to quickly be able to spin up a copy of production and anonymize sensitive data
- Ability to back out changes and restore the previous state if something goes wrong. Service needs to be quickly restored if there’s a failed deployment
If the tools used to manage SAP change can’t support this philosophy, then your business’s agility and competitiveness will be lost, and faith in IT diminishes.
After a long chat about all of this my old friend eventually left the train looking enlightened but troubled.
I stayed on for another 3 stops. And that’s when it hit me…..
He could see that the principles we talked about could have a huge impact on the ability of his IT teams to deliver change faster and better and for the perception of IT to be raised to superstars. However, his SAP-based change control tools simply can’t deliver in this way.
And that’s the crux of the problem.
Solution Manager and ChaRM struggle to provide agility and once a change is in a project, that’s it – it has to go in that project – so you can’t be unbundle it..
On this journey my friend and I started off together at the same station platform but the fact is that either of us could have got off at any station we wanted. With SAP you’re locked in to that ‘train’ until the end of the journey and in a lot of cases that’s just too late.
Organizations that run SAP can shift to Continuous Delivery today but need to be open-minded about changing the way they work, and have the tools – and courage – to allow them to do so.