My first job in planet SAP was a Service Desk Analyst. I was thrown in the deep end and our team had a rule: you stayed on the phone and solved the caller’s issue. Here's me thinking (with all my university education) hard is it is to answer a phone call, tap away at a few items, give them an answer and move onto the next call?
My first phone call starting with me exuding an abundance of confidence. Suddenly all these foreign terms were thrown at me along with a bunch of transaction codes and the user's interpretation of the issue. Something about they can’t do a GI as they are getting a -10 error but there is stock in the warehouse as they can see it in front of them and PR and IR are all done as well as the vendor has been paid. I was lost! Immediately, I put the caller on hold and turned to my mentor – arggh what do I do?!? I’m told to ask all these questions: Ask them what’s the purchase order number? Ask them if they have received the stock? Have they done the goods receipt? With a few pen and paper calculations and help from my mentor we were able to close out that call. Lesson to the caller: you cannot issue goods if you have not yet receipted them into the warehouse (who would have thought!).
This pattern followed through over quite a few months. But eventually I learned to ask the right questions. Being in a support team taught me an important lesson to use in other jobs: how to obtain valuable information via asking the right questions. Asking the right questions enables you to identify the actual issue and solve it.
I continued in my role, suddenly thinking I was this expert rock star (my inner Gen-Y shines through sometimes). Then I got a phone call from a lady from a country region who was nearing retirement. She did not grow up with computers at home like I did. I did not have remote desktop access to see what she saw so the entire information gathering activity was over the phone. She was stressed and did not know what to do. She did not know what a mouse, monitor or keyboard was. I needed her to email me a screen shot of her error message. I spent over an hour in a failed attempt to obtain. I started with describing the picture in front of her (aka monitor); I then had to describe the clicky things at her fingers (the keyboard) and step her through the squarish box that says ‘ESC’, followed by the F1 to F12 and then finally a ‘Print Scr’. I tell her to press that last button and explained that she just took a photo of her picture and now we need to “print it” and then send it to me. We got as far as saving the file and she was sooooo close to completing the email that she became overwhelmed, burst into tears and told me her supervisor will call me tomorrow to provide the details. I felt terrible. The following day it took about 10 seconds to get the error message and give her supervisor the solution.
Support taught me patience, empathy and a better understanding of the end user. Support taught me to alter my communication style to my targeted audience. I remember that phone call so well as she is the type of user I think of when I design my solutions.
After a few years in some project roles, I found myself back in Support land. It was less foreign – no longer a planet but still a different country. I eventually became a team leader with members spread across four countries for a follow the sun model support model. Each day I would write down my top priority to do list. As soon as I got to my desk and opened my inbox in the morning (if I had not received a phone call at some ungodly hour in the middle of the night) my to do list would be parked to the side as I was reacting to whatever critical issue had occurred – funnily enough the number that would be teething issues after a release to Production. My day would be taken up responding to issues outside of my control. I would get to the end of a long day and my ‘to do’ list would not have an item crossed of. I knew my priorities on the planning side were accurate as the next day when management for them.
Support roles taught me to multitask, adapt to changing time-frames, prioritisation, reacting to issues without overreacting, anticipation of issues to avoid a train smash (especially in moments where it felt like I was attempting to herd cats), managing end-users and other teams expectations and competing priorities, communicating technical issues with senior management to name just a few. These were all soft skills. In addition, I learned the system inside out. Many times I learned what not to and why not to design a system a certain way.
So why did I feel the need to write this blog?
Working in a support role has traditionally been the entry point in a career pathway to project work and architecture. It’s a great pathway to take if you want and have the aptitude and desire for project based work. However, a support role is a valuable and important career in itself. And I know quite a few people who take pride in their role and are not interested in project work. Support jobs also have opportunity for growth and promotion (team member -> team leader -> operations manager -> continue).
SAP Support jobs take a special type of person who is able to respond to unplanned issues by providing quality resolutions in a timely manner. Instead of having a go-live party each time they close out a critical issue (that may save $$) they are already onto the next issue at hand.
Interestingly, I have witnessed people from project backgrounds who could not cope in such a high-energy, unplanned work day that is typical for a support role. In one case, a senior manager preferred meetings with a defined agenda sent out in advance, however the issue was time critical and needed an answer on the spot. The project-orientated people were used to planned releases as they moved their change from Development through to Production. Their deliverable was to get to go live (and maybe hang around for a month end). They were not there 6 months or a year later when inefficient design and architecture meant supporting the system was unmanageable.
So, I find it disappointing when I witness a type of snobbery from project members or sense of inadequacy, embarrassment and failure from a support person for doing such an important job. I have observed this in the careers space either by question being asked and some of the advice given.
I hope you give support a chance. And if it’s not for you, at least the respect and appreciation it deserves.
Cheers
Colleen
- SAP Managed Tags:
25 Comments
