Service Support

The "Service Support" elements of ITIL tend to focus on the day to day management and maintenance of IT services.  

If ITIL was a car, Service Support would represent your annual service, MOT, the odd running repair and keeping all of those bits of paper together just in case you ever get pulled over!

They are broken down as follows:

Service Desk - this is the only ITIL "component" that is not a process but an actual function. The Service Desk should be the single point of contact for all users in the event of them raising a concern or request around IT service. Normally, the service desk would be in possession of a call logging tool and every call would be given a unique reference number. This is then used to trace the progress of the request. The tool would allow information about the issue to be captured and basic reporting about how long the call has been open should be available. For small companies, the Service Desk could be as simple as a nominated person (or group of people) who have access to a simple database or spread sheet allowing you a single point of contact and the ability to have visibility of your IT issues.

Incident Management - the process that the Service Desk follows when getting a call from a user about their IT systems. Incident Management has a simple focus - get the users working as quickly as possible! This may be through the use of a documented workaround or known procedures. If these don’t exist, the Incident Management process ensures that the callers issue is chased on a regular basis. This is particularly important if you have agreed service levels with your suppliers!

Problem Management - sometimes it goes wrong in a big way! That’s where problem management comes in. Complimenting Incident Management, the problem manager carries out 3 distinct roles:

1) Major Incident Management - this means ensuring that all of the fixers are working together and that they are aware of any deadlines that need to be met. If it looks like they wont, the problem manager is responsible for driving out the ideas for   contingency plans. Sometimes this means leaving the system down longer than needed so the real root cause can be found (and hopefully the method to prevent it happening again can be identified).

2) Reactive Problem Management - when problems happen, the problem manager is responsible for documenting the root cause, identifying process and system failures and then creating and managing an actions list to prevent it from happening again.

3) Proactive Problem Management - this element focuses on stopping problems happening before they have chance to get a hold. Predominantly this includes reviewing all of the incidents from the Incident Management process and looking for trends. Once these are identified, actions are recommended to stop them reoccurring or escalating to an unmanageable level.

Change Management - One of the biggest causes of IT system failures is change. Upgrading an operating system (including Microsoft patches!), loading a new program, adding a piece of hardware or changing your business process is all guaranteed at some point to stop your computer systems from behaving normally. The more complex and inter-dependent you services are, the bigger the influence of change on your availability.

Change Management bring’s control into this minefield by introducing some basic principles:

1) Approval - all changes must be approved by an agreed group of people who have the ability to say NO if it is deemed as to risky.

2) Testing - the change process drives awareness of testing. It is incredible how many changes are implemented without them ever being tested but by asking the question and insisting on a clear demonstration of the testing, the approval process becomes much easier.

3) Back out - If you can change it, you can normally back it out if it goes wrong. But is it just as easy as that? Does old data need to be restored? Was a backup taken before the change took place and how long will the back out actually take? The approval cycle once again requests clear back out instructions as part of its process.

Configuration Management - knowing what PC's you have is asset management. Configuration Management goes one step further and identifies how IT systems are dependent on each other. Each component is captured with additional information including dependencies to other components. Now if your main server fails you know exactly what department need it and what hours they work.

This sounds easy? Very few large organisations have Configuration Management in place because it is just too big a subject to tackle once you have services distributed over many sites and linked into multiple services and network points. The benefit for small companies is the fact that the smaller scale makes this discipline so much easier to implement.

Release Management - when do you upgrade? That’s where release management comes in. One of the most simplest of the processes, this is all about having a clear strategy for your IT services. At a simplistic level each service would have a "Release Plan". This would normally state things such as:

©2006 Nuts and May Ltd