Table of Contents
Many companies these days have moved to some form and implementation of ITIL (Information Technology Infrastructure Library). The reason for this is simple; it is a good framework to organize your support by. Another reason is that "everyone is doing it" and if you have been in an environment like this, you are likely to have some negative experiences with ITIL.
ITIL is a set of practices and procedures that an organization can use to manage IT operations. Within ITIL are definitions for operational procedures and practices related to all aspects of an IT operation. That means ITIL is quite large and comprehensive with information for both managers and IT personnel.
ITIL was first created by the CCTA, a part of the UK government, which has now been merged into the OGC (Office of Government Commerce). ITIL is a registered trademark of the OGC. The library has kept evolving and at the time of this writing has arrived at version 3. The main volumes, which are being published by TSO Books, are ITIL Service Strategy, ITIL Service Design, ITIL Service Transition, ITIL Service Operation, and ITIL Continual Service Improvement.
Certification for ITIL is available at three levels; Foundation Certificate, Practitioners Certificate, and Managers Certificate. Many organizations expect all IT personnel to have at least the Foundation Certificate. These certificates are useful in the IT world, because it has helped to ensure that people can communicate about IT operations with a common vocabulary.
The following is a discussion of the parts of ITIL that I have based the discussion of different activities on. It may help you map the information in this part of the book to the processes and activities in your organization if your organization uses ITIL in any way.
Service desk is not a process, but nevertheless an important function in the service support set. The main focuses of the service desk are incident management and communication. The service desk handles all incoming requests and escalates them to second or third level support if necessary. Ideally the service desk is the single point of contact for all users. This way the service desk can really streamline all communication and, if the service desk has access to a knowledge base with known issue solutions and workarounds, they can also provide very direct information about a broad range of requests.
An incident is an event which disrupts or reduces the quality of a service and which is not part of the standard operation. Basically this is a very broad category of issues. Any piece of software or system that is part of the IT operation infrastructure supported can have a number of issues, most of which are presented as incidents. Incidents are often much of a catch everything that does not fit elsewhere tool. The service desk will handle most of these incidents as they appear and from my point of view the service desk should be responsible for catching patterns of recurring incidents so they can be fed into the problem management work process.
A problem is the unknown cause of an issue (incident) or a number of issues. The process of problem management deals with finding the root cause of the issues and defining actions to be taking to prevent the problem from occurring again. In some cases it is not possible to find a solution for the problem and a known issue with optional workarounds can be logged. If a known issue is found and a solution is found for the known issue, this will often lead to a request for change.
Change management is aimed at controlling changes to the IT services provided to minimize the negative impact of these changes to the end user. The change management process is important in any IT environment to make sure that all changes that get implemented are maintainable and well thought through by all parts of the IT organization. Change management within ITIL calls for the definition of policies and change procedures, it also suggests a dedicated change manager and the establishment of a Change Advisory Board that approves all changes and assigns them as projects to people in the IT organization.
Configuration management is a more advanced level of asset management. The goal is to maintain a database with information about all IT assets, named configuration items, to facilitate many other processes with impact analysis, adherence to legal obligations, software changes and updates visibility, providing real information to problem management, and so on. Configuration management normally does more than listing the hardware and software used by users. It deals with information about the network infrastructure, server configurations, and end user desktop configurations. In short it helps you to know not just what you have (asset management) but also how the things you have interact and are linked into configurations.
Service level management is the process that has to be put in place to make sure IT service quality and scope are aligned with business needs at an acceptable cost for the business customers. It deals with monitoring the current service levels and reaching constant agreement with customers regarding the level of service provided. Not that I am using customers here, not users. The customer is the party that determines the required level of service based on business needs and budgets available. As an IT professional that is tasked with delivering service you will normally not be part of the negotiation process involved in the service level management process, but I think it is important to know why it is in place to better understand your responsibilities. For instance, it is important to understand what your priorities should be to best match the agreed upon service levels. Also, you should know what reporting should be possible to extract from the work you do. You can help this process greatly by making your work transparent to your manager and to actively ask to be appraised based on service level improvement goals.
What can go wrong, will go wrong is the basic message of Murphy's law. O'Tool wisely commented that Murphy was an optimist. IT service continuity management deals with plans to recover from serious incidents, also commonly referred to as disaster recovery plans. This is critical to any IT operation in my eyes. If you do not plan for disaster when you are managing the information infrastructure of a large company you are at high risk. Your company would not be the first to go under due to a serious event where all server systems are lost. Although it is likely that you are not going to be the person responsible for these plans for disaster recovery, you should be aware of them. If disaster strikes, what is your role in the plan?
There is more to IT service than described in ITIL. ITIL provides foundations of procedures needed to have a well oiled service delivery machine. It helps to separate tasks and assign people to specific areas of responsibility. But there is more. One of the things that I have found lacking is complaint handling for instance. Knowing how to act when a complaint is filed is very important to raise customer satisfaction. Customer satisfaction surveys are referenced as being needed often, and key performance indicators, a management tool for gathering information about how well you are doing, are described for all ITIL processes as well. There is little information provided to help you implement and use these tools. In the chapters below you will find some help with a few key areas and a possible way to implement them. If you wish to learn more about ITIL, I suggest you have a look at the open ITIL library (www.itlibrary.org) or better yet, order the books published by TSO and learn the ITIL way of organizing support. The primary goal of this book is not organizing support, it is delivering support. So studying ITIL could be a valuable addition to reading this book.