You, being a SAP Module Expert, have been providing consulting to customers implementing solutions supported by your module. Since the implementation projects follow standard methodologies you’re quite confident with the activities you have to perform during the course of solution implementation.

You gather requirements, analyze them, document as-is situation, design solutions, present different options to your customer and based on the selection develop a solution.

As you’re on the project and everyone else around you is also in such mode, you’re supported with the activities of developing and implementing solution.

Project for everyone

You configure system, unit test it or work with others for integration testing, you work with your developers / administrators / training / security / any other IT or business team, it’s a Project, for you and for everyone. Even if you face issues, ultimately you could deliver the project in set timeline with the available support. In the post-implementation period you & the project team is dedicated on addressing issues end-users face and finally you can conclude the project.

Same module different job

You have delivered solutions to number of customers (on implementation projects) and therefore you have mastered the respective module very well, now you feel yourself ready to face any challenges pertaining to the module. Now you’ve got an offer to work for a customer on a support role and you’re very excited about the role, relatively new to your earlier experience. Since you’ve provided project support before (which in most cases was for limited period after going live) you’ve set some expectations with the solution support role.

However, the new role isn’t just about Issues Management as some might think. And as not all job specs provide details on what exactly the role requires from an incumbent, it’s good to research.


Major functions of a Support Role


I divide Support function in following 4 categories: Issues, Problems, Change Requests and New Requirements. Your work, as a Support Consultant, would mostly fall in either of these categories.

Though the issue & problem are sometimes used as synonyms, both are different & require different resolution techniques. Typically if users face any disruption in performing certain tasks, they raise it without differentiating the issue & problem and you as a Support Consultant are expected to resolve both. However, to address them rightly you need to understand the difference. The issues mostly require quick-fix to complete a process and could sometime be fixed through workarounds / temporary solutions. The problems, on the other hand, cause the issues. Both the issue / problem might not necessarily be technical in nature so the resolution also could be non-technical.

For instance, a user might not be able to process certain tasks in system. It could be treated as an issue. However, the reason why he’s unable to proceed could be a problem. It’s possible that the user has maintained wrong master data and as a result he sees system behavior different than his expectations. So here you’d have two tasks; to help user in overcoming the situation he is trapped in (which is an issue) and to find out the root-cause why he faced such issue (which is in-fact the problem). You have good modular expertise, but such skills aren’t enough to address the issue as well as the problem. You have to have good customer facing & analysis skills to handle the angry customer and to find-out the reasons of problems.

Why it’s different in solution operation environment than the implementation project? Issues faced in implementation are usually (though not always) are related to design, but in operations they are generally related to user competence (ceteris paribus). So your post-implementation support experience might not help. Now you’re talking about a mature solution which was well-tested before deployment and therefore the issue might not be technical in nature. You have to understand the logic behind the original design to understand how respective solution works even if you’re module expert you’re supporting.

Change Requests are basically changes in the “original design”. Businesses change and so do the underlying IT solution requirements. A solution which was implemented earlier might not help business completely anymore and might require changes. Since you’re Support Consultant, you’re asked to address the change. Now if you just modify the design, it’s possible one business requirement is fulfilled but some other part of the overall solution doesn’t work (or behave inappropriately). So the skills you need here are cross-modular functional skills and you should also be able to analyze the impact & risks.

Its again different in both the solution implementation & operation environment. During implementation, change in design even though has an effect (in terms of cost / time / resources etc) but it’s not so severe to impact other running services as you’ll be testing overall solution anyways before going live. When it comes to operations, you don’t have luxury of just accommodating the requirements as they are raised, rather there is a process for Change Request Management and a Support Consultant has to work with internal IT teams to implement the change.

Another important & major activity a Support Consultant is often involved in is of working on New Requirements. This part of the support role apparently looks like an implementation as you go through some activities similar to project tasks whereby you meet with business people to understand the requirements, propose & develop solutions and ultimately implement & deliver to fulfill the requirements. However, there’s a difference i.e. not all new requirements are always considered projects and you don’t have a dedicated project team to work with you on such assignment.

Just as in the change orders you’ve to work with internal IT teams of the organization, you’ve to do the same in case of new requirements. AND you’ve to cross all the bureaucratic layers before you could commit / deliver something. Here the skills which help you most are your people, communication & presentation skills (among others, of course). You’ve to be able to understand other IT teams are supporting multiple solutions and therefore yours isn’t the ONLY urgent one, you’ve to be able to communicate the hurdles positively & politely and you’ve to be able to present the situation to BUSINESS and IT clearly so there’s no ORANGE to APPLE comparison on both sides.

Conclusion

To conclude the subject, here’s a summary of what you’d typically be required to work on while you’re on a support role (regardless of role type: Consultant / SME / Lead etc): To support business functions running smoothly, you’ve to 1) address the issues users face & the underlying reasons i.e. the problems and 2) manage the process changes & new requirements. Therefore you’d be using various other skills in addition to your technical abilities.

As I’m working with a SAP Customer now for quite some time now on Support role (and as such have helped organization in first stabilizing its productive solutions with support, then enhancing the solution landscape, streamlining many of its business processes, in coping-up with organizational change and currently managing cross-functional & multi-disciplinary teams), and have worked for few years on SAP Implementations previously, I think I’m clear in explaining the necessary points. However, if I’ve missed something, I’d request Gurus supporting SAP solutions to add their valuable comments for those who’re new to support function. 

To report this post you need to login first.

Be the first to leave a comment

You must be Logged on to comment or reply to a post.

Leave a Reply