I have interviewed many SAP customers and identified 4 maturity levels; the bad news - most customers didn't get past the first level. The good news - once you recognize this, you can do something about it.
I recently wrote about SAP Operations, and how SAP is well behind the market when it comes to DevOps Automation.
When SAP released Solution Manager in 2002, it was quite forward-thinking. Certainly, companies like SolarWinds already existed, but the concept of bringing Enterprise Software systems into a single managed environment was quite revolutionary.
In my view, it all went wrong around 2007, when SAP implemented Maintenance Optimizer, a tool to control how upgrades are performed, and then forced customers to use Solution Manager by requiring Maintenance Optimizer for all upgrades.
Spoiler: in 2019, your software has to delight customers in its own right. It is not acceptable to strong-arm customers to adopt. I found this 2010 article, which still holds true today: Solution Manager is too complicated, too expensive, and too difficult to implement. There aren’t enough skills in the market and there is no ROI.
And so we find ourselves in 2019, over a decade later, and a few interesting things have happened.
First, much software has moved to Platform as a Service (PaaS), where Operations is more or less irrelevant from a customer perspective. With PaaS, Operations is all about your agreed contractual service level agreements (SLAs), or integrations into other enterprise software.
Second, SAP has in its latest version of ERP, S/4HANA, retained a classic software model rather than a SaaS model. Certainly, there is a SaaS version of S/4HANA but this is not what Large Enterprises will deploy. This is a testimony to the complicated business problems that SAP solves rather than anything else.
I have interviewed many SAP customers and identified 4 maturity levels; the bad news is because of how long SAP DevOps has been left to languish, most customers didn't get past the first level. The good news is once you recognize this, you can do something about it.
The first level is simple: reactive. A problem occurs, a business user experiences a problem, a ticket is created and an operator starts to diagnose. Depending on the skill of the operator, the problem may be resolved in minutes, hours or days.
To contextualize this, I spoke to the Head of SAP at one at a Fortune 100 customer. She said; "I don't want to be woken up by my COO telling me we cannot ship product because of some SAP issue". This is not just an issue that plagues smaller companies.
You can tell if you are in a reactive company because the Operations team is always run ragged. A customer recently emailed me; "We are trying to get a meeting with our Basis team but they are very busy because we have a lot of issues".
If your Operations team is really busy all the time, they're likely reactive.
I recently read an article about someone who joined a company 5 years before to produce daily reports. In their first few weeks, they wrote Excel macros which collected the data, formatted it, and sent an email out with the report at a random time between 3pm and 3.30pm. They spent their day browsing the web.
Whilst this isn't an example of good ethical behavior, it is an example of an operator who could have been proactive.
If you apply a similar methodology to your SAP environments, it's possible to get proactive. Simple example, you can implement a system that recognizes when a bank interface has failed. Knowing this is enough to send an alert to fix it right away, which is all that is needed to get ahead of the issue before expenses don't reconcile.
But beware of alerts - many tools send out thousands of irrelevant alerts every day, leading to a syndrome called Alert Fatigue, which leads to creating an email rule to file alerts in Junk Mail. A proactive system also needs to only send the alerts that matter.
How do you know if you're proactive? Well, you have discussions with the team on what projects to prioritize.
Once customers make the transition from reactive to proactive, they're able to consider automata. An Automata is a set of actions, which happen automatically.
Some 15 years ago, a friend of mine wrote a set of scripts to update 1000 Oracle database servers autonomously for a UK Government organization. Cue, 1000 broken Oracle database servers.
But now we are able to automate quite sophisticated scenarios. A simple SAP scenario is maintenance window automation: notify users, lock system, shut down system including all the dependencies, upgrade kernel, bring up the system and complete sanity checks.
And this is just the beginning.
How do you know if you have automation? Your operations team spends their time watching systems rather than tapping at keyboards.
Oracle made a song and dance about their self-healing database capabilities. Actually what they have done is simple and makes a ton of sense: using data to drive automated decisions on what to do next. This can be programmed using AI techniques (AKA algorithms).
In SAP terms this can be programmed: Is a disk filling up? Is it the disk that TemSe uses to store spools? Did we run a TemSe cleanup job recently? No? OK, let's run TemSe cleanup? Yes? Let's extend the disk and notify the operator.
Let's take this a step further. A critical security kernel patch is released for SAP. Do our systems have it? No? Let's use our automation to install it automatically for Dev/Test systems overnight. Then let's run our automated regression tests, and push approval to a manager workflow, then automatically install the update on Patch Tuesday in production.
How do you know if you have Self Healing? Well, your Ops team are working on innovation to improve self-healing and business operations.
The self-healing enterprise is coming, make no mistake. Already, every PaaS and SaaS business has taken the responsibility for operations away from the customer, and they need to find ways to drive simplicity and improve margin.
The good news is that proactivity and automation are already strategic priorities for many CIOs, and they are investing in tools like ServiceNOW and RedHat Ansible. Unfortunately, because SAP is considered to be a black box, it is frequently ignored as part of these programs.
If you still find yourself in reactive mode you need to act now, because you are paying hourly rates for skilled workers to rake leaves. If you’re interested in more on this topic, I had a detailed conversation about it here.