ITIL Service Management is made up of eleven core process disciplines, document to two books, Service Support and Service Delivery.

Service Support

·     Configuration Management

·      Change Management

·      Release Management

·      Incident Management

·      Problem Management

·      Service Desk

Configuration Management

The object of Configuration Management is to provide a logical model of the IT infrastructure by identifying, controlling, maintaining and verifying the version of all Configuration Items in existence.  Configuration Management is used to

• account for all IT assets,
• provide accurate information to support other Service Management processes,
• provide a sound a base for Incident, Problem, Change and Release Management,
• verify records against infrastructure and
• correct exceptions.

There are five basic activities of Configuration Management:

1. Planning - The Configuration Management plan should cover the next three to six months in detail, and the following twelve months in outline. Review it twice a year at least. Include:

o      a strategy,

o      policy,

o      scope,

o      objectives,

o      roles and responsibilities, 

o      Configuration Management processes, activities and procedures, 

o      CMDB,

o      relationships with other processes and third parties, as well as

o      tools and other resource requirements. 

2.    Identification - The selection, identification and labeling of all CI's. This covers the recording of information about CI's, including ownership, relationships, versions and unique identifiers. CI's should be recorded at a level of detail justified by the business need.

3.    Control - This gives the assurance that only authorized and identifiable CI's are accepted and recorded from receipt to closure. It ensures that no CI is added, modified, replaced or removed without the appropriate controlling documentation. For example, approved RFC and updated specification. All CI's will be under Change Management control.

4.    Status Accounting - The reporting of all current and historical data concerned with each CI throughout its life-cycle. It enables changes to CI's and tracking of their records through various statuses. Examples: ordered, received, under test, live, under repair, withdrawn or closed.

5.    Verification and Audit - This is a series of reviews and audits that verifies the physical existence of CI's, and checks that they are correctly recorded in teh CMDB. It includes the process of verifying Release and Configuration documentation before changes are made to the live environment.

Change Management

The object of Change Management is to ensure that standardized methods and procedures are used for efficient and prompt handling of all changes, in order to minimize the impact of any related Incidents upon service.  Changes in the IT infrastructure may arise either

• reactively in response to problems or externally imposed requirements, e.g. legislative changes, or
• proactively from seeking imposed efficiency and effectiveness or to enable or reflect business initiatives, or from programmers, projects or service improvement initiatives. 

Change Management can ensure standardized methods, processes and procedures are used for all changes, facilitate efficient and prompt handling of all changes, and maintain the proper balance between the need for change and the potential detrimental impact of changes.

Change Management is responsible for controlling change to all CIs within the live environment.  It is not responsible for change within ongoing projects, which are controlled by the project change process.  However, close liaison between development project managers and the Change Manager is expected.  Change Management would typically comprise the raising and recording of changes, assessing the impact, cost, benefit and risk of proposed changes, developing business justification and obtaining approval, managing and coordinating change implementation, monitoring and reporting on implementation, reviewing and closing RFCs.

Release Management

The object of Release Management is to take an holistic view of a change to an IT service and ensure that all aspects of a release, both technical and non-technical, are considered together.

Release Management should be used for large or critical hardware roll-outs, major software roll-outs and bundling or batching related sets of changes.  Release management co-ordinates the many service providers and suppliers involved with a significant release of hardware, software and associated documentation across a distributed environment.

Release Managements is responsible for planning and overseeing the successful roll-out of new and changed software and associated hardware and documentation, liaison with Change Management to agree exact content and roll-out plan for the release, ensuring that all items being rolled out or changed are secure and traceable via the CMDB and managing Customers and Users expectations of releases and roll-outs.

Incident Management

The object of Incident Management is to restore normal service to operation as quickly as possible with minimum disruption to the business, thus ensuring that the best achievable levels of availability and service are maintained.

Use Incident Management to

• support the business,
• develop and maintain meaningful records relating to incidents, and
• devise and apply a consistent approach to all incidents reported.

Incident Management is responsible for incident detection and recording, classification of all incidents, and initial support, investigation and diagnosis, resolution and recovery, incident closure, and incident ownership, monitoring, tracking and communication.

Problem Management

The object of Problem Management is to minimize the adverse effect on the business of incidents and problems caused by errors in the infrastructure, and to proactively prevent the occurrence of incidents, problems and errors.

Use Problem Management to

• resolve problems quickly and effectively,
• ensure resources are prioritized to resolve problems in the most appropriate order based on business needs,
• proactively identify and resolve problems and known errors thus minimizing incident occurrences,
• improve the productivity of support staff, and
• provide relevant management information.

Problem Management is responsible for problem identification, recording, classification, investigation and diagnosis.  Problem Management is also concerned with

• error identification,
• recording, assessment,
• recording of resolution,
• closure,
• monitoring resolution progress,
• assistance with the handling of major incidents,
• proactive prevention of problems through trend analysis,
• targeting support action, and
• providing information to the organization, as well as obtaining management information from problem data and completing major problem reviews.

Service Desk

The object of the Service Desk is to act as the central point of contact between the user and IT Service Management.  To handle incidents and requests, and provide an interface for other Service Management activities, such as:

• Change,
• Problem,
• Configuration,
• Release,
• Service Level, and
• IT service Continuity Management.

The service desk, unlike the other ten disciplines (processes), is a function essential to effective Service Management.  More than just a Help Desk, it is the principal operational interface between IT and their Users.  A good first impression by each of its Users is predicted upon its performance and attitude.  Often a stressful place for staff to work, underestimating its importance, high profile and the skills required to perform the duties well can severely hinder an organizations ability to deliver high quality IT services.

After the ITIL re-write took place, the change of name from help desk to service desk demonstrates the broader role of front line support – with more organizations looking to radically increase the percentage of calls closed at first point of contact.

The main reasons organizations are investing in service desks now are that they

• provide a single point of contact for users,
• enable them to deliver high quality support critical for achieving business goals,
• help to identify and lower the cost of ownership for IT services as a whole,
• support changes across business, technology and process boundaries,
• help to aid user retention and satisfaction, and
• assists in the identification of business opportunities.

Most of the activities carried out by the service desk fall under the responsibility of one of the IT Service Management processes.  The role and responsibilities of the service desk will depend upon arrangements that the organization has put in place.  Among the tasks commonly assigned to the service desk are to

• receive and record all calls from users,
• deal directly with simple requests and complaints,
• provide initial assessment of all incidents,
• make first attempt at incident resolution and/or refer to 2^nd line support, based on agreed service levels,
• monitor and escalate all incidents according to agreed service levels,
• keep users informed on status and progress, and
• produce management reports.

Service Delivery

·       Service Level Management

·       Capacity Management

·       Financial Management

·       Availability Management

·       Continuity Management

Service Level Management

The object of SLM is to maintain and gradually improve business aligned IT service quality, through a constant cycle of agreeing, monitoring, reporting and reviewing IT service achievements and through instigating actions to eradicate unacceptable levels of service.

SLM ensures that the service targets are documented and agreed to in SLAs, and monitors and reviews the actual service levels achieved against their SLA targets.  SLM should also be trying to proactively improve all service levels within the imposed cost constraints.  SLM is the process that manages and improves agreed level of service between two parties, the provider and the receiver of a service.

SLM –

• Negotiates and agrees to service requirements and expected service characteristics with the customer,
• measures and reports of service levels actually being achieved against target, resources required, and cost of service provision, 
• continuously improves service levels in line with business processes, with a SIP,
• coordinates other Service Management and support functions, including third party suppliers,
• reviews SLAs to meet changed business needs or resolving major service issues, and
• produces, reviews and maintains the Service Catalogue.

Capacity Management

The goals of Capacity Management are to:

• understand the future business requirements (the required service delivery), the organization’s operation (the current service delivery), the IT infrastructure (the means of service delivery), and
• ensure that all current and future capacity and performance aspects of the business requirements are provided cost effectively.

Capacity Management is responsible for ensuring that IT processing and storage capacity provision match the evolving demands of the business in a cost effective and timely manner. 

The process includes:

• monitoring the performance and the throughput of the IT services and supporting IT components,
• tuning activities to make efficient use of resources,
• understanding the current demands for IT resources and deriving forecasts for future requirements,
• influencing the demand for resources in conjunction with other Service Management processes, and
• producing a capacity plan that predicts the IT resources needed to achieve agreed service levels.

Capacity Management has three main areas of responsibility:

1. BCM, which ensures that the future business requirements for IT services are considered , planned and implemented in a timely fashion.  These future requirements will come from business plans outlining new services, improvements and growth in existing services, development plans etc.  This requires knowledge of existing service levels and SLAs, future service levels and SLRs, the business and capacity plans, modeling techniques (Analytical, Simulation, Trending and Base-lining), and application sizing methods.
2. SCM, which focuses on managing the performance of the IT services provided to the Customers, and is responsible for monitoring and measuring services, as detailed in SLAs and collecting recording, analyzing and reporting on data.  This requires knowledge of service levels and SLAs, systems, networks, service throughput and performance, monitoring, measurement, analysis, tuning and demand management.
3. RCM, which focuses on management of the components of the IT infrastructure and ensures that all finite resources within the IT infrastructure are monitored and measured, and collected data is recorded, analyzed and reported.  This requires knowledge of the current technology and its use/application, future or alternative technologies, and the resilience of systems and services.

Financial Management for IT Services

The object of Financial Management for IT Services is to provide cost effective stewardship of the IT assets and the financial resources used in providing IT services.

Financial Management for IT Services is an integral part of Service Management.  It provides the essential management information to ensure that services are run efficiently, economically and cost effectively. 

An effective financial management system will:

• assist in the management and reduction of overall long term costs,
• identify the actual cost of services and their provision,
• provide accurate and vital financial information to assist in decision making,
• identify how IT adds value to the customers business,
• enable the calculation of TCO and ROI,
• make customers aware of what services actually cost (if appropriate),
• support the recovery, costs from customer, in a fair and equitable manner,
• provide measurements of value for money,
• provide incentives to produce quality services aligned to business needs,
• help influence customer behavior,
• provide incentives for using non-critical resources, and encourage more efficient use of resources,
• provide better cost information and control of external contracts and suppliers, and
• assist in the assessment and management of changes.

Financial Management for IT services –

• enables the organization to account fully for the costs of  IT services and to attribute these costs to the services delivered to the organization’s customers,
• assists management decisions on IT investment by supporting detailed business cases for changes to the IT services,
• controls and manages the overall IT budget and
• enable the fair and equitable recovery of costs (by charging) for the provision of IT services.

Availability Management

The object of Availability Management is to optimize the capability of the IT infrastructure and supporting organization to deliver a cost effective and sustained level of availability that enables the business to satisfy its objectives.

Availability Management ensures services are available when the cstomer needs them and is influenced by business demand, the cost required to meet it, the configuration and complexity of the IT infrastructure including the level of redundancy, the reliability of the infrastructure and its components, the levels of infrastructure maintenance, and the processes and procedures used by IT services and the human factors and external events.

Availability Management –

• optimizes availability by monitoring and reporting on all key elements of availability,
• determines availability requirements in business terms,
• predicts and designs for expected levels of availability and security,
• produces the availability plan,
• collects, analyzes and maintains availability data and reporting on that data,
• ensures service levels are met by monitoring service availability levels against SLAs,
• monitors OLA targets and external supplier serviceability achievements, and
• continuously reviews and improves availability.

IT Service Continuity Management

The object of IT Service Continuity Management is to support the overall business continuity management process by ensuring that the required IT technical and services facilities can be recovered within required and agreed business time-scales.

IT Service Continuity Management is concerned with managing an organization's ability to continue to provide a pre-determined and agreed level of IT services to support the minimum business requirements, following an interruption to the business. This included:

• ensuring business survival by reducing the impact of a disaster or major failure,
• reducing the vulnerability and risk to the business by effective risk analysis and risk management,
• preventing the loss of customer and user confidence, and
• producing IT recovery plans that are integrated with and fully support the organization's overall business continuity plan. 

IT Service Continuity –

• ensures that the available IT Service Continuity options are understood and the most appropriate solution is chosen in support of the business requirements.
• identifies roles and responsibilities and makes sure these are endorsed and communicated from a senior level to ensure respect and commitment for the process. 
• guarantees that the IT recovery plans and the Business Continuity Plans are aligned, and are regularly reviewed, revised and tested.

ITIL, as a philosophy, still has some way to go, but it has the wholehearted support of everyone and anyone that wishes to provide a common approach to high quality IT Service Management.

Implementing an ITIL framework can and will involve a lot of hard work. You are bound to face problems, but nothing that you can’t overcome, and nothing that won’t lead to future benefits for you and your organization.

As more and more organizations, software vendors included, become increasingly dependent on IT services, it is surely to everyone’s benefit to work within a common framework that has a common goal of providing unified, integrated and consistent IT Service Management for our customers, whoever they may be.

Why do I need ITIL?

ITIL is not a standard or a method as such, but can be considered a combination of the two, an approach which enables business to technology communication, because it formalizes and integrates related processes using a common language that anyone else using ITIL can understand.

A common language might not seem very important to some but it is vital to accurate and efficient communication and without excellent communication systems your business will waste vast amounts of resource trying to get the work done.

For example: Let’s take a simple change that has been reported by phone to IT support. A monitor has developed a fault.

One process might be to raise a trouble ticket that describes the fault, to pass it to an engineer who does the site visit who creates a Maintenance Report describing the work performed.

Sounds simple, but only if you know what a “trouble ticket” is and what a “maintenance report” is and who is allowed to complete them under what circumstances and then, of course, what happens to them.

Many organizations (and many software vendors) use different terminology to mean the same things and the same terminology to mean different things.

For example: Change, Problem, Error, Bug, Defect, Incident, Engineering Change Request, Change Request, Request for Change, Maintenance Report, Maintenance Request and so on.

ITIL takes this language and suggests terminology to suit.

An incident is reported:

1. One or more incidents creates a Problem
2. A Change is identified to resolve the Problem
3. A Request for Change (RFC) is created
4. RFC’s are bundled together for Release

ITIL also suggests the processes that should be used at each phase.

ITIL processes: 

• are industry recognized and therefore provide you with an excellent foundation on which to build;
• save you the trouble of having to construct your own processes, and then wonder if they are as effective as they need to be; and
• reduce the costs involved with creating your own processes.

Remember though, ITIL processes are not set in stone, but provide a framework which can be adjusted to suit your specific needs.

For example, if we take the Change management aspect of ITIL, we can draw up a process chart representing how an organization might handle a “Request for Change (RFC)” according to ITIL.

ITIL suggests that if the change is a standard change – that is, it is common and has an easily recognizable solution – a “Change Manager” should review the change and initially prioritize it deciding impacts, resources required and whether it should be fast tracked.

Your organization may not have a “Change Manager” dedicated to this activity or even anyone nominated as such but the procedure that ITIL suggests is still sound. A number of people may be involved and are responsible for various aspects of what ITIL suggests the “Change Manager” should do.

ITIL also recommends that a close relationship is maintained between Project and Change Management which, if you think about it, is a very much a common-sense approach.

What do I need to do if I want to use ITIL in my organization?

Getting yourself trained and qualified in ITIL is always a good start, but many organizations don’t have the training budget. Even if they do it is not always convenient for you to go off on training courses. The job needs to be done now.

So there are many things you can do without training, because ITIL is really a reflection of common sense.

Let’s start at the beginning. You think you need ITIL, so there must be a reason why you think that way.

So, the first thing to do is document that reason and see what other people around you think. Identify the people in your organization that may be impacted by adopting ITIL and involve them as much as possible in the following steps:

Weaknesses

Identify current weaknesses, actual and perceived. Don’t forget the perceived ones, because they are just as real to people as the actual ones, and they need to be resolved just the same. Prioritize the weaknesses in terms of business benefit, should they be resolved.

Solutions

Propose solutions to the weaknesses that you have identified. Use your experience and the ITIL suggestions such as the recommended process flows, to come up with your initial solutions in conjunction with the stakeholders you identified at the start.

Costs

Identify costs and other resource issues (including timescales, process changes, cultural impact on the organization, people and the skills and supporting tools they will require) that are impacted either directly or indirectly by your solution.

Benefits

Identify the benefits – a vital but tricky part, in that you are not going to get sign-up by others in your organization unless they can see that it is going to be of benefit Quantifiable benefits (such as man hours saved) are fairly easy to identify. Unquantifiable ones (such as process improvement) are much more difficult, but just as important, so use all of the stakeholders to help you. Consider measuring the impact a change currently has:

·       How long does it take

·       How much of the usual service has been lost and for how long whilst the change is in progress

·       Who is aware of the change, and who should be aware and is not, and what is the impact of the difference between the two

·       Could you take on a significant amount of change, or is this one in particular stretching you to your limits?

·       What will the reduction in re-work be if you put policies/guidelines into place to improve your process, such as extra quality assurance or longer testing times?

·       If we are talking about software changes, we might be able to identify the number of incidents that are reported following a delivery of the software.

·       Find software tools that:

o      Cover the areas that are appropriate to you,

o      Help you implement your processes,

o      Enable you to use your terminology, and

o      Provide the necessary links between Change and Project Management.

Sounds like a lot of work!

There is a lot there, but if something is worth doing, we should at least try to do it properly. That is also what ITIL is about.

What problems might I face in implementing ITIL?

Here are some of the more common problems we have faced when helping people implement ITIL in the change and configuration management arena. We suspect they are common to more than just this arena – and more than just ITIL – but they are problems nonetheless.

·       Top Down Commitment

·       Resistance to change

·       Where to start

·       Lack of training

·       Lack of resource – people

·       Lack of planning

·       Lack of existing software support tools such as change and configuration management tools

·       Vendor influence – in that the software does it this way so you have to as well.

·       Cost justification

·       Exception planning

·       Culture shock

·       End users by-passing procedure

How you can get the help and support you need? You can look to the software vendors here.

Naturally, to be successful you need the support of your organization at all levels. You also need the support of the software vendors as you search for software that can help you.

The best vendors realize that:

·       Only by working closely with their clients can they gain the correct understanding of the client’s requirements.

·       Only by understanding their client’s business can those all important requirements be put into their correct context.

·       Only by correctly identifying the context can they really provide the support and the service levels that their clients deserve.

Why is effective IT service management (ITSM) important for financial services companies?

IT service management fosters and encourages IT departments to fully engage with the business in order to meet its needs in a quality-controlled, cost-effective and measurable manner. The introduction of BS 15000 (the standard for service management) is proof that both IT and the business are working together to cement the relationship.

How can effective IT service management improve performance?

How many facets has a diamond?! Effective service management is a series of service improvement programs – each facet of which should be designed with performance in mind. The definition of performance is up to the business to decide.

What is ITIL, and why is it important?

ITIL – the IT Infrastructure Library – is a series of books that provides a framework for best practice based upon real-life, within real organizations. Originally there were 40 books. These were updated a couple of years ago and condensed into the seven publications available today. ITIL is the foundation stone of IT service management, which we encourage people to ‘adopt and adapt’ to meet the needs of their business. Many other systems are based upon it, for example Microsoft’s Operations Framework is essentially ITIL tailored for a Microsoft environment.

What are the challenges of implementing ITIL?

There are many indeed, the main one is buy-in. This must be achieved at all levels – both financially and culturally. The former is difficult in itself, as justifying a return on investment can be complex due to the tangible and intangible nature of the benefits likely to be achieved. Increased availability to a bank could mean saving hundreds of thousands of pounds or not losing customers, but assessing and measuring the return on such a benefit would be a massive challenge. It is also important not to try to implement everything at once – it will not work! ITIL is a framework that allows you to implement a series of targeted improvement programs. Choose an area, measure where you are, decide where you want to be and look at the gaps. Remember that quick wins can provide confidence and a springboard for larger improvement programs.

How will ITSM evolve in the future?

Specifically, the OGC, which owns ITIL, has announced an ITIL refresh – version 3. I anticipate this version will have processes that will be seen to encourage, foster and facilitate a change culture within any organization. Generally, I believe that IT will continue to integrate with the business, eventually developing into more of a symbiotic relationship, with both relying on each other to ensure survival in a given market place. Who needs the ‘IT’ in ITSM then?