If SAP is so critical, why are there so many unanswered performance questions?
How Critical is SAP?
We all know just how important SAP is, whether your organization uses it, or you’ve only heard about it in general. And, in case you aren’t aware, 77% of all worldwide business transactions touch an SAP system in some form.
Over the years, I’ve had the opportunity to work with many of the largest SAP clients on various application and performance issues. Sometimes it’s working with applications that are external to SAP but have critical workflows that either communicate to SAP or where SAP communicates to those external applications or services.
While working with these organizations, there are three main themes that I kept hearing repeatedly. I want to discuss each of those below and break them down into consumable pieces.
Three Main Themes
CAPTURING SAP TRACES ARE TIME INTENSIVE AND MISS INTERMITTENT PROBLEMS
Basis team members spend a lot of time troubleshooting user complaints regarding performance. If one is lucky enough to have a reproducible issue, then there’s an obvious thing that every Basis team member has done hundreds if not thousands of times. Take a trace. After all, an SAP trace is the source of the truth, and it tells you where the problem may lie. This could be something like ABAP code, a database call, or a web service call to an external system. This is all great, but there are a couple of major shortcomings in taking traces.
First, is that this is something that is 100% manual. An admin goes and turns on tracing (perhaps for a certain user or a certain transaction, called a t-code,) has the user re-run the problem transaction and then stops the tracing. Why not leave the tracing on all the time? Well, great question. The short answer is, overhead. Tracing can be turned on for a short time, but SAP themselves even agree it’s not something that should be turned on all the time due to the additional performance concerns that tracing could cause on the system.
The second shortcoming is because we can’t leave it on, this means by nature, that it will miss capturing intermittent issues. This isn’t desirable, but it’s just how it is, due to its manual approach. I once worked with a client who had a handful of Basis team members “locked away” in a conference room just running manual traces all day long for a couple of weeks to try and track down performance issues. That’s quite scary!
SETTING UP ALERTS WITH SOLUTION MANAGER IS MANUAL AND PAINFUL
Every SAP team has access to SAP Solution Manager. There are many different options and combinations of “free” and “licensed” features and Solution Manager does many different things within the SAP landscape. One of the things that Solution Manager is commonly used for is monitoring. After all, who would know more about monitoring the SAP system than SAP themselves?
While Solution Manager does many things well, there is no doubt that it has its shortcomings. One of those is around the capturing, gathering, and alerting of metrics that Solution Manager captures. When you talk with the administrators, users, or even business teams that may rely on Solution Manager’s data to make informed decisions you hear some common themes. “It’s tough to work with as it’s buried in this complex, antiquated interface,” or “there are so many metrics, I have no idea which ones are important,” or the most common one I’ve heard is, “there are a handful of metrics that Solution Manager captures, but I’ve spent so much time trying to figure out a meaningful threshold to set when to alert on, that I decided to turn off the alerts because I was being alerted when there aren’t really issues and missing alerts when there are issues.” These are definitely a concern, and when I discuss these scenarios in a group setting, I get a lot of heads nodding and people agreeing.
SAP TEAMS ONLY HAVE INSIGHT INTO THEIR SYSTEMS EVEN THOUGH MULTIPLE APPLICATIONS AND SERVICES ARE INVOLVED
This last scenario is one that I commonly run into, but the pain involved varies depending on how integrated SAP is into various other business workflows, applications, and services. As we’ve previously discussed, SAP Basis teams, IT operations, and even business teams are reliant on the tools that they have at their disposal, and many times that’s only Solution Manager.
What happens when there are other applications or services involved within a business process or even for a single transaction? Unfortunately, Solution Manager has no insight into these external applications and services. It may know a call is sent to an external system, and that something is taking a long time, but it cannot identify the root cause of the performance issue in those “external” applications and services. An example of this would be an external web application that makes real-time calls into SAP for pricing or order information since it’s the system of record. In this example, if there is a slowdown with SAP, the end users nor the external web application team may be unaware, and the external web application is blamed for poor performance.
The inverse may also be true, where SAP is blamed for a slow down since it is the system of record, but the issue may be happening in this web application. Since no one has a true end-to-end perspective of that user’s transaction between systems, each team is only able to see its own piece of the pie, potentially causing high tension, finger-pointing, and high mean time to resolution (MTTR) due to this lack of complete visibility.
THE GOOD NEWS
While these problems are prevalent across nearly every organization that uses SAP and the issues are quite large and impactful, it’s not all doom and gloom. There is a solution and a single solution that can solve all three of these shortcomings.
Can’t wait until then, and curious what this solution is? Please email us at [email protected], and we will get you looped into the preview of this content and set up a no-cost workshop to discuss your SAP performance concerns!
