I was reading a book recently where the author was talking about failure. What struck me was that he chose to avoid the negativity surrounding the word “failure” and instead describes failure as an “unexpected outcome”.
These “unexpected outcomes” then become the catalyst for us to do something different next time around. Wasn’t it Albert Einstein who said that “Insanity is doing the same thing and expecting a different result”?
The same can be said about delivering SAP change. How many organizations have experienced “unexpected outcomes” with their SAP projects?
- SAP production system outages due to poor change control that results in huge costs and untold damage to their reputation
- SAP project overruns and delays due to manual processes that cause high levels of errors and rework
- Loss of competitive advantage due to the inability of organizations to roll out their SAP transformation projects quickly enough
- Audit failures due to the inability to report on how and when SAP changes were approved and deployed
For almost 20 years, organizations and integrators have been delivering SAP projects in pretty much the same way – and the heart of their challenge lies in technical change management – the ability to control and manage the flow of configuration and development from development into their production systems.
A typical SAP project or release contains thousands of individual changes – each carrying its own particular risk if not properly managed. But despite constant issues and failures, many SAP customers just repeatedly ‘live with’ this high risk and high complexity – after all, it’s “just part of the overhead of running SAP”.
So what’s the alternative?
What is the best way to manage complex changes in an SAP solution?
How do the most mature SAP customers ensure on-time delivery of their SAP projects?
What best practices are there to reduce the risk of SAP system outages?
I’ve worked in the SAP world for nearly 20 years and have accumulated plenty of war wounds along the way. In my experience, poor SAP change control has lead to so many issues – untested changes being put in production, project cutovers where ‘what was tested’ and ‘what was put live’ are different, teams drowning in manual processes where emails and spreadsheets of transports are the nearest things available to the ‘truth’ without knowing whether SAP changes are correct, complete or in the right sequence.
Worse still, this then leads to outages in test systems delaying project test phases and more critically, to production downtime where the business is unable to operate at all.
One of the reasons I joined Basis Technologies is because I recognized the need to do something about these issues and I wanted to help make a difference – not to one project but to the SAP industry as a whole.
And as Product Manager for ActiveControl I’m pleased to say that we’re making great progress on changing the way SAP customers deliver change.
We’ve gone beyond simple ‘change control’ and ‘transport management’ – some of the world’s largest SAP customers use ActiveControl to provide governance, run agile development for SAP, automate their development lifecycle, run automated risk and quality analysis on SAP changes, support audits, manage multi-track development, and even back out SAP transports that cause outages.
Quite simply, ActiveControl has become a major enabler for thousands of SAP consultants on hundreds of SAP projects – so to finish on a Steve Jobs quote “we just want to put a small dent in the universe.”
If you think you already know ActiveControl, or you’ve never seen it used in anger, take a look at how it could improve the performance of your SAP delivery. We’re always happy to spread the word in the quest to help remove our customers’ unexpected outcomes.
Download the ActiveControl feature sheet now.