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.