Providing Affordable IT Management to SME's The expanded incident lifecycle part 2
We ended the last chapter of this topic by saying that we can help ourselves shorten the downtime by focusing on the following key phases:
1. “Detection elapse time”. This is how long it takes the user to report the fault once they have noticed it
2. “Response time” is how long it takes whoever is fixing it to start working on the problem. For some contract’s this may be a contractual key performance indicator
3. “Repair time” is how long it takes to get the service back into an operational state. Once again, this may be contractual
4. “Recovery time” is how long it takes to get users back onto the system once it has been fixed
So how can an SME with limited or no IT staff help themselves in this area?
Well really we need to focus on 1 & 4 above and this is where good incident and problem management start to come into it. We have already discussed in previous threads, how the service desk is the starting point of good ITIL practices, but most SME’s can not afford an investment in either people or toolsets to deliver this core principle. But it does not have to be complex and the easiest way to shorten step 1 above is have a nominated IT contact which is publicised to everyone in your organisation.
In doing this you may have to consider shift patterns (so a designated deputy may be worthwhile), but either way, your staff need to know who to talk to if they have an IT “issue”. Once this person in place, a basic call logging tool can be developed to take basic information such as their name, department, contact number and the nature of the problem they are having (not forgetting to also capture the date & time). It is normally good practice to issue them with a call ref number, so a sequential numbering system on an excel spreadsheet would do it.
Now what we have just talked about is the “theory” of ITIL, but what does this really mean to a SME? I would hazard a guess that you culture is not about being a mini IT department, what you want to do is focus on your core business. So let me put another slant on it (not from the ITIL book). If you really want to reduce the first phase of the incident lifecycle you really need to develop a culture / awareness within your staff to report anything about their IT equipment that does not seem to be normal. It could be as simple as the PC seems to take longer to boot up or the odd pop up message that they get every now and again. Why is this important? Well firstly they will get into the habit of noticing when things are not right and hopefully reporting them (which should help spot future more serious problems and also provide you with the starting point of trend analysis) but more important if people are use to and comfortable reporting the minor problems, when you do have a more serious issue, they will be conformable reporting it and will know who to go to.
Remember the aim here to reduce the total incident duration by looking at each component of the incident lifecycle. The starting point is the lag from the user identifying they have a problem to the point that they report it.
Next we need to look at recovery time. This is the period of time between the service being restored and the users getting back onto the system. Once again, it is worthwhile looking at this from the pure ITIL viewpoint and also how an SME would implement this. The communication to the user that service has been restored would normally come from the service desk as one of the final parts of the incident management lifecycle. In terms of our “simplified service desk”, this would mean the person who entered the incident onto our spreadsheet, contacting the user and letting them know that everything is OK now. Likewise if it was more of a major incident where multiple users were impacted, it may result in several people being told. Once again, the focus here is on reducing the elapsed time between the service being fixed and the users getting back on.
So what does this mean in reality? Well it will be different for every SME, but it all comes down to efficient communication. You may be a factory operation with a large production floor which has lost its main LAN. Utilising a tannoy system could communicate the service restoration to all users in a matter of seconds. A loss of you ISP (which results in downtime for your email service / internet use) may be best communicated to an office on several floors by having “super-users” in each team who receive the initial message and cascade it out to others.
Hopefully this chapter has been of some use and should give you a couple of pointers in shortening your incident duration. Obviously the ideal step is to look at setting up a simplified “service desk” and call logging process but even as a minimum it may be worth looking at how you would communicate both the failure and restoration of you core systems in a way that suites your organisation. Next time we will look at the other two steps which involve your engagement with the supplier / fixers.
8th Nov 2009