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

Call Centre, Help Desk or Service Desk – I’m confused!

Posted in ITIL tagged , , , , , at 4:53 pm by Molly

What are the differences between these, which one do I implement in my organisation?

Let’s tackle the last question first. Which one do I implement in my organisation? That is the 10 million dollar question. The simple answer is the one that is fit for purpose for your organisation. There is no real advantage to having a Help Desk in a fully ITIL conformant organisation is there, so pick the most suitable ‘function’.

What is a Call Centre?

A call centre handles large call volumes, like a telesales company. Look at what it’s called, Call Centre, so that means calls are centralised here, but does this call centre improve or extend the overall services of a typical organisation?

What is a Help Desk?

Now we are getting a little warmer to the ITIL meaning, but again, we haven’t hit the mark yet. A Help Desk manages, coordinates and resolves incidents fast. Great I hear you say, precisely what I need. Hmm, Umm again slightly missing the point, after all, does this Help Desk interface with all other IT activities? Well if it does, then you should be calling it by its proper name – a Service Desk.

What is a Service Desk?

A global focused approach to handle not only incidents, problems and questions, but also, interfaces with and for the other operational activities within your organisation e.g. Change Requests, Maintenance Contracts, SLM, Availability Mgt, ITSCM. How cool!

Let’s look at the primary aims of this Service Desk, especially in terms of how ITIL describe it:

    to facilitate the restoration of normal operational service;
    to act as the central point of contact (SPoC – Single Point of Contact) between the user and ITSM;
    to handle incidents and requests, and provide an interface for other activities
    “.

So in terms of what a Service Desk provides to the business, it identifies and lowers the cost of ownership, supports management of changes, reduces costs via efficiency, supports investments and management of business support services (the ones we mentioned above already Change Mgt, Availability Mgt, IT Service Continuity Mgt, Financial Mgt etc..), it improves customer retention and satisfaction, and it identifies business opportunities.

How does it do all these things, a little word called metrics, or management information or reporting or whatever you wish to call it. Remember we said that the Service Desk is the SINGLE POINT OF CONTACT for users. Well because it is the single place where information flows into and out of, isn’t it great then to have all this user information to hand. It’s how you handle this information that is also a major part of the benefits that the Service Desk can provide for the whole business.

Just because you have a Call Centre or a Help Desk now, doesn’t mean that those functions can’t evolve into a more extendable service and provide the benefits we have already discussed.

Where do I begin to implement a Service Management process?

Posted in ITIL at 4:30 pm by Molly

Consider implementing a Service Management (SM) process using the tried and tested method of planning and creating a PROJECT (something like PRINCE2 methodology);

Set your GOALS, OBJECTIVES, SCOPE, KPIs, CSFs down into documents;

Obtain your organisation’s management COMMITMENT and FUNDING for the project;

Define all ROLES & RESPONSIBILITIES of the resources that will be required for the project and outline the resources required for the actual process being implemented too;

Write and develop the SM PROCESS, PROCEDURES and if a POLICY does not exist, create one;

Mount an AWARENESS CAMPAIGN to overcome the lack of commitment from the customers and users, and don’t forget your 3rd party service providers;

Procure, develop and configure the necessary TOOLS that will be used within the new process;

Give great consideration to TRAINING needs, not only the training towards the tools but also towards the process, so run education workshops, explain the process, don’t just write it down in a manual that sits closed on people’s desks, bring it alive;

Develop your implementation plan, develop the AUDIT requirements where necessary and your procedures for implementing this process. Using your project management experience, produce the milestones and project plan charts, constantly review your milestones, and keep to the target dates, because your awareness campaign has generated interest, you want to keep that interest alive;

Once your process is in place, pay close attention to a REVIEW of the process and procedures. After all you want them to work, so you may need to make sure that any creases are ironed out quickly. Remember to version control your documentation and place them all into the CMDB (if you have one) otherwise try and get them published somewhere where everyone can find them (your internal website, intranet, portal page, etc ..)

January 20, 2009

Key Performance Indicators (KPIs) for SM processes

Posted in ITIL tagged , , at 4:03 pm by Molly

What are they?

First, we have to understand what they are before we can understand how and why we need them. A KPI is a metric, a type of report or value you use to measure or show the success of your Service Management (SM) process (this is an ITSM blog). You will want to use them and understand them in greater depths, so that you can target failures in the existing process and maybe kick-start a Service Improvement Program (SIP).

Why do we need to know about these process failures?

Your organisation doesn’t want to have a failing or ineffective Release Management process does it? Think about all those illegal, pirated, and beta versions of software that are floating around amongst your staff. Now consider the consequences of an external audit (it may well happen with a large financial institution). Does your organisation really want and can it afford to appear in the next morning’s press with the headline “€1Million fine for illegal software/downloads at ABC”? This would be a big wake-up call for your management team and if you are part of this Release Management team, you will probably consider a new career. So you see, it is important have visibility of, not only your own process but all the other interfacing and underpinning processes too, because they may directly or indirectly affect yours. KPIs also assist with your process strategy, which feeds further up the management ladder and produces the management strategy for the whole organisation.

KPIs are measured in percentages (%) or number(s) of something. Let’s look at a few examples, and let’s consider our Release Management process.

    Number of implementations (releases) bypassing Change Management;
    Number of incidents caused by releases; (this would be a hard pill to swallow)
    Number of failed releases;
    Number of urgent releases in the current quarter; (could another process be failing for this to occur?)
    Number of releases not adequately tested;
    Number of releases implemented late;
    % of releases without back-out plans;
    % of releases that failed during the testing phase … due to incorrect configuration information; (another process is involved here, is that process failing in some way?)
    % reduction of illegal software decommissioned in the live environment … during a certain period; (a nice management information success story for the Board of Directors – shows you’re on the ball with this one)

Do you see what we are trying to achieve?

We are identifying positives & negatives of the process, and whether it is or has improved or reduced over a period of time. This in turn, will help us identify whether the Release Management process is at fault, or whether there are interfaces into Release Management from other processes that are causing these errors. Ideally, we want to collect information that will be useful, so that is another topic entirely – the collection of USEFUL DATA. How do you scope the data you want to collect to improve your process? That is entirely up to you and probably your management team. Obviously you don’t want to be spending huge amounts of time as well as computer resources gathering all this information (hopefully you won’t be slowing down the network!).

Know what you want to report, identify what is important to the business, keep the other data for yourself, it could be useful to have a baseline.
Give management the bottom line in plain business speaking language, don’t fluff it up with technical jargon either, but also justify your data (back up your arguments).

How can KPIs be useful to me?

KPIs can kick start some process improvement program/plan, can identify where the bottlenecks are occurring, can maybe identify staff who are ‘doing something incorrectly’ which you may take action upon (further education, more training, sticking the procedures manual on their desk) and it can identify other processes that are causing you failures or reductions in service. Remember this isn’t a ‘blame game’, you should just be highlighting areas within your team where improvements can be identified, curbed, and improved so that your team or your process can function efficiently and effectively.

Let’s look at this minor scenario: “Joe has been a tester in your team for six months, he gets the job done, but he constantly keeps forgetting to get his test plans signed-off by you, the Release Manager. What hasn’t been identified yet are that all Joe’s release units create more incidents when they are released into the live environment. This is starting to annoy the users and in turn the Service Desk manager too.”

As the responsible owner of this process, what are you going to do about it? Do you care that this minor deviation in your process is going unnoticed? Is it going unnoticed by the users or other team members or management? Are you getting it in the neck at management meetings when the Service Desk manager once again pipes up that releases are causing more incidents? Are you the bad guy, the guy who doesn’t manage his team, the guy who is costing the company money, money that could be better spent on hiring a configuration librarian or further training elsewhere in the organisation. Will you sit on your laurels now – surely not!

Why then is it useful to have these KPIs for our little scenario? What possible benefit can you gain from knowing why releases are causing many more incidents? For one, you will stop getting it in the next from all the other managers at those management meetings. For two, you can identify within a short period of time both what and where the problem is occurring. For three, you can take Joe aside and ask him why he isn’t getting his test plans signed-off. Actually, he may just have forgotten because he’s been so busy, but what if he hasn’t read the paragraph in the Release Procedures manual that says in bold red letters that he needs to get all his tests signed-off before going into the rollout planning phase. Obviously you will have some pleasant words with Joe and make him understand his actions are causing more incidents, leads to more time resolving these incidents, leads to more RFCs being raised to resolve these incidents, leads to further release units and finally more work for Joe!

Nip problems in the bud early, by early identification, and how best to do that is to keep one eye on those reports!

N.B. Your process is only as good as the people who use it.

Keep it ITIL conformant, but if you see that an additional tweak or improvement can be made to it, try it out first before putting it into your Policy or Procedure. That improvement might help your organisation stay ahead of the game.