Skip to Content
Author's profile photo Former Member

How to get quicker solutions from SAP Support

I work on many incidents a day and whenever I get a new one I have a big challenge: to understand the customer’s issue. The customer may have clear in mind what his/her issue is. But normally it’s not easy for me to understand it. So, some time is taken until I completely understand the issue.

Here I will present some tricks you can use to help us helping you and get faster solutions.

1. Search first, log an incident later

My first tip is to use the SAP xSearch to search for existent SAP Notes, Knowledge Base Articles (KBAs), SCN blogs, discussions and wikis. Mainly if you get an error message: it’s easier to elaborate a search when you have an error message.

A good search will maximize the chances of finding a solution yourself. But you may think: “I pay SAP for support. They must provide a solution”. Well, you are right. But as much faster you get a solution, the less the issue will impact your company, right? As I said, we (support engineers) take some time to understand your issue before being able to start our investigation. And nobody knows more about your issue than yourself.

The SAP KBA 1540080 is very basic and shows how to perform searches on the SAP Service Marketplace. If you’re already familiar with that process jump to the next: the SAP KBA 2081285. This one explains in more details how to perform the most efficient searches. Believe me: if you don’t know it yet, it worth a try.

2. Create an incident

You combined many search terms but could not find an existent correction (SAP Note, KBA, etc.) to your issue so you need to log an incident. In this case, the more quality has the initial information you provide, the less time it will take to the support engineer to start the actual troubleshooting of your issue.

Sometimes we see incidents going back and forth requesting the connections to be opened, the customers claiming that the connection is opened but the support engineer reports that it still fails, the support engineer requesting more detailed information about the actual issue, how to reproduce it, traces, etc.

So, here’s a checklist for OLAP incidents (some of them may apply to other areas):


a) Select the correct system ID and installation number

Opening the incident for the correct system ID and installation number will ensure that no confusion is made by the support engineer when accessing your systems. In case the incident needs to be forwarded to other component or to the Development Support no time is wasted finding the correct system to connect to.

b) Open the connections

Usually, for troubleshooting OLAP issues, the support engineer needs R/3, BW RFC and BW GUI connections. The instructions on how to set those connections up are contained in the SAP Notes 812732 and 195715, respectively. He/she also may need HTTP connection for testing whether the issue you reported lies on either the backend or frontend layer. The SAP KBA 592085 shows how to configure the HTTP connection.

In some companies the process of opening a system connection is very bureaucratic and/or takes a considerable time. You wonder if there would be a way to do this just once. In fact, there is: the Line Opener Program (LOP). Read the SAP Note 797124 for details.

c) Provide the logon information

If you don’t provide the logon information in the secure area the support engineer will not be able to connect to your system. The SAP KBA 508140 explains how to provide user name and password in the secure area.
IMPORTANT: Never write down a password in the body of the incident. Use the secure area instead.

d) Ensure that the user you provided has proper authorizations

The user account to be provided to SAP must have some specific authorizations. In the ideal case you provide a user with SAP_ALL authorization. In case that is not possible, at least the authorizations in the SAP Note 177875 must be given.

e) Simplify your report/query

Your business scenario sometimes require very complex reports to be designed. Some issues then show up (like after an upgrade, for example) and the customers log an incident for that. However, in nearly all cases the report/query can be simplified and the issue is still reproducible.

Simplifying the query allows the support engineer to focus on the real potential causes of the issues and can save much time investigating the issue. The SAP Note 1125883 shows some recommendations to be followed in that matter.

IMPORTANT: For performance issues it is very important that you apply filters to your report/query so its execution time does not exceed 15 minutes (notice that the support engineer will execute it repeated times). Also inform by what factor the applied filters will reduce the amount of data returned by the report/query (e.g. “my filters reduce the query results in 80%”).

f) Explain clearly how to reproduce the issue

Provide a document with screenshots showing each step taken until the issue is reproduced: what transaction (T-Code) you open, what is the name of the report you are accessing, what is the technical name of the BEx query associated to that report (if applicable), what input values are required (if any), where to click, what options to select, etc.

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Uwe Fetzer
      Uwe Fetzer
      Author's profile photo Former Member
      Former Member
      Blog Post Author

      Hi, Uwe.

      What motivated me to write this blog was a recent research I did. You may not believe but only around 2% of the incidents I worked in the last 12 months were like yours, containing steps to reproduce, description of the issue, having connections opened, etc. In all the others I had to request something that was missing.

      There are cases that 2-3 weeks are taken just to get a connection properly configured. This is not good for us and not for the customer.

      I wish all the incidents I take were like yours. Supporting would be much more rewarding.

      Author's profile photo Uwe Fetzer
      Uwe Fetzer

      Hi Leonardo,

      the problem described in the blog post is, that many support agents just don't read the content of the incident, although all information you mentioned is present.

      By the way: the blog post Just for fun... a day in my life is not by me but by Nicolas Busson but I experienced the same often.