Are they serious? Yes, they are! Expectations of SAP Users from SAP Consultants in an Organization
Are you an Application Consultant and have started working for an Organization’s IT on a SAP Support Role? Do you find yourself in situations where business users expect you to
- resolve issues, they face in ‘their’ SAP system, as soon as they report them (regardless of whether / not they have provided all the details),
- find-out the root-causes of the problems they ever face (knowing they are following wrong procedures to complete their tasks),
- change the system’s configuration so it works the way they want (despite the fact an alternative route is available), and
- provide an instant solution to meet the ‘urgent’ & ‘current’ requirement (without going to implementation ‘formalities)?
If yes, how do you handle such situations? Especially when, on top of such expectations, you hear some statements like below:
- As our agreement with the business is to resolve issues within 24 hours, you need to do something about it.
- It is embarrassing to know the same issue is appearing again & again. Isn’t there some permanent solution?
- We have to align ourselves with business needs. Maybe you need to extend your full support.
- For this particular requirement, we can’t afford to follow the methodology you’re referring to provide solution.
If you are among those who feel ‘ignited’ with such pressure (from both sides; the Business and IT), you may need to work on few additional skills. No, not the technical skills! You’ve good skills in the module you’re working in and you’ve demonstrated these already on “nn” numbers of SAP implementation projects. The solution operation environment is different and hence, it doesn’t expect you to always showcase your technical abilities, it sometimes requires you to guide business for “what now” and “what next”.
Previously, at implementation projects, the business people you were dealing with were MOSTLY Subject Matter Experts and you had luxury of a dedicated project team & leads who knew the subject to good-enough extent. Now, when you’ve joined the organization’s SAP Support Organization, you might not see similar model available in new organizational structure, rather you should be expecting something like below:
- The end-users are mostly focused & possibly with no knowledge of other related areas beyond the transactions they’re supposed to perform.
- The managers merely knowing there’s some change in IT system, without being able to really differentiate between earlier / new system.
- You are understood as SAP Guy, not modular specialist anymore. Hence, you may expect people routing their problems to you, even if you’re not the relevant person.
- Your manager might / might not be fully aware of the challenges you have faced in the module with x number of experience. So don’t be surprised if you don’t get the required support up to satisfactory level.
If you understand the model depicted above, it’d be more easier to adopt few additional skills, I’m referring to.
Understanding the situation: Any user, when he/she reports an issue, generally explains “what he/she was doing” and “where he/she was stopped” on a high-level, assuming you are fully aware of his/her situation. When you first receive the message, chances are you may feel bad to see the language – without any protocols. Keep your cool, it’s not personal message, anyways. Just try to put yourself in user’s place and if you can’t imagine the situation completely respond back, assure user of your support and ask for explanation where anything isn’t clear. When asked explicitly, a user may provide details you require to provide solution. And remember (even if the user wasn’t polite enough in his/her message) you (still) have to be respectful.
Addressing the reasons: There are situations that an issue requires urgent attention; you may find a way-out to resolve the issue. However, once solved, it doesn’t mean the chapter is closed. It may reappear and if it’s appearing more frequently, than there must be some background reason causing it to appear recurrently. You have to work on the reason; if you don’t it’ll haunt you. To find-out the root-causes, in ‘silent’ times (which means not the peak times), you may try to call the user and understand from him / her the complete situation in which such issue appears. Having detailed feedback could provide you some clues to look for the possible causes. In many cases you’ll notice the wrong procedure to complete a process is being followed which would not be told openly until you investigate.
Educating team & promoting functionalities: Sometimes business users require a solution to be changed / enhanced just because they’re unaware of additional functionalities available within the system. They may, therefore, insist on incorporating the desired functions within a solution delivered to them earlier. By educating them of the capabilities of the module and promoting those additional functions which were never asked before could dramatically reduce number of requests to change the system behavior. Sharing tips on exploring additional ‘nice functions’ now and then could not only help them in completing their tasks but also in accepting SAP system as a desired tool.
Getting the stakeholders involved: It’s not surprising if business users require you to provide an urgent solution as they are also required to suddenly shift their focus on an urgent business need. So in natural order of consequences, they will require the backend tool (the SAP system in our scenario) supporting their process to accommodate the new requirement. As you’re responsible for the respective component, you’d be required to provide solution as a result. But for you to move on, you need to understand the requirement first, have to settle with business on a single solution out of many you’ll propose, have to implement the agreed-upon solution and get it tested before you could make it available for productive use. All of this effort, for sure, isn’t related to you in its entirety; some of the tasks are yours, some have to be addressed by process owner and some by your boss. What would help you here is to list down the tasks, assign what belongs to whom, get estimate from the parties involved and assemble the whole plan and send it across to get everything aligned. You’ll notice by utilizing your planning & organizing skills you could get the stakeholders involved and could set right expectations.
The business expectations are part of a typical support process which include managing issues, problems, changes & new requirements and require you to exercise your Analytical, Communication, Presentation and Planning skills in addition to your existing technical skills.
Of course, I agree there are many other skills used in a solution support environment; I’ve just mentioned those which helped me a lot in last 5 years since I moved to a Support Function at an Organization’s SAP Center of Excellence, after working with SAP Partners for 8 years on different projects. You may share your experiences / thoughts here.
it is nice blog ,really open up new career avenues for those consultant whose opt sap consultancy ,i appreciate Mr Faisal Iqbal for positive approach toward sharing best practices and experiences,,this is worth reading which add on sap literature particularly for fresher as well as business partners and consultants.
Thanks Barkat for liking the content and referring for reading. I hope its useful to those, particularly new to support function.
Very informative and worthwhile for SAP Consultant in their working. I am sure , it will assist many consultants during their solution design.
Thank you Muhammad for your comments. As the topic addresses key elements of SAP Support, I hope it could help greatly to those moving to solution operation environment, especially in understanding why the expectations (from SAP Consultants) are different in pre & post implementation.
Good Faisal Bhai ! ! ! very informative
In my opinion you should add the following
You have to set the service level agreement for Low , Medium and High Priority issues so user before creating an issue should understand how long it can take to resolve their issues and set the priority according to that.
Above that you have to distinguish and draw a line between the enhancement and routine maintenance very carefully.
Thanks Baddar for your comments. In fact sometime you, as a support consultant, are asked to address some of the issues out of general procedure and hence, your 'plea' of referring to SLA is unheard, I'm sure you understand what I mean : )
Where are you by the way? Long time! Let's reconnect.
HaHa Thats true, but still if your budget & Resources are allocated properly than you can not include scope extension in routine system maintenance work. I know companies don't practice that when they have inhouse support team (Ghar kee murghee daal barabar)
I am in Vancouver , Canada
Connect of FB