Providing Affordable IT Management to SME's Service desk - next steps
In my first blog covering the Service Desk and the Incident Management process, I mentioned that the purpose of Incident Management is to restore the service as quickly as possible therefore getting the user back working. For a small business this could mean protection and the continued satisfaction of a key existing or possibly a new customer. So once the call is actually logged, how do we go about restoring the service without the need to wait for a technical supplier? Well within this blog I would like to explain some concepts that may help
1) First Time Fixes (FTF’s) – This is a term applied to any action that can be taken by your “service desk” person without the need of calling on someone else.
Examples could be:
a. Your application has a password system and if you put in the wrong password 3 times, the application lock you out and you have to go into an administration section to reset it
b. Giving advise on how to use an application or aybe how to select a different printer
c. Loading a piece of software to allow a certain task to be carried out (eg flash player)
You will notice, that as a general rule, these type of first time fixes are not based on problems or where something is not working, but the day to day type of administration tasks needed to keep more complex IT equipment working. Regardless of this the aim is quite simple – to remove the need of going to second line support.
Why? Because every time you go to 2nd, 3rd, 4th line support you increase the cost of your support which inturn reduces your profits. To make first time fixes work for you, a key success factor is how you record them. The worse possibility is that you rely on retained knowledge because when people leave, the knowledge goes out the door with them. A simple system (which can be paper based) should be set up, with each first time fix recorded. A title, explanation of the fault and the required steps should be recorded in a format that is easily understood and then once it is required, it should be tested by two independent people (as the writer may miss steps or record them at a shallow level of detail to fit their level of knowledge). Once the fix has been signed off, it can be filed and used by your “incident manager” once it is needed
2) Known Errors and Workarounds So what is a known error and how does it differ to a FTF ? Well to simplify it I tend to focus on the following:
A first time fix is an action taken by the service desk to get a user working, normally due to a process that happens on a regular basis BUT is an expected part of the service (eg users will always forget their passwords, on want help on how to spell check an email etc). A known error occurs when a “fault” with your computer system occurs, you know what has caused it and you also know how to get around it. The fault itself is not fixed but you have a short term way of dealing with it via a “workaround” (by the way, if an unexpected fault occurs, you do not know what has caused it but you can still carryout a workaround, this is referred to as a “problem” but that’s another topic ….).
It’s OK to have known errors in your infrastructure and even to live with them for a long period of time. In fact large organisations due to the complexity of their systems and the cost of making changes, decide to run for many years with known errors. The key thing is balancing the impact of when the error occurs (and the potential loss of revenue) against the cost of getting it fixed. Therefore, if a good workaround can be found which restores the service back in an acceptable period of time; this can sometimes be just as affective as paying to get it fixed. As with FTF’s, all known errors should be documented and the workaround clearly defined, recorded and tested. When you “service desk” then takes a request from a user about a fault they are experiencing, the list of known errors can be checked and if you have a workaround recorded, the service can be restored quickly without the need to call out any 2nd line support (which may extend the time of the service being down or cost you additional money).
As part of this blog, I also said I was going to start talking about trend analysis. Well to get you thinking, I would like you to consider the type’s of problems you have with your computer systems? Are they around a certain application or piece of hardware ? Maybe they occur at specific times of the day/week or are more common around a specific user or group of users ? All of these questions can help you with your IT support and by understanding the type of issues you have (which in ITIL terms are referred to as “Incidents”) you should be able to target any spend around the areas that are going to give you the biggest benefit. The starting point for this has to be a well defined process for recording your incidents (your single point of contact) and a method to capture some basic information (a service desk tool). If anyone would like a simple call logging tool (written in Excel or Access) please contact us.
16th April 2009
Click here for details of our FREE business healthcheck and join the rest of the companies using IT Service Management.