Tag Archives: ola

Is your service desk really a help desk in a fish costume?

Fish

Let me start with some honesty. I hate calling call centres. Every time I call I seem to loose a little bit of the will to live especially when they try and all call themselves all manner of different names, my recent favourite was ‘a customer experience agent’, when all I get is passed around, all telling me someone else should be dealing with my call or they will check and give me a call back, if I had a pound every time I was told that. A customer experience centre is still a bad call centre if I still get passed around and nobody really knows what to say or do.

I have just moved house and needed to register with British Gas (UK Gas and Electric utility company), I needed to do four things on the call:

– Give them all the details, name, address, occupation etc
– Set up a direct debit/giro so every month the right amount for the bill would be taken out of my account automatically.
– Register to add points to my nectar card, its a UK points card where I can get money off my supermarket shop
– Register for Hive, an awesome new system where I can control my  heating from my phone/tablet/computer and hive knows when I am coming home and leaving and switches on or off my heating accordingly.

Hmmm, so not too much that could go wrong. Immediately the person who picked up the call and heard what I wanted, paused, stuttered and said she needed to put me through to someone else. Already I am loosing the will, getting a little frustrated that I want to give them money but they are making it so hard, maybe a little harsh, but this has normally how it starts and only gets worse.

Then another lady picked up the phone and she nailed it, names and address…done, direct debit….done, nectar card points…done, hive…errr, never done one of these before, hold while she asked someone how to do it (this is not a problem, it is a new system so I thought I was probably a first), then bang I have an engineer coming out the following week.

Sill with me, wondering what this has to do with fish and ITIL. Well, recently I saw on a forum the title ‘How to change a help desk into a Service Desk’, the person had been tasked with changing a help desk into a service desk because that is what ITIL says and you can’t be ITIL compliant with out it. I thought, that is like calling a call centre agent a customer experience agent, a name doesn’t change a thing, it is what you do to change the perception of the customer that the team has changed.

People should ask How do I change my IT organisation into an ITIL IT organisation?’ rather then changing team names and think you are done.

I have worked in many support environments, all called many different names and some supposedly within an ITIL framework. However, I would say all were a help desk once you took away the nice names. A help desk to me, was and is, a team which takes all the calls about anything, tries to fix anything and if they can not then they have to beg, and plead, with other support teams to help them as there are no support agreements internally to get assistance. If the Help Desk can not get help then they hold onto the ticket and try over a few days to resolve it. The customer thinks the help desk is a little hit and miss, one customer even once said ‘why don’t you just call yourself, desk, instead of help desk.’

How does this differ to a Service Desk? This really is a trick question as if the organisation hasn’t changed to ITIL then the Service Desk is still just a Help Desk with a new name.

Please read my earlier blog posts to get an idea of what ITIL is about  :

https://itilbegood.com/2014/04/07/what-is-itil/

https://itilbegood.com/2014/07/19/service-management-as-a-rugby-game/

If the IT organisation wants to be an ITIL organisation, they should :

Have a catalogue showing the business what services are supported and the service desk knowing how these services are supported.

The services should be backed up with a configuration database, showing how these services are configured. the aim here is to give support engineers access to the latest configuration of the service with all the components to make troubleshooting easier so the service is resumed quickly. This is not an exercise in creating a database and ticking a box, it has to be usable and up-to-date. How the information should be presented should be after speaking to the stakeholder who will use this information. The database is a read and write database not a write database that nobody reads.

OLA’s should be written to show internal IT organisation resolution times for services, what is included and who can be involved in these fix times and how changes to these services should be implemented. If it comes in a 30 page document, ask yourself, if you were the engineer who just got a call saying nobody can access their e-mails, could you:

Would you know where then OLA is held?
How should the support teams escalate the incident?
Find out who should be on a bridge call to help fix it?
Use the configuration database to troubleshoot?
What support agreements with 3rd parties are in place?
What and who should communicate to the business the issue?
If an emergency change or a normal change needs to be implemented, how and who should do this?

All while users are screaming at you to fix it, if you feel you can’t, fix the documentation to make it easier. One suggestion would be to create a share point dashboard from the 30 page OLA document which support engineers can look to for easy reference.

After the OLA is created, SLA’s can be written which the business then knows how long an incident, request or outages should take to complete.

So, now the IT organisation knows :

What services are supported
How the services are configured
How the services are supported

Next, how does the business tell you they want something or something is broken. This is done through requests and incidents. The Service Desk should categorise the requests / incidents and add a priority to them. The priority comes from the OLA. When the service is restored to normal the incident is closed.

https://itilbegood.com/category/in-a-nutshell/

Overview of requests, incidents, problems : https://itilbegood.com/2014/07/28/requests-incidents-problems-and-known-errors-in-a-nutshell/

If an incident can’t be resolved definitively so a work around can only be used or an incident has been closed but the root cause could not be found. Open a problem, this can be worked on by an individual or a team of people to find the root cause and find the fix for the incident.

Though, ITIL is all about constant improvement there should be some sort of incident and problem management to analyse the incidents and problems to see if these can be reduced or done better through additional training or better procedures.

If you want to make a change to the service, a group of people (defined in the OLA) should assess the change in a regular meeting for proposed work, impact, back out plan, timings (is this within a change window defined in the OLA) and if the business needs to be aware, either by the business being in the same change meeting or a business communication, or both. This should minimise the impact to the business for any changes to services.

Finally, make sure there are some reports showing the business how IT is doing and the value provided. Maybe a report showing the number of changes (successful / unsuccessful), incidents (closure rate/time, categories), problems (types, closure rate, resolutions), SLA (within SLA and if not, what steps have been taken to rectify this)

Now the IT organisation knows :

How to log incidents and requests.
How to investigate incidents in more depth.
How to improve / spot trends with the incidents and problems process.
Make changes to services in a controlled way.

Finally, the IT organisation should put in place some method of improvement. Can areas of IT be improved to provide better service or value to the business?

If the IT organisation can provide these support structures to help the Service Desk, without them, the Service Desk is a Help desk still

Remember

Help Desk

Thankyou for reading my post. This is my opportunity to blog about a subject I love but am still learning. These posts are my way of showing how I understand the subject, however, I would encourage you to leave comments, did you agree / disagree with the post? Did I not explain something well enough or incorrectly? Do you want me to blog about another subject within ITIL? All feedback helps me to understand more. Thankyou.

 

 

 

Categories in a nutshell

Categories

I wanted to write this post to try and explain why we use categories in ITSM tools such as Remedy, Servicenow etc and why I think there is a need to be monitored regularly.

Lets start at the beginning, when logging and incident or request the team categorises the incident or request.

Please can I have Photoshop installed? – Category = Request – Software – Photoshop – Install

Or

I can’t connect to any network shares – Category = Incident – Network – Loss of network connectivity – Desktop

These categories choices are open to debate and discussion, that’s the beauty of ITIL, it is open to debate and a guide. You have to work out what works best for you and your company.

The next step in ITIL, remember you whole reason for doing ITIL is to provide value to the business, is to analyse these incidents in Incident Management. This should highlight trends, eg reviewing the incidents shows 30 calls per week to install photoshop, which is taking an engineer 30 mins per install to do. Maybe, this could be automated and therefore giving 15 hours back to the engineers and providing a better, quicker service to the business. More importantly, you can see trends with incidents, the incident with the network shares, you notice this happens to the same person every week at 2pm on a Tuesday. A reboot fixes this but it keeps happening and is probably a clue that a problem should be raised and looked at this in more detail.

One of the reasons to logged problems is if incidents are trending but the root cause isn’t found, then these can be looked into in more detail and hopefully finding the root cause. Once the root cause is found and resolved, then the incident shouldn’t happen again, meaning a happy customer and your engineers can work on something else. The whole point of incident management is to look at ways to reduce the number of incidents and requests.

However, how many categories do you have in your organisation? Could an incident be categorised few different ways depending on who picks it up? Are there duplications of categories / sub categories? How often do you look at your categories and check if they are still relevant and if some should be added or deleted?

These questions I think are the crux of why I think categories need to be monitored. Do you need all the categories / sub categories? When were each last used? A lot of ITSM tools has loads and loads of categories…….are they all used and would the engineers who are logging the incidents know which one to use or could they use a few different combinations? If so, are you sure your incident management trend analysis is picking up all the incidents and giving the true picture of what is happening week on week? How often are the categories reviewed? Do you still have a category for Windows Server 2000….do you have any servers still running Windows Server 2000?

A possible solution would be this; rip down the top level categories to your primary services in Service Catalogue eg Telecoms, E-mail etc. Using your engineers previous experience, reviewing any trends of incidents/requests and intuition make up some sub categories, limit the sub categories to less than 10 and add other to all these categories. This gives a better chance to trend incidents and requests in future. However, add ‘other’ to the sub categories so any incidents that don’t match the categories can be logged under the ‘other’ category. Create a workshop for engineers to explain which type of incidents/requests should be logged under which category and what the ‘other’ category is for and document this.

On a regular basis, initially, review the incidents and categories; looking at why the ‘other’ category has been used, does another category need to be added? This is fine-tuning the incident categories. Are the engineers using the right categories for the right types of incidents and requests?

On a bi yearly basis, a review of all categories should take place, are these still all relevant? Does some need to be deleted or added? Are you able to see trends and are you taking steps to reduce them?

I hope this shows how important getting categories right and making sure these are monitored to keep them in check.

Thankyou for reading my post. This is my opportunity to blog about a subject I love but am still learning. These posts are my way of showing how I understand the subject, however, I would encourage you to leave comments, did you agree / disagree with the post? Did I not explain something well enough or incorrectly? Do you want me to blog about another subject within ITIL? All feedback helps me to understand more. Thankyou.

 

Service Management as a rugby game

ITSM rugby

I realise the game of rugby might not be the most obvious analogy which springs to mind when you think about Service Management but hear me out.

Rugby, for me, has always been a great spectator sport; I have more the physique of the ball and not the man mountains of players. I marvel at the discipline these giants display for the game and how the game does not descend into a bar room brawl with so much muscle and will to win in such a small area.

When I think about great IT customer support, it is all about the skills of the individuals and the hand over to other support teams. How skill and great hand overs to other support teams can win or lose the IT support game. IT support is always a battle between resolving the issues efficiently without taking too much time and customer frustration increasing.

Picture the field, the IT organisation vs Customer Frustration and Time. The whistle blows, it is game time!!! The ball goes into the IT service desk scrum and the incident ball comes out to the IT organisation’s support team, the first line engineer is running with the incident ball only to be put to ground by Time. Over the top comes support from the second line teams, the ball is handed over to the second line engineer seamlessly, the engineer side steps Customer Frustration with clear communication. Oh no, Time comes in, tackles the ball and is now running with it, second line support chases the ball down. Time’s lead is growing with Customer Frustration following up quickly behind but Time is skilfully tackled by second line and runs the ball back, the final ball is handed over to the third line engineer. The fastest and most experienced players on the field with lightning footwork the ball goes down for the try and the incident is resolved.

Without great hand over’s of the ball, Customer Frustration and Time would get the ball and the value for money for all the business areas, who have paid money to see the IT organisation win, isn’t seen. If the support individual cannot hand the incident ball off to each other, individual player must try and jink past the opposition to try and close the incident. This sometimes will work based on the skill of the individual support engineer and the ease of which the incident could be closed, but sometimes it will not. If the IT organisation can win with individual skill, great hand over’s and team work then the business areas sees the value of paying to come support the IT organisation.

The other thing I enjoy about rugby, and most other sports, is the analysis of all parts of play, the breakdown and repeats of every tackle, shot, space the players should of used etc.

This is the area, where the service management team comes in, the coaches. They can take apart the play; they see the 1st line engineer fumbles the ball on pick up. A work around could be designed for the present game but a problem could be created to go away and really analyse the issue to come up with a fix, maybe a grip on the some gloves or a textured ball to make it less slippery. Communication between the second and third line support teams might be poor so the ball was intercepted and needing to be won back. Encouraging better communication between the two leads to be better and more fluid play.

Various areas of improvement could be categories, like in the ITSM tools, to be later broken down into target areas eg running down the line, communication, creating space etc, which can be work upon away from the game in set areas of expertise.

The service management team can also look at the agreements between the various team members showing who is going to take the hand off ball and who is going to come and protect the ball. This goes some way to designing an OLA. An agreement between the IT organisations showing how an incident should be handled, the support timings and items covered by the agreement. This should be in a format, that in the heat of play, can be easily understood and quickly.

Documenting how set piece of play should be played. Making sure all team members know what is required and how to do something is also an important part of the Service Management team’s job.

IT service management is all about creating value for the business areas and the best customer experience. The play might not be the finish article and individuals and team might need some work, but if the IT organisation is committed to ITIL and service management, they will work at these areas, making small and large gains and improvements. Reminding why the business areas pay for their IT organisation and the value it creates.

Hopefully I have gone some way to try and convince you that rugby and IT service management are not too dissimilar after all.

Thankyou for reading my post. This is my opportunity to blog about a subject I love but am still learning. These posts are my way of showing how I understand the subject, however, I would encourage you to leave comments, did you agree / disagree with the post? Did I not explain something well enough or incorrectly? Do you want me to blog about another subject within ITIL? All feedback helps me to understand more. Thankyou.