January 23, 2009

Service Desk or Incident Analyst – which hat am I wearing today?

Posted in ITIL at 5:40 pm by Molly

In the previous post we discussed the differences between Call Centres, Help Desks and Service Desks. Now let’s discuss the differences between being a Service Desk Analyst and an Incident Management Analyst.

Since we know all about what a Service Desk function includes, let’s look at what the Incident Management ITIL aims are:

“to restore normal service operation (the quality aspect) as quickly as possible (the time & money aspect) within minimum disruption to business (the cost aspect) so continue revenue earning activities”

Well isn’t this kinda what the Service Desk do already? Indeed, but only to some degree. Remember the Service Desk provide that initial support, if they can’t resolve the error in a suitable timeframe, before SLA starts ringing its alarm bells, what are they going to do, call the user back and say “sorry mate, can’t help you with that error you reported”. In real life, they won’t do that, they would infact pass the error onto Incident Management who are the 2nd line support Service Desk if you like, but they are attached to the Incident Management process, they will be the people who investigate and diagnose this incident further. Do they contact the user directly if they require more information or if they restore ‘normal operation service’ back to the user. Sure why not, it saves time doing it this way, but if we want to stick to the ITIL process, this incident analyst will return the incident back to the Service Desk operator or analyst and give the resolution details so that they can contact the user and close off the call correctly with the correct closure codes and comments. Note that the Service Desk contacts and closes the call. What if the Incident analyst contacted and closed the call. Wouldn’t this confuse the user a little bit too much, here is another person taking the ownership of his call, maybe asking more questions etc … You’re right, so according to ITIL, OMCT (Ownership, Monitoring, Communication & Tracking) remains with the Service Desk. The Service Desk tracks all incidents, even incidents that turn into problems, why? We’ve mentioned it before, it’s because the Service Desk is a ‘one stop shop’ a SPoC (Single Point of Contact) and let’s not forget that the Service Desk can produce all the management information on each and every incident, service request, question, query, that could kick off further improvements of services, can identify where incidents are constantly occurring (and pass them to Problem Mgt directly), may even identify that users need additional training or education in weak areas. If we let Incident Management start to be a ‘one stop shop’ aren’t we duplicating the process, duplicating the management metrics, wimply pass the information back to the Service Desk and let them deal with it, because they have been trained in their roles.

So when implementing Incident Management in your organisation, pay close consideration to the boundaries of responsibilities, avoid duplications of roles and responsibilities, stick to the good practices of ITIL, they have been proven in many of the top global industries, why would you need to re-invent the wheel.

Consider this too, you have 12 Service Desk analysts, and you need to implement an Incident Management process and team. Will you (a) employ new staff (b) use the existing skills within your Service Desk, but allow them to change their hats every now and again. In the Middle Ages, farmers in the UK and maybe around the world used crop rotation methods in their fields, this was to allow the soil to recover and rejuvenate its good qualities, cows and sheep pastured allowing nutrients to enter the exhausted crop soil from the previous year. Can we use this technique in our modern world but for people. Would you not see a more motivated staff force, if you rotated them on a 8 on the Service Desk at all times, but took 4 out of the loop to work on Incident Management, each member of staff would gain valuable information from dealing with incidents to take back to the Service Desk. It would give each and every person another skillset so that the organisation would retain them further (maybe even pay them better). Staff morale may invariably rise, you’d hope so, because the Service Desk analyst wouldn’t just be answering calls day in day out, but knowing that next month he or she may be doing more technical monitoring and investigations AND bringing that knowledge gained within Incident Management back into the fold (“oh yes I had that error last month, now I know I put the resolution into the Incidnet Record and the Knowledge Base too, ….. here it is”) and something as simple as that, reduces the time to resolution, gives great user satisfaction and reduces the cost to the business of further investigations, monitoring time, diagnostic tweaking and researching etc. because it has been recorded not only in the incident record itself, but in a Knowledge Base (very useful things these KBs).

So go ahead, wear your hats, but know the boundaries of your roles and responsibilities, unless you are a very small organisation and you can wear two hats in the office.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: