Many global companies these days are using offshore SAP Support teams. Quite often offshore SAP Support organization accounts for over 100 people and the rotation rate within the team can be relatively high. This can create a certain disconnect between the business and the support team. The knowledge transfer process and on-boarding and off-boarding procedures for the support team are not necessarily state of the art. Global consulting companies can easily move dozens of people overnight from one big account to another.
Same disconnect is often visible even inside same Support organization between onshore and offshore teams. That starts from the language barrier and goes on to technological challenges, like a noise on the line or network being slow or down. And sometime this time gap of 10 or 15 minutes to communicate a proper action can be of a vital importance. I would not go into a deep analysis of various types of potential issues created by a "split architecture" structure of support teams, but will illustrate the problem with just one basic example.
This example is about different approaches to problem solving. One approach is rather technical (and that often can prove to be wrong) and another approach is based on the knowledge of the business process. Unfortunately the second approach can take much longer time to learn through.
Imagine that the client creates an incident ticket where the employee is observed having a wrong hourly rate. Taking it from the technical approach the solution can be to go into KP26 and change the rate to correct value. But same activity type can be used by many other employees and that might make things even worse if the rate was indeed correct for that activity type. Taking it from the business approach you may find out that employee was assigned with a wrong activity type in the IT 0315 for example, and different activity type have to be assigned there. And we do not know if it will be changed with or without delimiting and with what date (so once again the support consultant needs not only the cross-functional SAP knowledge, but have to understand the business process).
Another similar example is that the person reports mistake during time reporting with CATS. The technical solution can be found on the master data side and person will be enabled with a function. On the business process side the person belongs to the department that should not be doing any time reporting, and his/her HR number was selected by mistake or by typo.
To summarize my point is not against the offshore support teams by any mean, but about a proper learning cycle that should include extensive knowledge transfer focusing specifically on the business process side. Not taking it seriously can gradually have a negative impact on the consultancy reputation as trusted service provider.
To address this risk consulting companies can take more serious approach to the knowledge transfer as part of the on-boarding and off-boarding process for offshore team members. Same time there is a clear conflict of interests for the company. On one hand the whole idea behind the offshore team is about cost reduction. On the other hand educating technical people with a knowledge of customer specific business processes means both time and money and naturally the consulting company will want to transfer such cost to the client. At the end of the day it might raise the bill for the offshore team to match certain on site team members.
It also puts a big question on the customer side to choose between short term cost saving or paying a premium for the long term quality and reliability.
