Wednesday, 10 March 2010

Planning, problems and incidents

In the middle of our planning round at the moment so very busy. Checking financial forecasts for next year, and planning for different financial scenarios - it won't surprise anyone that none of them actually involve us getting more money than now..... Also articulating our key activities for UEB and trying to work out the costs of them and how we demonstrate value for money. Producing a service catalogue as part of our ITIL implementation (more later) has made this easier, but actually costing our services is a bit of a black art, but more work is being done. Key objectives for next year being worked on, as well as their critical success factors.

Yesterday we had a good meeting looking at progress on the different aspects of ITIL we're implementing - I've already posted about change management, and yesterday we were looking at progress on our service catalogue which is going well, and incident and problem management. In terms of incident management, we have to first define what an incident is, and we had been using a definition of any significant service failure whether planned or unplanned, but as planned should be covered by the change management processes, we're changing the definition to unplanned only. And then - what's an incident - any service failure reported to the helpdesk? If Dr X rings to say his printer's not working is that an incident? It's a service failure to him. So, if you define everything as an incident, you have to have a good method of determining the level of an incident. This is where you need to take account of SLAs, OLAs (operational level agreements), Impact assessments, the calendar of activities etc. Who decides on the level of an incident, and how much can be automated by our helpdesk software?

Of course, the purpose of incident managment is to restore normal service as soon as possible, and to minimise the adverse effect on business operations. Incidents have to be identified, logged, categorised, prioritised, diagnosed, resolved and closed. All of this is under the control of the helpdesk (note - not the actual fixing). The incident is then reviewed.

In summary:

Communicate -- Fix -- Communicate


We're also drawing up procedures for problem management, the purpose of which is to reduce recurring incidents and these follow a similar cycle of:
  • Detection
  • Logging
  • Review
  • Prioritisation
  • Investigation and diagnosis
  • Resolution
  • Review
I'm pleased with the way everything is going so far and look forward to the day these processes are embedded and we have no incidents or problems to manage...

2 comments:

cattwell said...

Not sure whether all incidents or problems are channeled via the CiCS helpdesk, I am thinking about some of HR services which have their own helpdesk, support mechanisms. Should incidents or problems with these systems be looked at by CiCS ? and if so how will they be captured ?

james said...

We have a similar situation in Portsmouth where the bulk of our requests and faults are reported to the Service Desk, but we still have local support arrangements and requests to providers being managed by email inboxes. This is something we are working on but its slow going. We are changing the way people have worked for years and altering the level of service our users have come to expect.