5 SAP operations fails and how to fix them

SAP Basis hasn't changed much in the last 30 years, but IT wide, incredible changes have been done. What can we learn and adapt to SAP? A guest post by John Appleby

I sometimes feel like SAP Basis hasn’t changed in the last 30 years. Some of the code that was written when R/2 was ported to R/3 in 1991 is still in place in the latest S/4HANA systems, so perhaps this shouldn’t be a surprise.

But when you look outside the SAP Ecosystem, incredible bounds have been made: Google call it Site Reliability Engineering or SRE. This is why companies like Google, Microsoft, and Salesforce upgrade hundreds of thousands of tenants, millions of lines of code, and thousands of physical machines on a daily basis.

By contrast, you will see many SAP customers still do the customary “Daily Checks”: a contracted list of activities performed on a daily basis, by some poor soul, manually checking off a list of activities in Solution Manager.

SAP is the single most complicated business application that most customers run, and as such requires a specific approach, but perhaps SAP can learn from the innovation happening elsewhere in the market? Here are 5 things you might want to consider:

1) Reduce Repetitive Activities

In our analysis, we found that a great deal of work performed by Basis teams is unfortunately repetitive. This includes the eponymous daily check, but also audit tasks like identifying discrepancies in system landscapes. Eliminating repetitive activities allows Basis teams to focus on project work and root cause analysis - making their SAP systems better.

2) Automate Audit Control

There are many SAP environment situations which require consistency - everything from component versions to profile parameters, and password policies. A single user with SAP* (unlimited) authorizations can open the whole SAP system to vulnerabilities, and this is more than threat detection: first, ensure consistency. This allows improvements in security, early threat detection, and automated audit reports.

3) Eliminate Alert Fatigue

Every customer I speak to mention the barrage of emails, text messages, and pages coming from automated systems. In many cases, a single incident, like an SAP system down, can cause a cascading series of alerts from interfaces, databases, and other checks. The system does not understand the dependency between these errors, so sends a series of alerts, which get subsequently filtered into Junk Email folders.

4) Predictive Alerts

There is a lot of buzz about machine learning and AIOps, but one area that is definitely worth looking at is alerts which recognize conditions ahead of time. This can be as simple as forecasting algorithms that are able to predict database or disk size problems, and more sophisticated problems like identifying process and memory conditions which are likely to lead to downtime.

5) Integrated Service Management

It is a given that Application Performance Management tools will automatically generate tickets and executive visibility via dashboards, into a centralized service management tool. Unfortunately, in the SAP world, this is not standard functionality and so service desks are often reliant on service managers, who manually key in issues into the central system and assign work to be done.

Final Words

Hopefully, you now have some insight into how modern SAP DevOps concepts that can be used to automate repetitive tasks and reduce the overhead of running SAP systems. SAP is often considered to be a black box, but it doesn’t have to be this way.

It is possible to take control of SAP Operations, reduce the constant flow of alerts, and use machine learning algorithms to focus the operations team on adding value tot he business rather than reacting to conditions after the fact.

Photo by Tim Gouw from Pexels