C. ITIL IT Service Management Beginners Guide v7.1

V 7.
GPO Box 2673 Brisbane, QLD 4001 Australia Ph: +61 7 3252 2055 http://theartofservice.com
'
Beginners notes
IT Service Management with ITIL
A Service lifecycle approach
The Art of Service Pty Ltd 2007 All of the information in this document is subject to copyright. No part of this document may in any form or by any means (whether electronic or mechanical or otherwise) be copied, reproduced, stored in a retrieval system, transmitted or provided to any other person without the prior written permission of The Art of Service Pty Ltd, who owns the copyright.
Copyright: The Art of Service Pty Ltd 2007
Version 7.1
Table of Contents
START HERE....................................................................................................................................................................5 CONCEPTS OF ITIL........................................................................................................................................................5 ITIL SERVICE MANAGEMENT COURSES................................................................................................................7 IT SERVICE MANAGEMENT........................................................................................................................................8 INTRODUCTION TO IT SERVICE MANAGEMENT PRACTICES.............................................................................................8 ITIL SERVICE MANAGEMENT..................................................................................................................................10 PROCESSES......................................................................................................................................................................12 PROCESSES, SERVICES AND FUNCTIONS.........................................................................................................................13 ITIL OVERVIEW............................................................................................................................................................15 BENEFITS OF ADOPTING ITIL ........................................................................................................................................................................................16 IMPLEMENTING ITIL SERVICE MANAGEMENT PRACTICES........................................................................20 IT SERVICE MANAGEMENT TOOLS.......................................................................................................................23 ITIL SERVICE MANAGEMENT PRACTICES AND VENDORS...........................................................................24 CORE OF PRACTICE:...................................................................................................................................................25 PURPOSE..........................................................................................................................................................................29 PRINCIPLES......................................................................................................................................................................29 MAIN ACTIVITIES............................................................................................................................................................29 SERVICE STRATEGY PROCESS: FINANCIAL MANAGEMENT FOR IT SERVICES....................................30 SERVICE STRATEGY PRACTICE: DEMAND MANAGEMENT .........................................................................31 SERVICE STRATEGY PRACTICE: SERVICE PORTFOLIO MANAGEMENT.................................................32 SERVICE DESIGN..........................................................................................................................................................33 PURPOSE:........................................................................................................................................................................33 PRINCIPLES:.....................................................................................................................................................................33 ACTIVITIES:.....................................................................................................................................................................34 SERVICE DESIGN PROCESS: SECURITY MANAGEMENT................................................................................35 BASIC CONCEPTS.............................................................................................................................................................35 OBJECTIVES.....................................................................................................................................................................35 BENEFITS.........................................................................................................................................................................36 PROCESS..........................................................................................................................................................................36 ACTIVITIES......................................................................................................................................................................37 POLICY............................................................................................................................................................................37 RELATIONSHIPS WITH OTHER PROCESSES.......................................................................................................41 SERVICE DESIGN PROCESS: SERVICE CATALOGUE MANAGEMENT.......................................................47 GOAL...............................................................................................................................................................................47 OBJECTIVE......................................................................................................................................................................47 SCOPE..............................................................................................................................................................................47 2
V 7.1
SERVICE DESIGN PROCESS: SUPPLIER MANAGEMENT................................................................................48 GOAL...............................................................................................................................................................................48 OBJECTIVE......................................................................................................................................................................48 SCOPE..............................................................................................................................................................................48 SERVICE DESIGN PROCESS: AVAILABILITY MANAGEMENT.......................................................................50 GOALS.............................................................................................................................................................................50 OBJECTIVE......................................................................................................................................................................50 SCOPE..............................................................................................................................................................................50 SERVICE DESIGN PROCESS: CAPACITY MANAGEMENT................................................................................52 GOAL...............................................................................................................................................................................52 OBJECTIVE......................................................................................................................................................................52 SCOPE..............................................................................................................................................................................52 SERVICE DESIGN PROCESS: IT SERVICE CONTINUITY MANAGEMENT...................................................54 GOAL...............................................................................................................................................................................54 OBJECTIVE......................................................................................................................................................................54 SCOPE..............................................................................................................................................................................55 SERVICE TRANSITION................................................................................................................................................56 PURPOSE:........................................................................................................................................................................56 PRINCIPLES:.....................................................................................................................................................................56 MAIN ACTIVITIES:..........................................................................................................................................................56 SERVICE TRANSITION PROCESS: TRANSITION PLANNING AND SUPPORT.............................................57 GOAL...............................................................................................................................................................................57 OBJECTIVE......................................................................................................................................................................57 SCOPE..............................................................................................................................................................................58 SERVICE TRANSITION PROCESS: SERVICE VALIDATION & TESTING......................................................59 GOAL...............................................................................................................................................................................59 OBJECTIVE......................................................................................................................................................................59 SCOPE..............................................................................................................................................................................60 SERVICE TRANSITION PROCESS: EVALUATION...............................................................................................61 GOAL & OBJECTIVE........................................................................................................................................................61 SCOPE..............................................................................................................................................................................61 SERVICE TRANSITION PROCESS: SERVICE KNOWLEDGE MANAGEMENT.............................................62 GOAL...............................................................................................................................................................................62 OBJECTIVE......................................................................................................................................................................62 SCOPE..............................................................................................................................................................................62 SERVICE TRANSITION PROCESS: CHANGE MANAGEMENT.........................................................................64 GOALS.............................................................................................................................................................................64 OBJECTIVE......................................................................................................................................................................64 SCOPE..............................................................................................................................................................................64 SERVICE TRANSITION PROCESS: RELEASE & DEPLOYMENT MANAGEMENT......................................66 GOAL...............................................................................................................................................................................66 OBJECTIVE......................................................................................................................................................................66 SCOPE..............................................................................................................................................................................67 SERVICE TRANSITION PROCESS: ASSET & CONFIGURATION MANAGEMENT......................................68 GOAL...............................................................................................................................................................................68 OBJECTIVE......................................................................................................................................................................68 SCOPE..............................................................................................................................................................................68
Copyright: The Art of Service Pty Ltd, 2004-2007
V 7.1
SERVICE OPERATION.................................................................................................................................................70 PURPOSE:........................................................................................................................................................................70 PRINCIPLES:.....................................................................................................................................................................70 MAIN ACTIVITIES:..........................................................................................................................................................70 SERVICE OPERATION FUNCTION: SERVICE DESK ..........................................................................................71 SERVICE OPERATION FUNCTION: TECHNICAL MANAGEMENT.................................................................73 ROLES.............................................................................................................................................................................73 OBJECTIVES.....................................................................................................................................................................73 SERVICE OPERATION FUNCTION: IT OPERATIONS MANAGEMENT.........................................................74 ROLES.............................................................................................................................................................................74 OBJECTIVE......................................................................................................................................................................74 SERVICE OPERATION FUNCTION: APPLICATION MANAGEMENT.............................................................75 ROLE...............................................................................................................................................................................75 OBJECTIVES.....................................................................................................................................................................75 SERVICE OPERATION PROCESS: EVENT MANAGEMENT..............................................................................76 GOAL...............................................................................................................................................................................76 OBJECTIVE......................................................................................................................................................................76 SCOPE..............................................................................................................................................................................76 SERVICE OPERATION PROCESS: REQUEST FULFILMENT............................................................................77 GOAL...............................................................................................................................................................................77 OBJECTIVES.....................................................................................................................................................................77 SCOPE..............................................................................................................................................................................77 SERVICE OPERATION PROCESS: ACCESS MANAGEMENT............................................................................78 GOAL & OBJECTIVE........................................................................................................................................................78 SCOPE..............................................................................................................................................................................78 SERVICE OPERATION PROCESS: INCIDENT MANAGEMENT........................................................................79 GOAL & OBJECTIVE........................................................................................................................................................79 SCOPE..............................................................................................................................................................................79 SERVICE OPERATION PROCESS: PROBLEM MANAGEMENT ............................................................................................................................................................................................81 GOAL...............................................................................................................................................................................81 OBJECTIVE......................................................................................................................................................................81 SCOPE..............................................................................................................................................................................81 CONTINUAL SERVICE IMPROVEMENT................................................................................................................83 PURPOSE:........................................................................................................................................................................83 PRINCIPLES:.....................................................................................................................................................................83 MAIN ACTIVITIES:..........................................................................................................................................................83 KEY DOMAINS OF CSI.................................................................................................................................................84 KNOWLEDGE MANAGEMENT .........................................................................................................................................84 PLAN, DO, CHECK, ACT..................................................................................................................................................84 BASELINES......................................................................................................................................................................84 MONITOR, MEASUREMENT & METRICS..........................................................................................................................85 C.S.I PROCESS: SERVICE LEVEL MANAGEMENT..............................................................................................86
V 7.1
Start Here.
This document is designed to answer many of the questions about IT Service Management and the ITIL Framework. The document has evolved over many years and offers the reader the chance to quickly learn through reading and re-reading a lot of the theory behind ITIL (IT Infrastructure Library). It provides answers, but it will also raise some questions for the reader. It is a beginners document. It tells stories.
A pre-requisite for reading this document is that you have worked through the Fact Sheets and understand the core of each ITIL Process.
Many questions about ITIL are answered in this document.
Concepts of ITIL
On the following page you will find a picture of how the ITIL framework is structured around the various Service Lifecycles. You can use this illustration as a guide while you read through the rest of the document where we give you a summary of each of the processes and function in each book of the ITIL Framework.
Version 7.1
Version 7.1
ITIL Service Management Courses

After reading this beginners guide you may wish to attend formal ITIL Service Management certification course. When you attend a course, the course trainer will typically present the course subject (ITIL Service Management Practices) through slides, discussions and exercises. The exercises are generally based on a case study. The Fact sheets give an overview per process on the goal, activities and results. This syllabus gives some more information on ITIL Service Management Practices to prepare the course participant for the ITIL Service Management Practices Foundation exam. It provides some additional reading material, internet-links and evidence of ITSM implementations. When provided with the course material the itSMF booklet provides a summarised overview of the ITIL processes with concise descriptions and diagrams.
ANECDOTE
The investment of time and money in preparing to sit for an ITIL Service Management Practices Exam is perhaps a time for most adults that bring back the fear of sitting for tests of any kind. ITIL Service Management Practices Exams are by their very nature designed to indicate if the participant can understand and apply the theory knowledge of the ITIL Service Management Practices Framework. The ITIL Service Management Practices Exam can be taken at a variety of levels. ITIL Exam ITIL Service Management Practices Foundations Certificate Most ITIL Exams taken around the world are at this level. ITIL Exam ITIL Service Management Practices Practitioner Certificate ITIL Exams at this level test process knowledge for a specific cluster of processes ITIL Exam ITIL Service Management Practices Managers Certificate ITIL Exams in this category are for those faced with challenges of implementation. ITIL Exams for the Foundations certificate can actually be taken at any Prometric test centre around the world. ITIL Exams in the other two levels must currently be sat as a paper based test, facilitated independently.
Version 7.1
IT Service Management
Introduction to IT Service Management Practices
Most organizations now understand the benefits of having Information Technology (IT) throughout their structure. Few realise the potential of truly integrating the IT departments objectives with the business objectives. However, more and more organizations are beginning to recognize IT as being a crucial delivery mechanism of services to their customers. When the IT services are so critical, steps must be in place to ensure that the IT group adds value and delivers consistently. So the starting point for IT Service Management (ITSM) and the ITIL Service Management Practices Framework is not technology it is the organizational objectives. To meet organizational objectives, the organization has business processes in place. Examples of business processes are sales, admin and financial departments work together in a sales process or logistics, customer service and freight who have a customer returns process. Each of the units involved in these business processes needs one or more services (eg. CRM application, e-mail, word processing, financial tools). Each of these services runs on IT infrastructure. IT Infrastructure includes hardware, software, procedures, policies, documentation, etc. This IT Infrastructure has to be managed. ITIL provides a framework for the management of IT Infrastructure. Proper management of IT Infrastructure will ensure that the services required by the business processes are available, so that the organizational objectives can be met. Historically, these processes delivered products and services to clients in an off-line environment (the brick-and-mortar companies). The IT organization provides support to the back-office and 8
V 7.1
admin processes. IT performance is measured internally as the external clients are only indirectly influenced by the IT performance.
Today, with online service delivery, the IT component of the service delivery can be much stronger. The way of delivering the service is IT based and therefore internal and external clients measure the performance of the IT group. Service delivery is more important than a glimpse of brilliance every now and then. The internal clients (business processes) and external clients need availability of the IT services and to be able to expect a consistent performance. Consistency comes through the ability to repeat what was done well in the past. IT Service Management is a means to enable the IT group to provide reliable Information Systems to meet the requirements of the business processes, irrespective of the way these services are delivered to the external customers. This in turn enables the organization to meet its Business Objectives.
Version 7.1
ITIL Service Management

Any organization that delivers IT services to their customers with a goal to support the business processes, needs inherent structure in place. Historically, that structure was based around functions and technical capabilities. With the ever-increasing speed of change and the associated need for flexibility a technology driven approach (in most situations) is no longer appropriate. That is why IT organizations are looking for alternatives. Some alternatives include: Total Quality Management TQM processes and continuous improvement projects COBIT as a control & measurement mechanism CMM for control and structure in software (and system) development ITIL Service Management Practices for operational and tactical management of IT service provision
Which single or combination of frameworks selected is entirely dependant on the needs of the organization. For many IT organizations, ITIL is a very good way of managing service delivery and to perform the IT activities in end-to-end processes. Further research and reading on other COBIT CMM EFQM Six Sigma Deming British Standards Institution The Balanced scorecard models and frameworks: http://www.isaca.org/cobit.htm http://www.sei.cmu.edu/cmm/cmm.html http://www.efqm.org/new_website/ http://www.ge.com/sixsigma/ http://www.deming.org http://www.bsi.org.uk http://www.balancedscorecard.org/basics/bsc1.html
ANECDOTE
A lot of organisations are looking at ways of implementing ITIL Service Management Practices and CMM. The challenges of implementing ITIL and CMM tend to centre more on people issues, rather than the pure theoretical content of the frameworks. CMM of course is a framework established to guide software developers through the challenges of creating solutions that are truly aligned with business requirements. ITIL Service Management Practice is a framework that has been developed to guide IT Managers through the challenges of managing their IT infrastructure. The two frameworks are complementary and those faced with implementing ITIL Service Management Practices and CMM need not be concerned about any potential clash or duplication of effort between the two. The CMM measurement model is actually a 5 category measurement model. Most people think that ITIL is also a 5 level model, but there are actually steps between the 5 levels in ITIL (making 9 measurement levels altogether).
10
V 7.1
11
Version 7.1
Business Integration
By implementing IT Service Management in your IT organization you support the IT objectives of delivering services that are required by the business. You cant do this without integrating the IT strategy with the business strategy. You cant deliver effective IT services without knowing about the demands, needs and wishes of the customer. IT Service Management supports the IT organization to integrate IT activities and service delivery, with business requirements.
Processes
IT Service Management helps the IT organization to manage the service delivery by organising the IT activities into end-to-end processes. These processes have no functional boundaries within the IT group. A process is a series of activities carried out to convert an input into an output. Information flow into and out of each process area will indicate the quality of the particular process. We have monitoring points in the processes to measure the quality of the products and services provided. Processes can be measured for effectiveness (did the process achieve its goal?) and efficiency (did the process use the optimum amount of resources to achieve its goal?). The potential measurement points are at the input, the activities or the output of the process.
Generic Process
Norms Measure
Input Activity Activity Goal

Source: the Art of Service
Output Activity
25
12
V 7.1
The standards (or norms) for the output of each process have to be defined such that the complete set of processes meets the corporate objectives. If the result of a process meets the defined standard, then the process is effective. If the activities in the process are also carried out with the minimum required effort and cost, then the process is efficient. The aim of process management is to use planning and control to ensure that processes are effective and efficient.
Processes, Services and Functions

Most businesses are hierarchically organised. They have departments, which are responsible for a group of employees. There are various ways of structuring departments, for example by customer, product, region or discipline. IT services generally depend on several departments, customers or disciplines. For example, if there is an IT service to provide users with access to an accounting program on a central computer, this will involve several disciplines. To provide the accountancy program service the computer centre has to make the program and associated database accessible. The data and telecommunications department has to make the computer centre accessible, and the PC support department has to provide users with an interface to access the application. Processes that span several departments can monitor the quality of the service by measuring aspects, such as availability, capacity, cost and stability. IT Service Management to match these quality aspects with the customers demands. ITIL Service Management Practices provide a concise and commonsense set of processes to help with the management, monitoring and delivery of services. A process is a logically related series of activities for the benefit of a defined objective. The following diagram illustrates cross functional process flows.
13
V 7.1
With ITIL we can study each process separately to optimise its quality. The process manager is responsible for the process results (i.e. is the process effective). The logical combination of activities results in clear transfer points where the quality of processes can be monitored. The management of the organization can make decisions about the quality of an ITIL process from data provided by each process. In most cases, the relevant performance indicators and standards will already be agreed upon. The day-to-day control of the process can then be left to the process manager. The process owner will assess the results based on a report of performance indicators and whether they meet the agreed standard. Without clear indicators, it would be difficult for a process owner to determine whether the process is under control or if improvements are required. We have discussed processes and we have positioned services. We have highlighted the difference between functions and processes. Functionally structured organizations are characterised by: Somewhat fragmented Focus on vertical and functional matters With many control activities Emphasis on high/low people relationships In functionally driven organizations we may often see: Concept of walls or silos; not my responsibility A hint of arrogance - We in IT know whats good for you. Steering people instead of steering activities Because we have to communication Politically motivated decision making In contrast once processes are introduced we often see a change towards: Entire task focus Horizontal processes focussed towards clients Control measurements that add value Interdependence and uniting leadership Interdependence of independent persons Accessibility of information This leads to a culture of: No boundaries, but interconnections Customer focused: what is the added value? Steering activities instead of steering people Communication because it is useful (fulfilling the needs of the customer) Decision making is matching & customising IT service provision is a process
14
Version 7.1
ITIL Overview
ITIL has undergone some intensive changes. Notably, the title of the framework itself has been changed. Once called the IT Infrastructure Library, ITIL is now known as ITIL Service Management Practices. So, whats in a name? The name change is a reflection of ITILs evolution, from an operationally focused set of processes to a mature service management set of practice guidance. In fact, ITILs entire vision is a holistic, value based, business focused service practice for today and tomorrows service management professionals. ITIL is the only consistent and comprehensive documentation of best practice for IT Service Management. Used by many hundreds of organizations around the world, a whole ITIL philosophy has grown up around the guidance contained within the ITIL books and the supporting professional qualification scheme. ITIL consists of a series of books giving guidance on the provision of quality IT services, and on the accommodation and environmental facilities needed to support IT. ITIL has been developed in recognition of organizations' growing dependency on IT and embodies best practices for IT Service Management. The ethos behind the development of ITIL is the recognition that organizations are becoming increasingly dependent on IT in order to satisfy their corporate aims and meet their business needs. This leads to an increased requirement for high quality IT services. ITIL provides the foundation for quality IT Service Management. The widespread adoption of the ITIL guidance has encouraged organizations worldwide, both commercial and non-proprietary, to develop supporting products as part of a shared 'ITIL Philosophy'. There is a wide range of products and services available. At the heart of ITIL and commercially independent are: ITIL Publications The qualification scheme itSMF, the not-for-profit and independent group of users and vendors Commercial companies provide consultancy, software tools and training. ITIL is a non-proprietary approach for managing IT services, developed in the 1980s by the Office of Government Commerce (OGC) in the United Kingdom. Now considered the de facto standard for managing a business focused, cost effective IT organization, the ITIL framework was recently redesigned from a process-led approach to a service lifecycle approach. This end-to-end view of how IT should be integrated with business strategy is at the heart of ITIL v3s five core volumes: Service Strategy which looks at overall business aims and expectations to ensure IT strategy maps back to them. Service Design which starts with a set of new or changed business requirements and ends with the development of a solution designed to meet the documented needs of the business. Service Transition which is concerned with managing change, risk & quality assurance and has an objective to implement service designs so that service operations can manage the services and infrastructure in a controlled manner. Service Operation which is concerned with business as usual activities. Continual Service Improvement which has an overall view of all other elements and looks for ways that the overall process and service provision can be improved. 15
V 7.1
The structure of V3 has matured into a service lifecycle format. ITIL itself has become a service and its Service Portfolio looks like this:
ITIL V3 Model
Service Strategy
Service Design
Service Lifecycle
Service Transition
The Technology
Source: ITSMF
Benefits of Adopting ITIL

During the 20 years of ITIL practice, it remains the worlds most widely recognized and adopted framework for IT Service Management. It has grown from a cottage industry in the 80s to a global influence. Over this time the many benefits of ITIL have become widely known and continue to grow as the community of practice matures. Whether you are a business customer, a service provider, a CIO or CEO, ITIL Service Management Practices offer benefits that demonstrate their value and return on investment. Some of the widely published benefits are: Non-proprietary practice - ITIL is owned by the Office of Government Commerce, a department of the UK Government. ITIL does not require a license to practice and it is independent of any commercial solution or platform. Scalable - ITIL can be adapted for any size of organization. This is a key benefit since the industry predictions for the growth of small to medium enterprise is a major developing trend. Reduce Costs - ITIL has proven its value in reducing overall cost of managing services. Improved Quality - ITIL helps improve the quality of IT services through sound management practices.
The Business
Service Operation Continuous Service Improvement

(CSI)
20
16
V 7.1
Aligned to Standards - ITIL is well aligned to the ISO/IEC 20000 Standard for Service Management. Qualification - ITIL supports the ITSM professional with a line of accredited training and education courses. ROI - ITIL helps IT organizations demonstrate their return on investment and measurable value to the business. This helps establish a business case for new or continuing investment in IT. Seamless Sourcing Partnerships - Outsourcing, often with multiple service providers, is increasingly common today. ITIL is widely practiced among industry service providers and offers a common practice base for improved service chain management.
Parties Involved
TSO APMG Tool Vendors EXIN itSMF ISEB ITIL Service Management Co-Authors OGC
Trade Mark owners
Accredited Vendors
24
ITIL is a pseudo Public Domain framework. ITIL is copyright protected. The ITIL Trademark is owned by the OGC. However, any organization can use the intellectual property to implement the processes in their own organization. Training, tools and consultancy services support this. The framework is independent of any of the vendors. APMG- In 2006 APMG won the tender to own the rights for accreditation and certification of the ITIL courses. EXIN and ISEB used to be independent bodies, but now sublicense through APMG. EXIN and ISEB are the examination bodies that organise and control the entire certification scheme. They guarantee that the personal certification is fair and honest and independent from the organizations that delivered the course. Both bodies accredit training organizations to guarantee a consistent level of quality in course delivery. At the time of writing the only generally recognised certification is awarded to individuals. There is no independent tool certification or organizational certification. People and organizations that wish to discuss their experiences with ITIL Service Management implementation can become a member of the IT Service Management Forum (itSMF). The itSMF is a meeting place for users and adopters of ITIL.
17
V 7.1
Further research and reading on other models and frameworks: (web sites are active at time of writing use the search topic on the left in your internet search engine for more information) ITIL website www.itil.co.uk OGC website www.ogc.gov.uk EXIN www.exin-exams.com ISEB www.bcs.org.uk Vendor sites www.itsmdirect.com www.itilcollege.com www.itsm-learning.com www.itilsurvival.com www.itil-itsm-world.com
18
V 7.1
ANECDOTE
The itSMF is a member funded organisation for IT Service Management Professionals. The IT Service Management Forum (itSMF) is a non-profit organisation wholly owned, and principally operated, by its members. It is also a major influence on and contributor to Industry Best Practices and Standards across the world regarding IT Service Management standards and qualifications and has been for many years. Why do businesses and organizations need the itSMF? Businesses depend more and more on technology to promote and deliver their products to market. Service Management has become the primary critical success factor focused on achieving this aim. Outsourcing, demands on IT to deliver more business value and partnerships all visualize the need of adopting Best Practice IT Service Management and of becoming part of the itSMF. Why do individuals need the itSMF? The itSMF provides an accessible network of industry experts; information sources and events to help you address IT Service Management issues. As well as to assist you in the delivery of high quality, consistent IT service internally and externally through the adoption of Best Practice. You will be able to network among your peers and continually build your competence. The benefits of being able to draw from the experiences of literally thousands of individuals and organisations involved in ITIL are incalculable. itSMF Aims To develop and promote Industry Best Practice in service management To engender greater professionalism within service management personnel To provide a vehicle for helping members improving their service performance To provide members with a relevant forum in which to exchange information and share experience with their peers on both sides of the industry
Membership itSMF members are drawn from across industry, commerce and public sector. Most members represent "user" organisations that are responsible for delivering quality IT services to their customers and the remainder represent the leading IT service and product providers. Many of the leading blue chip companies are to be found amongst the user membership. Globally, the itSMF now boasts thousands of individual and corporate members.
19
V 7.1
Implementing ITIL Service Management Practices

Introduction
ITIL Service Management Practice is something that impacts the entire IT organization. Implementation of end-to-end processes can have a big impact on the way things are done and can initiate a lot of uncertainty and resistance with staff. For these reasons, it is important to implement ITIL Service Management Practices with a step-bystep and steady approach. The following model is an example of such an approach.
Developing ITIL processes is a fairly easy job to do! Making sure everybody understands the processes and uses them is more difficult and requires serious planning. It is advisable to use a project management approach to ITIL Service Management implementation and stay focused on the clearly defined end results (many different Project Management methodologies exist. The trademark owners of ITIL (the OGC) publish a widely used Project Management methodology, called PRINCE2 (Projects in Controlled Environments).
20
V 7.1
Cultural change
A small part percentage of the implementation project will be about process design. Most of the challenge lies in cultural change and personal motivation of staff to use the end-to-end processes as the better way to do business. Any change leads to feelings of vulnerability and loss of control. These feelings generally manifest themselves through feelings of resistance. The most important thing in this stage of the ITIL implementation is to keep the focus on the reason why your organization needs ITIL Service Management in the first place.
Implementation Checklist
DOs:
Perform a feasibility study first Use what is already good in the organization Take it slowly and concentrate on small steps and quick wins Appoint a strong project manager with end-to-end focus to drive this implementation program Keep in mind that you are dealing with personal issues Keep communicating WHY your organization needs this Measure your successes continuous Enjoy the milestones and share them with the IT group
DONT:
Try to mature all the processes at the same time Start with a tool Start without management commitment and/or budget ITILISE your organization its a philosophy, not an executable application Rush; take your time to do it well Go on without a reason Ignore the positive activities already in place
21
Version 7.1
ANECDOTE
ITIL is used by an ever increasing number of organizations to meet the growing demand on the IT service infrastructure. These are some of the benefits of implementing ITIL processes. ITILs most significant benefit is that it shows you what to do in terms of improving IT operations and how to do it. Now is an opportune time to apply the lifecycle principles to your environment and ensure that the service ethos of continual service improvement is an integral part of business as usual. Plus, with ITIL now as a base for an international quality standard (ISO/IEC 20000), your organization can receive independent verification of IT Service Management excellence. Among the many benefits, this standard provides organizations with a competitive edge in the RFP process and can be instrumental in audit preparation. Research confirms the benefits of the Version 3 ITIL approach which: Establishes the integration of business strategy with IT service strategy. Enables agile service design and a ROI blueprint. Provides transition models that are fit for purpose in a variety of innovations. Demystifies the management of service providers and sourcing models. Improves the ease of implementing and managing services for dynamic, high risk volatile and rapidly changing business needs. Improves the measurement demonstration of value. Identifies the triggers for improvement and change anywhere in the service lifecycle. Addresses the current gaps and deficiencies in ITIL today.
ANECDOTE
The traditional quality management system for organizations is ISO9000. In recent years, many major organizations have adopted the ITIL framework as their methodology for management of IT infrastructure. The ISO9000 and ITIL combination is in fact a very powerful one. There are a growing number of people aware of the benefits of ISO9000 and ITIL. As a matter of fact, since December 2005 there is now another ISO standard specifically aimed at certifying IT Service Management Processes (based on ITIL); this is the ISO 20000 standard. The primary distinction between the two is that while ISO9000 is focusing on business process quality, the ISO 20000 standard focuses on IT Service Management processes. Both ITIL and ISO 20000 are in a state of continual update and improvement. ISO20000 and ITIL both have well defined control mechanisms in place for ensuring that they reflect the current nature of business environments throughout the world. ISO is controlled by the International Services Organizations and ITIL is controlled by the Office of Government Commerce (OGC) in the United Kingdom. 22
V 7.1
IT Service Management Tools

Every IT organization uses tools to support its ability to deliver services and perform processes. The type of tool you need is dependent on what you want to get out of it. For small organizations, the tool can be an Excel Spreadsheet. For larger organizations, there are a great number of commercial tools to select from. Try to design your processes before you start looking for a tool. This gives you the opportunity to really do a thorough Functional and technical specification before talking to the vendors. A lot of research can be done using the Internet. Many (tool) vendors have a list of appropriate tools listed with the specifications.
Type of tools
There are many tools on the market. The following list gives an example of some of the tools that organizations use: Service Desk Tools / Support Tools Heat Infra Peregrine Service Centre Remedy System Management tools HP Openview Qualiparc CA Unicentre
The Cost of a Tool

When you have decided on a tool, you really need to have a close look at the cost. Most of the expenses are in getting the tool to work for you, the way you want it to. The following are some examples of the implementation cost of any tool: Initial Purchase Price Additional Licenses Maintenance contract Warranty Training of staff in using the tool Implementation expenses (consultancy hours) Fine-tuning the tool to your needs (consultancy and engineering hours) Updating the internal processes to fit the tool (consultancy and internal staff hours)
23
V 7.1
ITIL Service Management Practices and Vendors

A common mistake made by new adopters of ITIL Service Management Practices is trying to go it alone. Mistakenly, many new adopters feel that external consulting expertise adds prohibitive costs to their implementation. In many cases, the opposite is the case. Best practices are just that - proven over time and used in a variety of contexts to stand above all other practices. Many third party vendors offer the wisdom of experience in ITIL best practices and can greatly reduce the time and investment to get your ITIL practice up and running and to help establish proven business cases for additional improvement investment. IT service transformation often involves a shift in the vision and focus of an IT organization. This will often require organizational cultural change. Third party expertise is often a major selling feature in gaining unbiased, objective advice in ITIL Service Management Practice implementations and maturity improvements. The best of breed ITIL Service Management Practices consultant will have seen and heard it all before and will be well positioned to help you make the most compelling business case for ITIL adoption as well as providing the skills to get you there. ITIL V3 Service Management Practices devotes many pages of guidance, drawn from the experience of industry experts and will help guide you in managing organizational and cultural changes effectively to gain improvements in your service management practice. To some degree like anything else, navigating the vendor marketplace can be a buyer beware situation, so good advice is to follow the best practice trail! Seek out vendors that have proven track records with practical results. Ensure they can demonstrate their past experiences with situations relevant to your needs. Ask for references, and follow up with them. Look for providers that offer a variety of practice areas and end to end solutions. A good indicator of dedication in a vendors practice is one who is certified to the ISO/IEC 20000 Standard for service management. Large organizations often require that any vendor doing business with them is ISO certified. Seek out like-minded vendors who share your philosophy and vision for Service Management. Dont be afraid to ask tough questions. Many vendors are already preparing to help their customers transition to the new ITIL Service Management Practices. They are investing now in the knowledge and technical solutions that will meet the practice innovations of ITIL V3. This issue is so important that the ITIL V3 core books dedicate chapters of guidance on how to find the right vendor for your service needs and how to effectively measure performance and manage relationships with service management suppliers.
24
Version 7.1
Core of Practice:
At the heart of the practice is a set of core guides that revolve around the ITIL Service Lifecycle. The lifecycle is presented as a logical flow from Strategy, through Design, Transition, Operation and Improvement, but the real beauty of its structure is that it is entirely multi-dimensional. ITIL V3 uses a closed loop feedback system that provides feedback throughout all areas of the lifecycle. This is consistent with our real ITSM worlds - nothing is strictly linear. Although we view the flow of service management practice similar to the Deming cycle of Quality - Plan, Do, Check, Act - we know that rarely is real life IT service management quite so linear. So, ITIL has been redesigned in a way that encourages a logical flow, but is not restricted to a solely linear path for service management. The Service Lifecycle is illustrated in a hub and spoke design with Strategy at the core of practice and revolving stages of Design, Transition and Operation. The wheel is anchored by Continual Service Improvement which exerts its influence throughout the entire lifecycle. The core practice guides, listed in their logical flow are:
Service Strategy
The Service Strategy book offers a view of ITIL that aligns business and IT so that each brings out the best in the other. It ensures that every stage of the service lifecycle stays focused on the business case and relates to all the companion process elements that follow. Subsequent titles will link deliverables to meeting the business goals, requirements and service management principles described in this publication. Concepts and guidance in this publication include: Service Management strategy and value planning Linking business plans and directions to IT service strategy Planning and implementing service strategy
Service Design
In order to meet the current and future business requirements, Service Design provides guidance on the production and maintenance of IT policies, architectures, and documents for the design of appropriate and innovative IT services solutions and processes. Concepts and guidance in this publication include: Service design objectives and elements Selecting the service design model Cost model 25
V 7.1
Benefit/risk analysis Implementing service design Measurement and control
Service Transition
Service Transition focuses on the broader, long-term change management role and release practices, so that risks, benefits, delivery mechanism and the ease of ongoing operations of service are considered. This publication provides guidance and process activities for the transition of services into the business environment. Concepts and guidance in this publication include: Managing organizational and cultural change Knowledge management Service knowledge management system Methods, practices and tools Measurement and control Companion best practices
Service Operation
By focusing on delivery and control process activities, a highly desirable, steady state of managing services can be achieved on a day-to-day basis. To ensure it is integrated with the rest of the ITIL library, guidance is based on a selection of familiar service support and service delivery control points. Concepts and guidance in the Service Operation publication include: Application Management Change Management Operations Management Control processes and functions Scaleable practices Measurement and control
Continual Service Improvement

Alongside the delivery of consistent, repeatable process activities as part of service quality, ITIL has always emphasized the importance of continual improvements. Focusing on the process elements involved in identifying and introducing service management improvements, this publication also deals with issues surrounding service retirement. Concepts and guidance in this publication include: Business and technology drivers for improvement Justification Business, financial and organizational improvements Methods, practices and tools Companion best practices A sixth book in the core of practice is the Introduction to ITIL Service Management Practices. This covers the key concepts and articulates the business case for adopting ITIL. The new core practice guidelines offer a greater level of prescription than older versions of ITIL whilst maintaining a generic customizability. It offers more how to expertise.
26
V 7.1
The core of practice is design for longevity and continued relevance over the long-term.
27
V 7.1
ITIL SERVICE MANAGEMENT PRACTICES
28
V 7.1
Service Strategy
ITIL integrated business and IT so that each brings out the best in the other. It ensures that every element of the Service Lifecycle is focused on customer outcomes and relates to all the companion process elements that follow.
Purpose
To operate and grow successfully in the long-term, service providers must have the ability to think and act in a strategic manner. The purpose of this area is to help organizations develop such abilities. The achievement of strategic goals or objectives requires the use of strategic assets. ITIL shows how to transform service management into a strategic asset. ITIL users benefit from seeing the relationships between various services, systems, or processes they manage and the business models, strategies, or objectives they support. The guidance answers questions such as: o o o o o o o o o o o What services should we offer and to whom? How do we differentiate ourselves from competing alternatives? How do we truly create value for our customers? How do we capture value for our stakeholders? How can we make a case for strategic investments? How can financial management provide visibility and control over value-creation? How should we define service quality? How do we choose between different paths for improving service quality? How do we efficiently allocate resources across a portfolio of services? How do we resolve conflicting demands for shared resources? A multi-disciplinary approach is required to answer such questions.
Technical knowledge of IT is necessary but not sufficient. The guidance is pollinated with knowledge from the disciplines such as operations management, marketing, finance, information systems, organizational development, systems dynamics, and industrial engineering. The result is a body of knowledge robust enough to be effective across a wide range of business environments. Some organizations are putting in place the foundational elements of service management. Others are further up the adoption curve; ready to tackle challenges and opportunities with higher levels of complexity and uncertainty.
Principles
Value Creation Service assets Service Provider Types Service Structures Service Strategy Fun
Main Activities
Define the Market Develop the offerings Develop strategic assets Prepare for execution
29
Version 7.1
Service Strategy Process: Financial Management for IT Services

The landscape of IT is changing as a strategic business and delivery models evolve rapidly, product development cycles shrink, and disposable designer products become ubiquitous. These dynamics create what often appears to IT professionals as a dichotomy of priorities: increasing demands on performance and strategic business alignment, combined with greater demand for superior operational visibility and control. Much like their business counterparts, IT organizations are increasingly incorporation Financial Management in the pursuit of: Enhanced decision making Speed of change Service Portfolio Management Financial compliance and control Operational control Value capture and creation.
IT organizations are conceding they are quite similar to market facing companies. They share the need to analyze, package, market and deliver services just as any other business. They also share a common and increasing need to understand and control factors of demand and supply and to provision services as cost-effectively as possible while maximising visibility into cost-related structures. This commonality is of great value to the business as IT seeks to drive down cost while improving its service offerings. When Service Level Management agrees with the customer on Service Levels, it has to be able know how much money is involved in delivering this service. Especially when the cost for IT services is to be charged on to the customer. Financial Management for IT Services allows the IT organization to clearly articulate the costs of delivering IT Services. There are 3 fundamental components with this process. Budgets IT Accounting Charging
Note: Charging is an optional activity and is dependant on the charging policy of the organization as a whole. Financial Management provides the business and IT with the quantification, in financial terms, of the value of IT services, the value of assets underlying the provisioning of those services, and the opportunity of operational forecasting. Talking about IT in terms of services is the key of changing the perception of IT and its value to the Business. Therefore, a significant portion of Financial Management for IT Services is in integrating with the business to help identify, document and agree upon the value of the service being received, and the enablement of service Demand Management. Financial Management for IT Services needs input from all other processes regarding the costs that form part of the service delivery. It will also deliver input to the other processes, e.g. financial information for the cost-benefits analysis within Problem Management and Change Management.
30
Version 7.1
Service Strategy Practice: Demand Management

Demand Management is a critical aspect of service management. Poorly managed demand is a source of risk for service providers because of uncertainty in demand. Excess Capability generates cost without creating value that provides a basis for cost-recovery. Customers are reluctant to pay for idle capacity unless it has a value for them. Insufficient capability has an impact on the quality of services delivered and the limits the growth of the service. SLAs, forecasting, planning and tight coordination with the customer can reduce the uncertainty in demand but cannot entirely eliminate it. Activity based Demand Management and daisy-chain demand patterns to ensure that the business plans of customers are synchronized with the service management plans of the service provider.
31
Version 7.1
Service Strategy Practice: Service Portfolio Management

A service portfolio describes a providers services in terms of business value. It defines the business needs and the providers solutions to those needs. By definition, business value terms correspond to marketing terms, providing a means for comparing service competitiveness across alternative providers. If we think of SPM as a dynamic and ongoing process set, it should include the following work methods: Define: Inventory Services, ensure business cases and validate portfolio data. Analyze: Maximise portfolio value align and prioritize and balance supply and demand. Approve: Finalize proposed portfolio, authorize services and resources. Charter: Communicate decisions, allocate resources and charter services .
Often the term portfolio is marginalised to a list of services, applications, assets and projects. A portfolio is essentially a group of investments that share similar characteristics. They are grouped by size, discipline and strategic value. There are few fundamental differences between IT Portfolio Management, Project Management and SPM. All enable techniques for governance. The difference is in the implementation details.
32
Version 7.1
Service Design
Service Design provides guidance on the production and maintenance of IT policies, architectures, and documents for the design of appropriate and innovative IT infrastructure service solutions and processes.
Purpose:
The aim of this area is to give the user guidance on using recommended practices when designing IT Services and IT Service Management processes. This area follows on from the Service Strategy, which provides guidance on integration of the business needs to IT. It enables the reader to assess the requirements when designing a service and documents industry best practice for the design of IT services and processes. Although this area can be used in isolation, it is recommended that it be used in conjunction with the other ITIL core areas. Service design is important for setting the stage to effectively deliver services to the business and meet the demand for growth and change. Enhancement is typically of an order of magnitude greater in cost and resource than development so significant consideration should be given to designing for the ease and economy of support over the whole lifecycle but more importantly it is not possible to completely re-engineer a service once in production. It may be possible to get close but it will be impossible to get back to a design once something is running. Retrofitting the design is difficult and costly and never achieves what could have been achieved if designed properly in the first place.
Principles:
IT service design is a part of the overall business change process. Once accurate information has been obtained on what is required and signed off, with regards to the changed needs of the business, the plan for the delivery of a service to meet the agreed need can be developed. The role of the Service Design stage within this overall business change process can be defined as: Service Design . 'The design of appropriate and innovative IT services, including their architectures, processes, policies and documentation, to meet current and future agreed business requirements' It is important that the right interfaces and links to the design activities exist. When designing new or changed services it is vital that the entire service lifecycle and ITSM processes are involved from the outset. Often difficulties occur in operations when a newly designed service is handed over for live running at the last minute. The following are actions that need to be undertaken from the outset of a service design to ensure that the solution meets the requirements of the business: The new service solution should be added to the overall Service Portfolio from the concept phase and the Service Portfolio should be updated to reflect the current status through any incremental or iterative development. This will be beneficial from the Financial perspective but also from all other areas during design As part of the initial service/system analysis there will be a need to understand the Service Level Requirements (SLRs) for the service when it goes live
33
V 7.1
From the SLRs the Capacity Management team can model this within the current infrastructure to ascertain if this will be able to support the new service. If time allows the results from the modelling activities can be built into the Capacity Plan If new infrastructure is required for the new service or extended support Financial Management will need to be involved to set the budget An initial Business Impact Analysis and Risk Assessment should be conducted on services well before implementation as invaluable input into IT Service Continuity Strategy, Availability design and Capacity Planning The Service Desk will need to made aware of new Services well in advance of live operation to prepare and train Service Desk staff and potentially IT customer staff Service Transition can start planning the implementation and build into the forward schedule Supplier Management will need to be involved if procurement is required for the new service
Activities:
The design processes activities are: requirements collection, analysis and engineering to ensure that business requirements are clearly documented and agreed design of appropriate services, technology, measurements to meet business requirements processes, information and process
review and revision of all processes and documents involved in Service Design, including designs, plans, architectures and policies liaison with all other design and planning activities and roles e.g. solution design production and maintenance of IT policies and design documents, including designs, plans, architectures and policies revision of all design documents and planning for the deployment and implementation of IT strategies using roadmaps, programmes and project plans risk assessment and management of all design processes and deliverables ensuring alignment with all corporate and IT strategies and policies
34
Version 7.1
Service Design Process: Security Management

Information Security Management is an important activity, which aims to control the provision of information, and to prevent unauthorized use of information. For many years, Information Security Management was largely ignored. However, this is changing. Security is now considered as one of the main management challenges for the coming years. The interest in this discipline is increasing because of the growing use of the Internet and e-commerce in particular. More and more businesses are opening electronic gateways into their business. This introduces the risk of intrusion. Senior Management has to take decisions and these decisions can only be taken if a thorough risk analysis is undertaken. This analysis should provide input to Security Management to determine the security requirements. These requirements affect IT service providers and should be laid down in Service Level Agreements. Security Management aims to ensure that the security aspects of services are provided at the level agreed with the customer at all times. Security is now an essential quality aspect of management. Security Management integrates security in the IT organization from the service providers point of view. The Code of Practice for Information Security Management (BS 7799) provides guidance for the development, introduction and evaluation of security measures.
Basic concepts
Security Management comes under the umbrella of Information Security, which aims to ensure the safety of information. Safety refers to not being vulnerable to known risks, and avoiding unknown risks where possible. The tool to provide this is security. The aim is to protect the value of the information. This value depends on confidentiality, integrity and availability. Confidentiality: protecting information against unauthorized access and use. Integrity: accuracy, completeness and timeliness of the information. Availability: the information should be accessible at any agreed time.
This depends on the continuity provided by the information processing systems. Secondary aspects include privacy (confidentiality and integrity of information relating to individuals), anonymity, and verifiability (being able to verify that the information is used correctly and that the security measures are effective).
Objectives
In recent decades, almost all businesses have become more dependent on information systems. The use of computer networks has also grown, not only within businesses but also between them, and between businesses and the world outside. The increasing complexity of IT infrastructure means that businesses are now more vulnerable to technical failures, human error, intentional human acts, hackers and crackers, computer viruses, etc. This growing complexity requires a unified management approach. Security Management has important ties with other processes. Other ITIL processes, under the supervision of Security Management, carry out some security activities. 35
Version 7.1
Security Management has two objectives:

To meet the security requirements of the SLAs and other external requirements further to contracts, legislation and externally imposed policies. To provide a basic level of security, independent of external requirements Security Management is essential to maintaining the uninterrupted operation of the IT organization.
It also helps to simplify Information Security Service Level Management, as it is much more difficult to manage a large number of different SLAs than a limited number. The process input is provided by the SLAs, which specify security requirements, possibly supplemented by policy documents and other external requirements. The process also receives information about relevant security issues in other processes, such as security incidents. The output includes information about the achieved implementation of the SLAs, including exception reports and routine security planning. At present, many organizations deal with Information Security at the strategic level in information policy and information plans and at the operational level by purchasing tools and other security products. Insufficient attention is given to the active management of Information Security, the continuous analysis and translation of policies into technical options, and ensuring that the security measures continue to be effective when the requirements and environment change. The consequence of this missing link is that, at the tactical management level, significant investments are made in measures that are no longer relevant, at a time when new, more effective measures ought to be taken. Security Management aims to ensure that effective Information Security measures are taken at the strategic, tactical and operational levels.
Benefits
Information Security is not a goal in itself; it aims to serve the interests of the business or organization. Some information and information services will be more important to the organization than others. Information Security must be appropriate to the importance of the information. Striking a balance between security measures and the value of the information, and threats in the processing environment develops tailor-made security. An effective information supply, with adequate Information Security is important to an organization for two reasons: Internal reasons: an organization can only operate effectively if correct and complete information is available when required. The level of Information Security should be appropriate for this. External reasons: the processes in an organization create products and services, which are made available to the market or society, to meet defined objectives. An inadequate information supply will lead to substandard products and services, which cannot be used to meet the objectives and which will threaten the survival of the organization. Adequate Information Security is an important condition for having an adequate information supply. The external significance of Information Security is therefore determined in part by the internal significance. Security can provide significant added value to an information system. Effective security contributes to the continuity of the organization and helps to meet its objectives.
Process
Organizations and their information systems change. Checklists such as the Code of Practice for Information Security Management are static and insufficiently address rapid changes in IT. For this 36
V 7.1
reason, Security Management activities must be reviewed continuously to ensure their effectiveness. Security Management amounts to a never-ending cycle of plan, do, check, and act. The activities undertaken by Security Management, or undertaken in other processes under the control of Security Management are discussed below. The security section of the Service Level Agreement defines these requirements in terms of the security services and the level of security to be provided. The service provider communicates these agreements to his organization in the form of a Security Plan, defining the security standards or Operational Level Agreements. This plan is implemented, and the implementation is evaluated. The plan and its implementation are then updated. Service Level Management reports about these activities to the customer. Thus, the customer and the service provider together form a complete cyclical process. The customer can modify his requirements on the basis of the reports. And the service provider can adjust the plan or its implementation on the basis of these observations, or aim to change the agreements defined in the SLA.
Activities
Control - Information Security policy and organization The Control activity is the first activity of Security Management and relates to the organization and management of the process. This includes the Information Security management framework. This framework describes the sub processes: the definition of security plans, their implementation, evaluation of the implementation, and incorporation of the evaluation in the annual security plans (action plans). The reports provided to the customer, via Service Level Management, are also addressed. This activity defines the sub processes, security functions, and roles and responsibilities. It also describes the organizational structure, reporting arrangements, and line of control (who instructs who, who does what, how is the implementation reported).
Policy
Policy development and implementation, links with other policies. Objectives, general principles and significance. Description of the sub processes. Allocating functions and responsibilities for sub processes. Links with other ITIL processes and their management. General responsibility of personnel. Dealing with security incidents.
Information Security organization Management framework. Management structure (organizational structure). Allocation of responsibilities in greater detail. Setting up an Information Security Steering Committee. Information Security coordination. Agreeing tools (e.g. for risk analysis and improving awareness). Description of the IT facilities authorization process, in consultation with the customer. Specialist advice. Cooperation between organizations, internal and external communications. Independent EDP audit.
37
V 7.1
Security principles for access by third parties. Information Security in contracts with third parties.
Plan
The Planning activity includes defining the security section of the SLA in consultation with Service Level Management, and the activities in the Underpinning Contracts related to security. The objectives in the SLA, which are defined in general terms, are detailed and specified in the form of an Operational Level Agreement. An OLA can be considered as the security plan for an organizational unit of the service provider, and as a specific security plan, for example for each IT platform, application and network. The Planning activity not only receives input from the SLA but also from the service provider's policy principles (from the Control activity). Examples of these principles include: Every user should be uniquely identifiable, and A basic security level is provided to all customers, at all times. The Operational Level Agreements for Information Security (specific security plans) are drafted and implemented using the normal procedures. This means that, should activities be required in other processes, there will have to be coordination with these processes. Change Management using input provided by Security Management makes any required Changes to the IT infrastructure. The Change Manager is responsible for the Change Management process. The Planning activity is discussed with Service Level Management to define, update and comply with the security section of the SLA. The Service Level Manager is responsible for this coordination. The SLA should define the security requirements, where possible in measurable terms. The customer's security requirements and standards have to be verified, realistic and achievable. Implement The Implementation sub process aims to implement all the measures specified in the plans. The following checklist can support this activity. Classification and management of IT resources Providing input for maintaining the CIs in the CMDB Classifying IT resources in accordance with agreed guidelines
Personnel security Tasks and responsibilities in job descriptions. Screening. Confidentiality agreements for personnel. Training. Guidelines for personnel for dealing with security incidents and observed security weaknesses. Disciplinary measures. Increasing security awareness.
Managing security Implementation of responsibilities, implementation of job separation. Written operating instructions. Internal regulations. Security should cover the entire life cycle; there should be security guidelines for system development, testing, acceptance, operations, maintenance and phasing out. Separating the development and test environments from the production environment. Procedures for dealing with incidents (handled by Incident Management).
38
V 7.1
Implementation of recovery facilities. Providing input for Change Management. Implementation of virus protection measures. Implementation of management measures for computers, applications, networks and network services. Handling and security of data media.
Access control Implementation of access and access control policy. Maintenance of access privileges of users and applications to networks, network services, computers, and applications. Maintenance of network security barriers (firewalls, dial-in services, bridges and routers). Implementation of measures for the identification and authentication of computer systems, workstations and PCs on the network.
Evaluate An independent evaluation of the implementation of the planned measures is essential. This evaluation is needed to assess the performance and is also required by customers and third parties. The results of the Evaluation activity can be used to update the agreed measures in consultation with the customers, and also for their implementation. The results of the evaluation may suggest changes, in which case an RFC is defined and submitted to the Change Management process. There are three forms of evaluation: Self-assessments: primarily implemented by the line organization of the processes. Internal audits: undertaken by internal EDP auditors. External audits: undertaken by external EDP auditors.
Unlike self-assessments, the same personnel that act in the other sub processes do not undertake audits. This is to ensure that the responsibilities are separated. Evaluations are also carried out in response to security incidents. The main activities are: Verifying compliance with the security policy and implementation of security plans. Performing security audits on IT systems. Identifying and responding to inappropriate use of IT resources. Undertaking the security aspects of other EDP audits.
Maintenance Security requires maintenance, as risks change due to changes in the IT infrastructure, organization and business processes. Security maintenance includes the maintenance of the security section of the SLA and maintenance of the detailed security plans. Maintenance is carried out on the basis of the results of the Evaluation activity and an assessment of changes in the risks. These proposals can either be introduced into the Planning activity, or included in the maintenance of the SLA as a whole. In either case, the proposals can result in including activities in the annual security plan. Any changes are subject to the normal Change Management process. Reporting
39
V 7.1
Reporting is not an activity, but an output of the other sub processes. Reports are produced to provide information about the achieved security performance and to inform the customers about security issues. These reports are generally required under agreement with the customer. Reporting is important, both to the customer and to the service provider. Customers must be informed correctly about the efficiency of the efforts (e.g. with respect to implementing security measures), and the actual security measures. The customer is also informed about any security incidents. A list with some suggestions for reporting options is included below. Examples of scheduled reports and reportable events: The Planning activity Reports about the extent of compliance with the SLA and agreed Key Performance Indicators for security. Reports about Underpinning Contracts and any problems associated with them. Reports about Operational Level Agreements (internal security plans) and the provider's own security principles (e.g. in the baseline). Reports about annual security plans and action plans.
The Implementation activity Status reports about the implementation of Information Security. This includes progress reports about the implementation of the annual security plan, possibly a list of measures which have been implemented or are yet to be implemented, training, outcome of additional risk analyzes, etc. A list of security incidents and responses to these incidents, optionally a comparison with the previous reporting period. Identification of incident trends. Status of the awareness program.
The Evaluation activity Reports about the sub process as such. Results of audits, reviews, and internal assessments. Warnings, identification of new threats.
Specific reports To report on security incidents defined in the SLA, the service provider must have a direct channel of communication to a customer representative (possibly the Corporate Information Security Officer) through the Service Level Manager, Incident Manager or Security Manager. A procedure should also be defined for communication in special circumstances. Apart from the exception in the event of special circumstances, reports are communicated through Service Level Management.
40
Version 7.1
Relationships with other processes

Security Management has links with the other ITIL processes. This is because the other processes undertake security-related activities. These activities are carried out in the normal way, under the responsibility of the relevant process and process manager. However, Security Management gives instructions about the structure of the security-related activities to the other processes. Normally, these agreements are defined after consultation between the Security Manager and the other process managers.
Configuration Management
In the context of Information Security, Configuration Management is primarily relevant because it can classify Configuration Items. This classification links the CI with specified security measures or procedures. The classification of a CI indicates its required confidentiality, integrity and availability. This classification is based on the security requirements of the SLA. The customer of the IT organization determines the classification, as only the customer can decide how important the information or information systems are to the business processes. The customer bases the classification on an analysis of the extent to which the business processes depend on the information systems and the information. The IT organization then associates the classification with the relevant CIs. The IT organization must also implement this set of security measures for each classification level. These sets of measures can be described in procedures. Example: Procedure for handling storage media with personal data. The SLA can define the sets of security measures for each classification level. The classification system should always be tailored to the customer's organization. However, to simplify management it is advisable to aim for one unified classification system, even when the IT organization has more than one customer. In summary, classification is a key issue. The CMDB should indicate the classification of each CI. This classification links the CI with the relevant set of security measures or procedure.
Incident Management
Incident Management is an important process for reporting security incidents. Depending on the nature of the incident, security incidents may be covered by a different procedure than other Incidents. It is therefore essential that Incident Management recognise security incidents as such. Any Incident, which may interfere with achieving the SLA security requirements, is classified as a security incident. It is useful to include a description in the SLA of the type of Incidents to be considered as security incidents. An Incident that interferes with achieving the basic internal security level (baseline) is also always classified as a security incident. Incidents reports are generated not only by users, but also by the management process, possibly on the basis of alarms or audit data from the systems. It is clearly essential that Incident Management recognise all security incidents. This is to ensure that the appropriate procedures are initiated for dealing with security incidents. It is advisable to include the procedures for different types of security incidents in the SLA plans and to practice the procedure. It is also advisable to agree a procedure for communicating about security incidents. It is not unusual for panic to be created by rumours blown out of proportion. Similarly, it is not unusual for damage to result from a failure to communicate in time about security incidents. It is advisable to route all external communications related to security incidents through the Security Manager.
41
V 7.1
Problem Management
Problem Management is responsible for identifying and solving structural security failings. A Problem may also introduce a security risk. In that case, Problem Management must involve Security Management in resolving the Problem. Finally, the solution or workaround for a Problem or Known Error must always be checked to ensure that it does not introduce new security problems. This verification should be based on compliance with the SLA and internal security requirements.
Change Management
Change Management activities are often closely associated with security because Change Management and Security Management are interdependent. If an acceptable security level has been achieved and is managed by the Change Management process, then it can be ensured that this level of security will also be provided after Changes. There are a number of standard operations to ensure that this security level is maintained. Each RFCs is associated with a number of parameters, which govern the acceptance procedure. The urgency and impact parameters can be supplemented by a security parameter. If RFCs can have a significant impact on Information Security then more extensive acceptance tests and procedures will be required. The RFCs should also include a proposal for dealing with security issues. Again, this should be based on the SLA requirements and the basic level of internal security required by the IT organization. Thus, the proposal will include a set of security measures, based on the Code of Practice. Preferably, the Security Manager (and possibly also the customers Security Officer) should be a member of the Change Advisory Board (CAB). Nevertheless, the Security Manager need not be consulted for all Changes. Security should normally be integrated with routine operations. The Change Manager should be able to decide if they or the CAB need input from the Security Manager. Similarly, the Security Manager need not necessarily be involved in the selection of measures for the CIs covered by the RFCs. This is because the framework for the relevant measures should already exist. Any questions should only relate to the way in which the measures are implemented. Any security measures associated with a Change should be implemented at the same time as the Change itself, and be included in the tests. Security tests differ from normal functional tests. Normal tests aim to investigate if defined functions are available. Security tests not only address the availability of security functions, but also the absence of other, undesirable functions as these could reduce the security of the system. In terms of security, Change Management is one of the most important processes. This is because Change Management introduces new security measures in the IT infrastructure, together with Changes to the IT infrastructure.
Release Management
All new versions of software, hardware, data communications equipment, etc. should be controlled and rolled out by Release Management. This process will ensure that: The The The The The The The correct hardware and software are used. hardware and software are tested before use. introduction is correctly authorized using a Change. software is legal. software is free from viruses and that viruses are not introduced during its distribution. version numbers are known, and recorded in the CMDB by Configuration Management. rollout is managed effectively. 42
V 7.1
This process also uses a regular acceptance procedure, which should include Information Security aspects. It is particularly important to consider security aspects during testing and acceptance. This means that the security requirements and measures defined in the SLA should be complied with at all times.
Service Level Management

Service Level Management ensures that agreements about the services to be provided to customers are defined and achieved. The Service Level Agreements should also address security measures. The objective is to optimise the level of service provided. Service Level Management includes a number of related security activities, in which Security Management plays an important role: 1. Identification of the security needs of the customer. Naturally, determining the security needs is the responsibility of the customer as these needs are based on their business interests. 2. Verifying the feasibility of the customer's security requirements. 3. Proposing, discussing and defining the security level of the IT services in the SLA. 4. Identifying, developing and defining the internal security requirements for IT services (Operational Level Agreements). 5. Monitoring the security standards (OLAs). 6. Reporting on the IT services provided. Security Management provides input and support to Service Level Management for activities 1 - 3. Security Management carries out activities 4 and 5. Security Management and other processes provide input for activity 6. The Service Level Manager and the Security Manager decide in consultation that actually undertakes the activities. When defining an SLA it is normally assumed that there is a general basic level of security (baseline). Additional security requirements of the customer should be clearly defined in the SLA.
Availability Management
Availability Management addresses the technical availability of IT components in relation to the availability of the service. The quality of availability is assured by continuity, maintainability and resilience. Availability Management is the most important process related to availability. As many security measures benefit both availability and the security aspects confidentiality and integrity, effective coordination of the measures between Availability Management, IT Service Continuity Management, and Security Management is essential.
Capacity Management
Capacity Management is responsible for the best possible use of IT resources, as agreed with the customer. The performance requirements are based on the qualitative and quantitative standards defined by Service Level Management. Almost all Capacity Management activities affect availability and therefore also Security Management.
IT Service Continuity Management

IT Service Continuity Management ensures that the impact of any contingencies is limited to the level agreed with the customer. Contingencies need not necessarily turn into disasters. The major activities are defining, maintaining, implementing, and testing the contingency plan, and taking preventive action. Because of the security aspects, there are ties with Security Management. On the other hand, failure to fulfil the basic security requirements may be considered itself as a contingency.
43
V 7.1
Security section of the Service Level Agreement

The Service Level Agreement (SLA) defines the agreements with the customer. The Service Level Management process is responsible for the SLA. The SLA is the most important driver for all ITIL processes. The IT organization indicates to what extent the requirements of the SLA are achieved, including security requirements. The security elements addressed in the SLA should correspond to the security needs of the customer. The customer should identify the significance of all business processes. These business processes depend on IT services, and therefore on the IT organization. The customer determines the security requirements on the basis of a risk analysis. The security elements are discussed between the representative of the customer and the representative of the service provider. The service provider compares the customer's Service Level Requirements with their own Service Catalogue, which describes their standard security measures (the Security Baseline). The customer may have additional requirements. The customer and provider compare the Service Level Requirements and the Service Catalogue. The security section of the SLA can address issues such as the general Information Security policy, a list of authorized personnel, asset protection procedures, restrictions on copying data, etc.
The Security section of the Operational Level Agreement

The Operational Level Agreement is another important document. It describes the services provided by the service provider. The provider must associate these agreements with responsibilities within the organization. The Service Catalogue gives a general description of the services. The Operational Level Agreement translates these and general descriptions into all services and their components, and the way in which the agreements about the service levels are assured within the organization. Example: the Service Catalogue refers to managing authorisations per user and per individual. The Operational Level Agreements details this for all relevant services provided by the IT organization. In this way, the implementation of the measure is defined for the departments providing UNIX, VMS, NT, Oracle services, etc. Where possible, the customer's Service Level Requirements are interpreted in terms of the provider's Service Catalogue, and additional agreements are concluded where necessary. Such additional measurements exceed the standard security level. When drafting the SLA, measurable Key Performance Indicators (KPI) and criteria must also be agreed for Security Management. KPIs are measurable parameters (metrics), and performance criteria are set at achievable levels. In some cases it will be difficult to agree on measurable security parameters. This is easier for availability, which can generally be expressed numerically. However, this is much more difficult for integrity and confidentiality. For this reason, the security section of the SLA normally describes the required measures in abstract terms. The Code of Practice for Information Security Management is used as a basic set of security measures. The SLA also describes how performance is measured. The IT organization (service provider) must regularly provide reports to the user organization (customer).
Process control
Critical success factors and performance indicators The critical success factors are: Full management commitment and involvement. User involvement when developing the process. Clear and separated responsibilities.
The Security Management performance indicators correspond with the Service Level Management performance indicators, in so far as these relate to security issues covered by the SLA. Functions and roles
44
V 7.1
In small IT organizations, one person may manage several processes. While in large organizations, several persons will be working on one process, such as Security Management. In this case there is normally one person appointed as Security Manager. The Security Manager is responsible for the effective operation of the Security Management process. Their counterpart in the customer's organization is the Information Security Officer, or Corporate Information Security Officer. Points of Attention and costs As with any process there are areas that could undermine the successful implementation. The following section details some of the areas that must be covered to make the process implementation worthwhile. The final section looks briefly at some of the cost areas when it comes to the introduction of Security Management. Points of attention The following issues are essential to the successful implementation of Security Management: Commitment: security measures are rarely accepted immediately, resistance is more common than acceptance. Users resent losing certain privileges due to security measures, even if these facilities are not essential to their work. This is because the privileges give them a certain status. A special effort will therefore have to be made to motivate users, and to ensure that management complies with the security measures. In the field of Security Management in particular, management must set an example (walk the talk and lead by example). If there are no security incidents, then management may be tempted to reduce the Security Management budget. Attitude: information systems are not insecure due to technical weaknesses, but due to the failure to use the technology. This is generally related to attitude and human behaviour. This means that security procedures must be integrated with routine operations. Awareness: awareness, or rather communication, is a key concept. There sometimes appears to be a conflict of interest between communication and security communication paves the road, while security creates obstacles. This means that implementing security measures requires the use of all communication methods to ensure that users adopt the required behaviour. Verification: it should be possible to check and verify security. This concerns both the measures introduced, and the reasons for taking these measures. It should be possible to verify that the correct decisions have been taken in certain circumstances. For example, it should also be possible to verify the authority of the decision-makers. Change Management: frequently the verification of continued compliance with the basic level of security wanes over time when assessing Changes. Ambition: when an organization wants to do everything at once, mistakes are often made. When introducing Security Management, the implementation of technical measures is much less important than organizational measures. Changing an organization requires a gradual approach and will take a long time. Lack of detection systems: new systems, such as the Internet, were not designed for security and intruder detection. This is because developing a secure system takes more time than developing a non-secure system, and conflicts with the business requirements of low development costs and short time-to-market.
Costs
Securing the IT infrastructure demands personnel, and therefore money, to take, maintain and verify measures. However, failing to secure the IT infrastructure also costs money (cost of lost production; cost of replacement; damage to data, software, or hardware; loss of reputation; fines
45
V 7.1
or compensation relating to failure to fulfil contractual obligations). As always, a balance will have to be struck.
46
Version 7.1
Service Design Process: Service Catalogue Management

The purpose of SCM is to provide a single course of consistent information on all the agreed services and ensure that it is widely available to those that are approved to access it.
Goal
To ensure that a Service Catalogue is produced, maintained and contains accurate information on all operational services and those being prepared to run operationally.
Objective
Manage the information contained within the Service Catalogue and to ensure that it is accurate and reflects the current details, status, interfaces and dependencies of all services that are being run or being prepared to run in the live environment.
Scope
Provide and maintain accurate information on all services that are being transitioned or have been transitioned to the live environment. Activities Definition of the service Production and maintenance of an accurate Service Catalogue Interfaces, dependencies and consistency between the Service Catalogue and Service Portfolio. Interfaces and dependencies between all services and supporting services within the Service Catalogue. Interfaces and dependencies between all services and supporting components and Configuration Items (CIs) within the Service Catalogue.
The Service Catalogue provides a central source of information on the IT services delivered by the service provider. This ensures that all areas of the business can view an accurate, consistent picture of the IT services in use, how they are intended to be used, the business processes they enable, and the levels and quality of the service the customer can expect for each service.
47
Version 7.1
Service Design Process: Supplier Management

The Supplier Management process ensures that suppliers and the services they provide are managed to support IT service targets and business expectations. The aim of this process is to raise awareness of the business context or working with partners and suppliers, and how this can work best be directed towards realising business benefit for the organization. It is essential that Supplier Management is involved in all of the stages throughout the lifecycle, from strategy to design, through transition and operations to improvement. The complex business demands require the complete breadth of skills and capability to support service provision of a comprehensive set of IT services to the business. Therefore, the use of value networks and the suppliers and the services they provide are an integral part of any end to end solution. Suppliers and the management of suppliers and partners are essential to the provision of quality IT services.
Goal
Obtain value for money from suppliers and to ensure that suppliers perform to the targets contained within their contracts and agreements while conforming to all of the terms and conditions.
Objective
Obtain value for money from supplier contracts Ensure that underpinning contracts and agreements with suppliers are aligned to business needs and support and align with agreed targets in SLAs and SLRs, in conjunction with SLM. Manage relationships with suppliers Manage supplier performance Negotiate and agree contracts with suppliers and manage them through their lifecycle Maintain a supplier policy and a supporting Supplier and Contract Database (SCD).
Scope
Management of all suppliers and contracts needed to support the provision of IT services to the business. The SM process should include: Implementation and enforcement of the supplier policy Maintenance of Supplier and Contract Database Supplier and contract categorization and risk assessment 48
V 7.1
Supplier and contract evaluation and selection The development, negotiation and agreements of contracts Contract review, renewal and termination The management of suppliers and supplier performance The agreement and implementation of service and supplier improvement plans The maintenance of standard contracts, terms and conditions Management of contractual dispute resolution Management of sub contracted suppliers.
49
Version 7.1
Service Design Process: Availability Management

Goals
Contrary to popular belief, Availability Management deals with ensuring that the services are available according to agreed levels. It does not set out to guarantee the maximum level of availability, nor is it about reporting on server availability as a stand-alone issue.
Objective
To produce and maintain an appropriate and up to date Availability Plan, which reflects the current and future needs of the business To provide advice and guidance to all other areas of the business and IT on all availability related issues To ensure that service availability achievements meet are exceed all of their agreed targets, by managing services and resources related availability performance To assist with the diagnosis and resolution of availability related incidents and problems To assess the impact of all the changes on the Availability Plan, and the performance of capacity of all services and resources. To ensure that proactive measures to improve the availability of services are implemented wherever it is cost justifiable to do so.
Scope
The scope of Availability Management covers the design, implementation, measurement and improvement of IT service and component availability. Availability Management needs to understand the service and component availability requirements from the business perspective in terms of: The current business processes, their operation and requirements The future business plans and requirements The service targets and the current IT service operation and delivery The IT infrastructure, data, applications and environment and their performance The business impacts and prioritise in relation to the services and their usage
This process ultimately links all IT components together and manages the links and weaknesses between the IT components to ensure the availability of the service delivery to the customer. Availability works closely together with Capacity Management. This is a logical connection as you cant ensure the availability of the service when the capacity is insufficient. There is also a close 50
V 7.1
link to Problem Management as the availability expert is often technically skilled and able to analyze root cause analysis.
51
Version 7.1
Service Design Process: Capacity Management

Capacity Management is a process that extends across the Service Lifecycle. The essence of Capacity Management is to ensure that the right amount of capacity is at the right location, for the right customer, at the right time and at the right price. Capacity Management aims to optimise the amount of capacity needed to deliver a consistent level of service to the customer. Balancing or spreading workload is a key method to avoid wasting money on excess capacity that is unnecessary. A key success factor in managing capacity is ensuring it is considered in the design stage. CM is initially supported by Service Strategy, where decisions and analysis of business requirements, customer outcomes influences the development of patterns of business activity, levels of service and service packages are identified. This provides the predictive and ongoing capacity indicators needed to align capacity to demand.
Goal
To ensure cost justifiable IT capacity in all areas of I, always exists and is matched to the current and future needs of the business, in a timely manner.
Objective
To produce and maintain an appropriate and up to date Capacity Plan, which reflects current and future needs of the business To provide advice and guidance to all other areas of the business and IT on all capacity and performance related issue To ensure that service performance achievements meet or exceed all of their agreed performance targets, by managing the performance and capacity of both service and resources To assist with the diagnosis and resolution of performance and capacity related incidents and problems To assess the impact of all changes on the Capacity Plan and the performance and capacity of all service and resources To ensure that proactive measures to improve the performance of services are implemented wherever it is cost justifiable to do so.
Scope
The Capacity Management process should be the focal point for all IT performance and Capacity issue. Technology management functions, such as Network Support, Server Support and Operations Management may carry out the bulk of the day-to-day operational duties but will provide performance information to the Capacity Management process. The process should encompass all areas of technology, both hardware and software, for all IT technology components and environments. Capacity Management has a very close relationship to Availability Management, Configuration Management and Service Level Management. 52
V 7.1
ANECDOTE Why Bother?

With cheap hardware prices, capacity planning may be seen to have lost its importance. You can always upgrade later! The fact that hardware systems can be upgraded easily has, in recent times, diverted attention away from this key process area. There are two main concerns that make capacity planning critical. The first is the rate of technical change in the distributing computing sector. We now measure progress in "Internet years" -- equivalent to a fraction of a typical calendar year. The second is that todays systems are primarily being developed within complex multi-tier architectures. This rapid change, coupled with the increase in complexity of 3-tier architecture, is causing system designers to pay closer attention to capacity. Five years ago, a designer could roll out a new system with a rough estimate of capacity and performance. The system could then be tuned or more capacity added before all of the users had been converted to the new system. The process was reasonable because the systems were typically not mission-critical. Today, theres no time for this approach. Once systems are in place they become an integral part of the overall operation. Upgrade downtime is increasingly expensive in both time and resources. In addition, the added complexity of the environment typically requires more care, due to the interdependency between various application components. Capacity planning is driven purely by financial considerations. Proper capacity planning can significantly reduce the overall cost of ownership of a system. Although formal capacity planning takes time, internal and external staff resources, software and hardware tools, the potential losses incurred without capacity planning are staggering. That is why we should bother!!
53
V 7.1
Service Design Process: IT Service Continuity Management

IT Service Continuity Management (ITSCM) prepares us for the worst case scenario. ITSCM investigates, develops and implements recovery options when an interruption to service reaches a pre-defined point. The ultimate choice of which option to choose, is made by the customer as part of the SLA agreements. Price generally has a factor in selecting an appropriate recovery option. In the current global situation, a structured approach to IT Service Continuity Management has become more and more important. Business processes rely more and more on IT Services and IT components are more under attack. Defining the pre-conditions that constitute a disaster is part of the ITSCM process. Such definitions form an integral part of any Service Level Agreement relating to the provision of services.
Goal
To support the overall business Continuity Management (BCM) processes by ensuring that the required IT technical and service facilities (including computer systems, networks, applications, date repositories, telecommunications, environment, technical support and Service Desk) can be resumed within required, and agreed, business timescales.
Objective
To maintain a set of IT Service Continuity Plans and IT recovery plans that support the overall Business Continuity Plans (BCP) of the organization To complete regular Business Impact Analysis (BIA) exercises to ensure that all continuity plans are maintained in line with changing business impacts and requirements. To conduct regular risk assessment and management exercises in conjunction particularly with the business and the AM and Security Management processes, that manages IT service within an agreed level of business risk. To provide advice and guidance to all other areas of the business and IT on all continuity and recovery related issue. To ensure that appropriate continuity and recovery mechanisms are put in place to meet or exceed the agreed business continuity plans To assess the impact of all changes on the IT Service Continuity Plans and IT recovery plans To ensure that proactive measures to improve the availability of services are implemented wherever it is cost justifiable to do so To negotiate and agree the necessary contracts with suppliers for the provision of the necessary recovery capability to support all continuity plans in conjunction with the Supplier Management process.
54
V 7.1
Scope
ITSCM focuses on those events which the business considers significant enough to be considered a disaster. Less significant events will be dealt with as part of the Incident Management process. What constitutes a disaster will vary from organization to organization. The impact of loss of a business process, such as financial loss, damage to reputation or regulatory breach, is measured through the BIA exercise, which determines the minimum critical requirements. BIA to quantify the impact loss of IT service would have on the business Risk Analysis (RA) the risk identification and risk assessment to identify potential threats to continuity and the likelihood of the threats becoming reality. This also includes taking measures to manage the identified threats where this can be cost justified Production of an overall ITSCM strategy that must be integrated in to the BCM strategy. Productions of the ITSCM plans which again must be integrated with the overall BCM plans. Testing of the plans The on-going operation and maintenance of the plans.
55
V 7.1
Service Transition
Service Transition provides guidance and process activities for the transition of services in the operational business environment. It covers the broader, long-term change management role, release and deployment practices, so that risks, benefits, delivery mechanisms and the support of ongoing operational services are considered.
Purpose:
The goal of this area is to assist organizations seeking to plan and manage service changes and deploy service releases into the production environment successfully.
Principles:
Defining a service Define and implement a formal policy for service transition Implement all changes to services through service transition Adopt a common framework and standards Maximize re-use of established processes and systems Align service transition plans with the business needs Establish and maintain relationships with stakeholders Establish effective controls and disciplines Provide systems for knowledge transfer and decision support Plan release and deployment packages Anticipate and manage course corrections Proactively manage resources across service transitions Ensure early involvement in the service life cycle Assure the quality of the new or changed service Proactively improve quality during service transition
Main Activities:
Transition planning and support Change Management Service Asset and Configuration Management Release and Deployment Management Service Validation and testing Evaluation Knowledge Management
56
Version 7.1
Service Transition Process: Transition Planning and Support

Effective transition planning and support can significantly improve a service providers ability to handle high volumes of change and release across its customer base. An integrated approach to planning improves the alignment of the service transition plans with the customer, supplier and business change project plans.
Goal
The goal of transition and support is to: Plan and co-ordinate the resources to ensure that the requirements of service strategy encoded in service design and effectively realizes in service operations To identify, manage and control the risks of failure and disruption across transition activities.
Objective
Plan and co-ordinate the resources to successfully establish a new or changed service into production with the predicted cost, quality and time estimates Ensure that all parties adopt the common framework of standard re-useable processes and supporting systems in order to improve the effectiveness and efficiency of the integrated planning and co-ordination activities Provide clear and comprehensive plans that enable the customer and business change projects to align their activities with the service transition plans. Plan appropriate capacity and resources to package, build, release, test, deploy and establish the new changed service into production. Provides support for the service transition teams and people Plan the changes required in a manner that ensures the integrity of all identified customer assets, service assets and configurations can be maintained as they evolve through service transition Ensure that service transition issues, risks and deviations are reported to the appropriate stakeholders and decision makers. Co-ordinate activities across projects, suppliers and service teams when required.
57
V 7.1
Scope
Incorporating design and operation requirements into transition plans Managing and operating transition planning and support activities Maintaining and integrating service transition plans across the customer, service and contract portfolios Management of service transition progress, changes, issues, risks and deviations Quality review of all service transition, release and deployment plans Managing and operating the transition processes, supporting systems and tools Communications with customers, users and stakeholders Monitoring and improvement of service transition performance.
58
Version 7.1
Service Transition Process: Service Validation & Testing

The underlying concept to which service testing and validation contributes is quality assurance establishing that the service design and release will deliver a new or changed service or service offering that is fit-for-the-purpose and fit-for-use. Testing is a vital area within service management and has often been the unseen underlying cause of what was taken to be inefficient service management process. If service are not tested sufficiently then their introduction into the operational environment will bring a rise in: Incidents, since failures in service elements and mismatches between what was wanted and what was delivered impact upon business support Service desk calls for clarification, since services that are not functioning as intended are inherently less intuitive causing a higher support requirement Problems and errors that are harder to diagnose in the live environment. Costs, since errors are more expensive to fix in production than if found in testing. Services that are not used effectively by the users to deliver the desired value
Goal
The goal of this service is to assure that a service will provide value to customer s and their business
Objective
Provide confidence that a release will create a new or changed service or service offerings that deliver the expected outcomes and value for the customers within the projected costs, capacity and constraints. Validate that a service is Fit for Purpose - it will deliver the required performance with desired constraints removed Assure a service is; Fit for Use it meets certain specifications under the specific terms and conditions of use. To confirm that the customer and stakeholder requirements for the new or changed service are correctly defined and remedy any errors or variances early in the service lifecycle as this is considerably cheaper than fixing errors in production. To plan and implement a structured validation and test process that provides objective evidence that the new or changed service will support the customers business and stakeholders requirements, including the agreed service levels. To quality assure a release, its constituent service components, the resultant service and service capability delivered by a release. To identify, assess and address issues, errors and risks throughout the service transition. 59
V 7.1
Scope
The service provider takes responsibility for delivering, operating and/or maintaining customer or service assets as specified levels of warranty, under a service agreement. Service validation and testing can be applied throughout the service life cycle to quality assure any aspect of a service and the service providers capability, resources and capacity to deliver a service and/or service release successfully. In order to validate and test an end to end service the interfaces to suppliers, customers and partners are important. A Service Provider Interface definitions define the boundaries of the service to be tested e.g. process interfaces, organizational interfaces.
Testing is equally applicable to in-house or developed services, hardware, software or knowledge based services. It includes the testing of new or changed services or service components and examines the behaviour of these in the target business unit, service unit, deployment group or environment
Testing directly supports the Release and Deployment process by ensuring that appropriate levels of testing are performed during the release, build and deployment activities. It evaluates the detailed Service Models to ensure that they are fit for purpose and fit for use before being authorized to enter Service Operations, through the Service Catalogue. The output from testing is used by the Evaluation process to provide the information on whether the service is independently judged to be delivering the service performance with an acceptable risk profile.
60
Version 7.1
Service Transition Process: Evaluation

Evaluation is a generic process that considers whether the performance of something is acceptable, value for money etc and whether the performance of something is acceptable, value for money etc and whether it will be proceeded with, accepted into use, paid for etc.
Goal & Objective

Evaluation provides a standardized means of determining the performance of a Service Change in the context of existing and proposed services. The actual performance of a change is assessed against its predicted performance and any deviations between the two are understood and managed.
Scope
Specifically in this section we consider the evaluation of new or changed service into operations. The importance of evaluating the actual performance of any service change against its anticipated performance is an important source of information to service providers to help ensure that expectations set are realistic and that if there are any reasons that production performance does not meet what was expected.
61
Version 7.1
Service Transition Process: Service Knowledge Management

The ability to deliver a quality service or process rests to a significant extent upon the ability of those involved to respond to circumstances and that in turn rests heavily upon their understanding of the situation, the options and the consequences and benefits, i.e. their knowledge of the situation they are, or may, find themselves in. That knowledge within the service transition domain might include: Identity of stakeholders Acceptable risk levels and performance expectation Available resource and timescales.
The quality and relevance of the knowledge rests in turn upon the accessibility, quality and continued relevance of the underpinning date and information available to service staff.
Goal
Enable organizations to improve the quality of management decision making by ensuring that reliable and secure information and date is available throughout the Service Life Cycle.
Objective
Enable the service provider to be more efficient and improve quality of service, increase satisfaction and reduce the cost of service. Ensure staff have clear and common understanding of the value that their services provide to customers and the ways in which benefits are realized from the utilization of those services. Ensuring that, at a given time and location, service provider staff have adequate information of Who is currently utilizing their services? The current states of consumption Service delivery constraints Difficulties faced by the customer in fully realizing the benefits expected from the service.
The purpose of Knowledge Management is to ensure that the right information is delivered to the appropriate place or person at the right time to enable informed decision.
Scope
Knowledge Management is a whole life cycle wide process in that it is relevant to all life cycle sectors and hence is referenced throughout ITIL from the perspective of each book. 62
V 7.1
63
Version 7.1
Service Transition Process: Change Management

A robust Change Management process ensures that the Change Manager is in full control of the changes to the IT infrastructure. Change Management is NOT about performing changes risk free. It is about performing changes with a minimal risk OR consciously taken risk. It is therefore important to involve the clients or client representatives in the change management process. All projects start through Change Management as all projects wish to change something to the IT Infrastructure: they either modify the current infrastructure or add/remove a component. Change Management is more than just Change Control. The Change Management process starts with the Request For Change (RFC) being raised and keeps control from the assessment and acceptance of the RFC through to the Post Implementation Review (PIR).
Goals
Respond to the customers changing business and business requirements whilst maximising value and reducing incidents, disruption and re-work Respond to the business and IT requests for change that will align the services with the business needs.
Objective
Ensure that changes are recorded and then evaluated, authorized, prioritized, planned and tested, implemented, documented and reviewed in a controlled manner. Standardised methods and procedures are used for efficient and prompt handling of all Changes All changes to service assets and configuration items are recorded in the CMDB. Overall business risk is optimised.
Scope
The scope of Change Management covers changes to baseline service assets and configuration items across the whole Service Life Cycle. Each organization should define the changes that lie outside the scope of their service change process. These may include: Changes with significantly wider impacts than service changes e.g. departmental organization, policies, business operations these changes would produce RFCs to generate consequential service changes. Changes at an operational level such as repair to printers or other routine service components.
64
V 7.1
All other processes issue RFCs to Change Management for necessary upgrades to improve their effectiveness and efficiency. Change Management needs information from all other processes in order to perform the risk assessment regarding requested changes.
ANECDOTE Software Changes

"I updated that document yesterday, but it's not appearing on the Intranet. What happened?" "The new version's wrong! Did we back up the old one?" "Chris and I were editing the same file at the same time, but I finished first. His changes overwrote mine! "Who made that change?" "Only the Webmaster is allowed to change any files, so your changes might be implemented by Christmas." If you hear statements like these on a regular basis, you may be suffering from change out of control. Changes in files are necessary and beneficial, but they also have to be controlled. People in a development environment know all about this problem, and have devised a sound way of managing the volume of changes to software files. The discipline of managing, controlling, and automating changes in your files is called software change management.
How can we fix it? Begin with a sound policy when applying a change management system
to Web development. Policy is the rationale behind tools and procedures, and without a sound one, the tools won't be nearly as helpful as they could be.
Special Tip: When drawing up a policy, consider both the organizational structure and the
logical structure of the Web site or sites.
65
Version 7.1
Service Transition Process: Release & Deployment Management

As soon as Change Management has approved a change, where appropriate, it hands it over to Release management to release the change into the appropriate environment. Release Management performs version control and controls the movement of software, hardware and other infrastructure components from the development environment to the test environment and into production. Release management also manages the Definitive Software Library (DSL), in which it stores all master copies of the software Configuration Items (CIs). The Definitive Hardware Store (DHS) is a physical storage area with the authorized spare parts and other components of the non-software CIs. The Definitive Media Library (DML) secure library in which authorized versions of all media CIs are stored and protected. All master copies of versions that have passed QA checks. All products that go into the DSL of DHS need to be checked for damage and viruses before they are stored. The management of impending release notifications is an important part of this process (especially with regard to advance warnings to the Service Desk).
Goal
The goal of Release and Deployment management is to deploy Releases into production and enable effective use of the service in order to deliver value to the customer.
Objective
There are clear and comprehensive release and deployment plans that enable the customer and business to change projects to align their activities with these plans A release package can be built, installed, tested and deployed efficiently to a deployment group or target environment successfully to on schedule A new changed service and its enabling systems, technology and organization are capable of delivering the agreed service requirements i.e. utilities, warranties and service levels Ensure there is enough knowledge transfer to enable customers and users to optimise their use of service to support their business activities Ensure that skills and knowledge are transferred to operations and support staff so they can effectively and efficiently deliver, support and maintain the service according to required warranties and service levels There is minimal unprecedented impact on the production services, operations and support organization Customers, users and service management staff are satisfied with the service transition practices and outputs e.g. user documentation and training
66
V 7.1
Scope
The scope of Release and Deployment Management includes the processes, systems and functions to package, build, test and deploy a release in to production and establish the service specified in the service design package.
ANECDOTE Capability Maturity Model

ITIL and CMMI are distinctly different but not mutually exclusive maturity models. The main difference between the two is that CMMI focuses on software process maturity continuous improvement whereas ITIL helps us understand and develop all of the areas within our infrastructure. ITIL and CMMI similarities The initial Capability Maturity Model (CMM v1.0) was developed by the Software Engineering Institute and specifically addressed software process maturity. It was first released in 1990, and after its successful adoption and usage in many areas, other CMMs were developed for other disciplines. ITIL and CMMI which one should I choose? The answer to that question is that there is no single reason why you cannot have both. You see, ITIL is not prescriptive and the process maturity framework that ITIL conforms to is very similar to CMMIs model. ITIL and CMMI both, as a structured approach. If CMMI is a structured approach for software development then, the ITIL Release Management process dovetails into it perfectly. Release Management focuses on the release of software into the live environment.
67
Version 7.1
Service Transition Process: Asset & Configuration Management

There is no easy way to manage your IT service Delivery in a consistent manner, when you dont know all the resources that you have at your disposal. Lots of IT organizations dont know what they own, or what they use to deliver the IT services to their customers. Configuration Management is the process that keeps a track of all the Configuration Items you need in order to deliver the IT Services. Information about Configuration Items (CIs) is held in a Configuration Management Data Base (CMDB). CIs include and are not limited to- Hardware items, software items, SLAs, Disaster Recovery Plans, policy statements, etc. Assets can be resources and capabilities used by the organization to create value in the forms of goods and services. Crucially a CMDB also defines relationships between CIs. That is, whether a CI is part of, is connected to, belongs to, joins with, etc. another CI. Configuration Management makes sure that the information about the CIs, stored in the CMDB, is accurate and up to date. All other processes rely heavily on this process.
Goal
Provide a logical model of the IT infrastructure correlating IT services and different IT components (physical, logical etc) needed to deliver these services.
Objective
To define and control the components of services and infrastructure and maintain accurate configuration records. This enables an organization to comply with corporate governance requirements, control its asset base, optimize its costs, manage change and release effectively, and resolve incidents and problems faster.
Scope
Asset Management covers service assets across the whole Service Life Cycle. It provides complete inventory of assets and who is responsible for their control. It includes: Full Life Cycle management of IT and service assets, from point or acquisition or acquisition through disposal. Maintenance of the asset inventory
68
Version 7.1
ANECDOTE . Configuration Management

Configuration Management What exactly is it? The best way to describe it is that it is like Asset Management but also unlike it because it is far more than Asset Management. Configuration Management focuses on the relationships between items, to help us understand our infrastructure far more than we do now! Configuration Management - definition The process of identifying and defining Configuration Items in a system, recording and reporting the status of Configuration Items and Requests for Change, and verifying the completeness and correctness of Configuration Items. Configuration Management - benefits Configuration Management contributes to the economic and effective delivery of IT services in an organization by: Providing accurate information on CIs and their documentation. Controlling valuable CIs. Facilitating adherence to legal obligations. Helping with financial and expenditure planning. Making software Changes visible. Contributing to contingency planning. Supporting and improving Release Management. Improving security by controlling the versions of CIs in use. Enabling the organization to reduce the use of unauthorized software. Providing Problem Management with data on trends .
69
Version 7.1
Service Operation
Service Operation introduces, explains and details delivery and control activities to achieve operational excellence on a day-to-day basis.
Purpose:
The purpose of Service Operation is to coordinate and carry out the activities and processes required to deliver and manage services at agreed levels to business users and customers. Service Operation is also responsible for the ongoing management of the technology that is used to deliver and support services. Well designed and implemented processes will be of little value if the day-to-day operation of those processes is not properly conducted, controlled and managed. Nor will service improvements be possible if day-to-day activities to monitor performance, assess metrics and gather data are not systematically conducted during Service Operation.
Principles:
When considering Service Operation it is tempting to focus only on managing day-to-day activities and technology as ends in themselves. However, Service Operation exists within a far greater context. As part of the Service Management Lifecycle it is responsible for executing and performing processes that optimize the cost and quality of services. As part of the organization it is responsible for enabling the business to meet its objectives. As part of the world of technology it is responsible for the effective functioning of components that support services.
Main Activities:
Monitoring and control It Operations Mainframe operations Server Management and support Network Management Storage and Archive Database Administration Directory Services Management Desktop Support Middleware Management Internet/Web Management Facilities and Data Centre Management Information Security Management and Service Operation Improvement of operational activities
70
Version 7.1
Service Operation Function: Service Desk

The business users / end-users need IT services to improve the efficiency of their own business processes. When they cant use the IT services, they have trouble achieving their objectives. End-users of services need a single point of contact with the IT organization. The Service Desk should be the single point of contact for all end-users. This is where ALL questions, issues and requests are logged and recorded. The type of Service Desk you need depends on the requirements of your customer base. ITIL defines Service desk types in terms of skill and structure.
Skill levels:
Call Centre Unskilled Service Desk Skilled Service Desk Expert Service Desk
Service Desk structures:

Centralized Service Desk Distributed Service Desk Virtual Service Desk Split Function Service Desk
71
V 7.1
ANECDOTE The Expert Service Desk

The Expert Service Desk extends the range of services and offers a more globally focused approach, allowing business processes to be integrated into the Service Management infrastructure. It not only handles Incidents, Problems and questions, but also provides an interface for other activities such as customer Change requests, maintenance contracts, software licenses, Service Level Management, Configuration Management, Availability Management, Financial Management for IT Services, and IT Service Continuity Management. Many Call Centres and Help Desks naturally evolve into Service Desks to improve and extend overall service to the Customers and the business. Why change from what you have? The Expert Service Desk provides a vital day-to-day contact point between Customers, Users, IT services and third-party support organisations. Service Level Management is a prime business enabler for this function. A Service Desk provides value to an organisation in that it: acts as a strategic function to identify and lower the cost of ownership for supporting the computing and support infrastructure supports the integration and management of Change across distributed business, technology and process boundaries reduces costs by the efficient use of resource and technology supports the optimization of investments and the management of the businesses support services helps to ensure long term Customer retention and satisfaction assists in the identification of business opportunities.
To introduce and maintain a successful Service Desk, it is essential that: business needs are understood Customer requirements are understood investment is made in training for Customers, support teams and Service Desk staff service objectives, goals and deliverables are clearly defined service levels are practical, agreed, and regularly reviewed the benefits are accepted by the business.
This really is only the tip of the iceberg, the more you read, the more you will understand that the Service desk becomes the face of IT.
72
Version 7.1
Service Operation Function: Technical Management

Technical Management refers to the groups, departments or teams that provide technical expertise and overall management of the IT Infrastructure.
Roles
It is the custodian of technical knowledge and expertise related to managing IT Infrastructure. In this role Technical Management ensures that the knowledge required to design, test, manage and improve IT services is identified, developed and refined. It provides the actual resources to support the IT Service Management Lifecycle. In this role Technical Management ensures that resources are effectively trained and deployed to design, build, and transition, operate and improve the technology required to deliver and support IT Services.
Objectives
The objectives of the Technical Management are to plan, implement and maintain a stable technical infrastructure to support the organizations business process through: Well designed and highly resilient, cost-effective technical topology The use of adequate technical skills to maintain the technical infrastructure in optimum condition Swift use of technical skills to speedily diagnose and resolve any technical failures that do occur.
73
Version 7.1
Service Operation Function: IT Operations Management

In Business the term ;Operations Management is used to mean the department, group or team of people responsible for performing the organizations day-to-day operational activities such as running the production line in a manufacturing environment or managing the distribution centres and fleet movements within a logistics organization. In a similar way IT Operations Management can be defined as the function responsible for the ongoing management and maintenance of an organizations IT Infrastructure to ensure delivery of the agreed level of IT service to the Business. IT Operations can be defined as the set of activities involved in the day-to-day running of the IT Infrastructure for the purpose of delivering IT Services at agreed levels to meet stated Business Objectives. Below is a brief list of the main roles performed by IT Operations Management.
Roles
Execute the ongoing activities and procedures required to manage and maintain the IT Infrastructure so as to deliver and support IT Services at agreed levels. Operational Control, overseas the execution and monitoring of the operational activities and events in the IT Infrastructure. Console Management, which refers to defining central observation and monitoring capacity and then by using those consoles to exercise monitoring and control activities. Job Scheduling or the management of routine batch jobs or scripts. Backup and Restore on behalf of all Technical and Application Management team and departments and often on behalf of users. Print and Output Management for the collation and distribution of all centralized printing or electronic output. Performance of maintenance activities on behalf of Technical or Application Management teams or departments. Facilities Management, which refers to the management of the physical IT environment, typically data centre or computer rooms and recovery sites together with all the power and cooling equipment.
Objective
Maintenance of the status quo to achieve stability of the organizations day-to-day processes and activities Regular scrutiny and improvements to achieve improved service at a reduced cost, whilst maintaining stability Swift application of operational skills to diagnose and resolve any IT operations failures that occur.
74
Version 7.1
Service Operation Function: Application Management

Application Management is responsible for managing Applications throughout their Life Cycle. The Application Management function is performed by any department, group or team involved in managing and supporting operational Applications. Application Management also plays an important role in the design, testing and improvement of applications that form a part of IT Services. As such they may be involved in development projects, but are not usually the same as the Application Development teams.
Role
Application Management plays a role in all applications, whether purchase or develop in-house. One of the key decisions that they contribute to is the decision of whether to buy an application or build it *(this will be discussed in Service Design). Since that decision is made, Application Management will play a dual role: Custodian of technical knowledge and expertise related to managing applications. In this role Applications Management, working together with Technical Management, ensures that the knowledge required to design, test, manage and improve IT Services is identified, developed and refined. Provide the actual resources to support the IT Service Management Lifecycle. In this role Applications Management ensures that resources are effectively trained and deployed to design, build, and transition, operate and improve the technology required to deliver and support IT Services. By performing these two roles Applications Management is able to ensure that the organization has access to the right type and level of human resources to manage applications and thus to meet business objectives. This starts, Service Strategy, is expanded in Service Design, tested in Service Transition and refined in Continuos Service Improvements.
Objectives
To support the organizations business processes by helping to identify functional and manageability requirements for application software, and then assist in the design and deployment of those applications and the ongoing support and improvement of those applications.
75
V 7.1
Service Operation Process: Event Management

An Event can be described as any detectable or discernable occurrence that has significance for the management of the IT infrastructure or the delivery of the IT service and evaluation of the impact a deviation might cause to the services. Events are typically notifications created by an IT Service, CI, or monitoring tool. Effective Service Operation is dependent on knowing the status of the infrastructure and detecting any deviation from normal or expected operation. This provided by good monitoring and control systems, which are based on two types of tools: Active monitoring tools that poll key CIs to determine their status and availability. Any exceptions will generate an alert that needs to be communicated to the appropriate tool or team for action Passive monitoring tools that detect and correlate operational alerts or communications generated by CIs
Goal
Detect Events, make sense of them, and determine the appropriate control action is provided by Event Management.
Objective
Provide and entry point for the execution of many Service Operation processes and activities. It also provides a way of comparing actual performance and behaviour against design standards and SLAs.
Scope
EM can be applied to any aspect of SM that needs to be controlled, and which can be automated. These include: C.IS (some CIs will be included because they need to stay in a constant state, e.g. switch on a network needs to stay on, EM tools confirm this by monitoring responses to pings) Some CIs will be included because their status needs to change frequently and EM can be used to automate this and update the CMS (e.g., updating of a file server). Environmental conditions (e.g., fire and smoke detection) Software licence monitoring for usage to ensure optimum/legal license utilization and allocation Security (intrusion detection) Normal Activity (e.g. tracking the use of an application or the performance of a Server)
76
Version 7.1
Service Operation Process: Request Fulfilment

The term service request is used as a generic description for many varying types of demands that are placed upon the IT department by the users. Many of these are actually small changes low risk, frequently occurring, low cost etc (e.g. a request to change a password, a request to install and additional software application onto a particular workstation, a request to relocate some items of desktop equipment. Or may be just a question requesting information -but their scale and frequent, low risk nature means that they are better handled by a separate process, rather than being allowed to congest and obstruct the normal Incident and Change Management processes.
Goal
Dealing with service requests from the users.
Objectives
Provide a channel for users to request and receive standard services for which a pre-defined approval and qualification can exist Provide information to users and customers about the availability of services and the procedure for obtaining them Source and deliver the components of requested standard services (e.g. licenses and software media) Assist with general information, complaints or comments
Scope
The process needed to fulfil a request will vary depending upon exactly what is being requested but can usually be broken down into a set of activities that have to be performed. Some organizations will be comfortable to let the service requests be handled through their Incident Management process (and tools) with service requests being handled as a particular type of incident. Ultimately , it will be up to each organization to decide and document which request it will handle through the Request Fulfilment process and which others will go though ore formal Change Management.
77
Version 7.1
Service Operation Process: Access Management

Access Management is the process of granting authorized users the right to use a service, while preventing access to no-authorized users.
Goal & Objective

Provide the right for users to be able to use a service or group of services. It is therefore, the execution of policies and actions defined in Security and Availability Management .
Scope
Ensure Users are given the right to use a service, but it does not ensure that this access is available at all agreed times (this would be Availability Management) Executed by all Technical and Application Management functions, and is usually not a separate function. Access Management can be initiated by a Service Request through the Service Desk.
78
Version 7.1
Service Operation Process: Incident Management

This process is in place to get the end-user back to work following an interruption to normal service delivery - as soon as possible. It is symptom-driven and the only concern is speed of response, and the continuation of the business process. Incident Management uses information out of the Problem Management process (work-a-rounds and Known Errors) and the Configuration Management process (linking Incidents to Configuration Items) A large component of Incident Management is the administration and tracking of the incident itself.
Goal & Objective

Restore normal service operation as quickly as possible and minimise the adverse impact on business operations. Therefore ensuring that the best possible levels of service quality and availability are maintained.
Scope
IM includes any Event which disrupts, or which could disrupt a service. This includes Events which are communicated directly by users, either through the Service Desk or through an interface from Event Management to Incident Management tools. Incidents can also be logged and/or reported by technical staff (e.g. if they notice something untoward with the hardware or network component, they may report or log an incident and refer it to the Service Desk). Although both Incidents and Service Requests are reported to the Service Desk, this does not mean they are the same. Service Requests do not represent a disruption to agreed service levels, but are a way of meeting the customer needs. Service Requests are dealt with by the Request Fulfilment process.
79
Version 7.1
ANECDOTE More on Incident Management

The line between the function of the Service Desk and the Incident Management process is perhaps the area of greatest confusion for most people regarding ITIL. It is best explained by making the point again that the Service Desk is a function and that Incident Management typically lies inside that function. If an end user calls the Service Desk they are making contact with a functional part of the IT Service Delivery. What takes place after the call is made and the end user is being looked after is part of the Incident Management process. Generally, most organisations have their Service Desk staff conducting Level 1 incident management support. However, this is not a caveat and the decision is dependant on the selected skill level of staff and Service Desk structure selected. Level 2 and beyond Incident Management staff can be tightly integrated into the Service Desk area, or they may be recognisable as a separate group of staff. In a lot of organisations who have adopted ITIL, the concept of Level 3 support has given way to the Problem Management process. The objective of Incident Management is to restore normal operations as quickly as possible with the least possible impact on either the business or the user, and at a cost-effective price. The definition of how quickly is quickly, should not be subject to interpretation. The timeframes for Incident resolution should be defined in the Service Level Agreements (SLAs) that exist between the IT Department and the customer. The speed of resolution will affect the cost. It is this cost-to-speed ratio that is often forgotten when a user faces problems. Issues that are low priority during negotiations are "somehow" escalated to the status of requiring high levels of attention when the issue occurs. Often support staff will simply respond to user pressure in such situations and immediately the expectation is adjusted and anything less than immediate response to this otherwise low priority issue is considered as poor service
80
Version 7.1
Service Operation Process: Problem Management

It is the intent of Problem Management to find Known Errors in the IT Infrastructure. Everything you do within this process is focused on: Finding what the Known Error is (Problem Control diagnosis) Identifying alternative solutions for the removal of the Known Error (Error control) Raising a request for change (RFC) to request for the deletion to happen Checks after a change is performed to see that the Known Error is gone
The Problem Management process also has an element of proactive troubleshooting. The concept here is to identify and facilitate the removal of errors before they manifest themselves as end-user complaints or queries.
Goal
Managing the Life Cycle of all problems
Objective
Prevent problems and resulting incident from happening, eliminate recurring incidents and to minimise the Impact of Incident that cannot be prevented.
Scope
Problem Management will also maintain information about problems and the appropriate workarounds and resolutions so that the organization is able to reduce the number and impact of incidents over time. In the respect Problem Management has a strong interface with Knowledge Management, and tools such as the Known Error Database will be used for both. Although Incident Management and Problem Management are separate processes, they are closely related and will typically use the same tools, and may use similar categorization, impact and priority coding systems. This will ensure effective communication when dealing with related Incidents and Problems.
81
V 7.1
ANECDOTE Problem Management Flow

There is no single flow from start to finish because the Problem Management process has both reactive and proactive aspects. Reactive Problem control is concerned with identifying the real underlying causes of Incidents in order to prevent future recurrences. The three phases involved in the (reactive) Problem control process are: Problem identification and recording Problem classification - in terms of the impact on the business Problem investigation and diagnosis.
When the root cause is detected the error control process begins. The Error control activity consists of: Error identification and recording Error assessment Recording the Error resolution Closes Error and associated problems
ITIL Problem Management process flow But that isnt all folks!
Now this is where problem management differs from being a simple flow that is does it achieve x yes now do this etc. Problem Management has a Proactive side. Problem prevention ranges from prevention of individual Problems, such as repeated difficulties with a particular feature of a system, through to strategic decisions. Problem prevention also includes information being given to Customers that negates the need to ask for assistance in the future. Analysis focuses on providing recommendations on improvements for the Problem solvers. The main activities within proactive Problem Management processes are trend analysis and the targeting of preventive action.
82
Version 7.1
Continual Service Improvement

Alongside the delivery of consistent, repeatable process activities as part of service quality, ITIL has always emphasized the importance of continual improvements. Focusing on the process elements involved in identifying and introducing service management improvements, this publication also deals with issues surrounding service retirement.
Purpose:
This area aims to provide practical guidance in evaluating and improving the quality of services, overall maturity of the ITSM service lifecycle and its underlying processes, at three levels within the organization: the overall health of ITSM as a discipline the continual alignment of the portfolio of IT Services with the current and future business needs the maturity of the enabling IT processes required to support business processes in a continual Service lifecycle model
Principles:
Service improvement must focus on increasing the efficiency, maximizing the effectiveness and optimizing the cost of services and the underlying ITSM processes. The only way to do this is to ensure that improvement opportunities are identified throughout the entire Service Lifecycle.
Main Activities:
Collect data and analyze trends compared to baselines, targets, SLAs and benchmarks. This would include output from Services and Service Management processes Set targets for improvement in efficiency and cost effectiveness throughout the entire Service Lifecycle Set targets for improvements in service quality and resource utilization Consider new Business and Security requirements Consider new external drivers such as regulatory requirements Create a plan and implement improvements Provide a means for staff members to recommend improvement opportunities Measure, report, and communicate on service improvement initiatives Revise policies, processes, procedures, and plans where necessary Ensure that all approved actions are completed and that they achieve the desired results
83
Version 7.1
Key Domains of CSI

Knowledge Management
Knowledge Management is one of the key domains in support of CSI in Knowledge Management. Capturing, organising, assessing for quality and using knowledge provides invaluable input for CSI activities. An organization has to gather knowledge and analyze what the results are in order to look for trends in service level achievements and/or results and output of Service Management processes. This input is used to determine what service improvement programs are to be worked on.
Plan, Do, Check, Act.
Continuous Improvement
Design
Plan Do
Pilot
Act
Check
Results
Rollout
Quality Assu
Source: Deming
rance
Improvement
48
The Deming cycle is critical at two pints of CSI: implementation and application of CSI to services and service management processes. At implementation all four stages of the Deming Cycle (Plan, DO, Check, Act) are used, With ongoing improvement, CSI draws on the Check and Act stages to monitor, measure, review and implement initiatives. The cycle is underpinned by a process-led approach to management whee defined processes are in place, the activities are measures for compliance to expected values and outputs are audited to validate and improve the process.
Baselines
An important point for highlighting improvement is to establish baselines as markers or starting points for later comparison. Baselines are also used to establish an initial date point to determine 84
V 7.1
if a service or process needs to be improved. As a result, it is important that baselines are documented, recognised and accepted throughout the organization. Baselines must be established at each level: strategic goals and objectives, tactical process maturity and operational metrics and KPIs.
Monitor, Measurement & Metrics

There are four main reasons to monitor and measure: To Validate monitoring and measuring to validate previous decisions To Direct monitoring and measuring to set direction for activities in order to meet set targets. It is the most prevalent reason for monitoring and measuring To Justify monitoring and measuring to justify, with factual evidence or proof, that a course of action is required. To intervene monitoring and measuring to identify a point of intervention including subsequent changes and corrective actions.
Metrics are a system of parameters or ways of quantitative assessment of a process that is to be measured, along with the processes to carry out the measuring. Metrics define what is to be measured. There are three types of metrics that an organization will need to collect to support CSI activities, as well as other process activities. The three types are: Technology metrics these metrics are often associated with component and application based metrics such as performance, availability etc. Process Metrics these metrics captured in the form of KPIs and activity metrics for the Service Management Processes. These metrics can help determine the overall health of the process. Four key questions that KPIs can help answer are around quality, performance, value and compliance of the following process. CSI would use these metrics as an input to identifying improvement opportunities for each process. Service Metrics these metrics are the results of the end-to-end service. Component metrics are used to compute the Service Metrics.
85
Version 7.1
C.S.I Process: Service Level Management

This process provides the contact point between the IT organization and the customer. Within the ITIL books, the customer is defined as being the person who pays for the services. It should therefore be someone with decision-making authority, e.g. business manager. Service Level Management is the process that ensures that the IT organization knows what services they can deliver and organises for the IT group and the customer to agree on the levels of service that need to be delivered. It also ensures that the IT group can consistently deliver these services to the customer by ongoing monitoring the service achievements and reporting these to the customer. Adopting the SLM process is a key principle of CSI. While in the past many IT organizations viewed SLM as merely a smattering of isolated agreements around system availability or help desk calls this is no longer true. SLM is no longer optional. Todays business demands that IT be driven by the service model. Thos service orientation of IT toward the business becomes the foundation for the trusted partnership that IT must endeavour to create. Today IT is a core enabler of every critical business process and must be integrated in every channel of communication and level of decision making. SLM involves a number of steps: Involving the business and determining their SLRs Defining the internal portfolio of Services: services that are planned, in development or in production. This service Portfolio also contains component services which will make up a finished Service Package. Defining a customer facing Service Catalogue which details every service and service package offered by IT with options, parameters and pricing. Identifying internal IT departmental relationships, negotiating the terms and responsibilities of the internal relationships and codifying them with Operational Level Agreements (OLAs). Identifying existing contractual relationships with external vendors. Verifying that these Underpinning Contracts (UCs) meet the revised Business requirements. Renegotiating, if necessary. Utilizing the Service Catalogue as a baseline, negotiate SLAs with the business. Create a Service Improvement Plan (SIP) to continually monitor and improve the level of service.
86
Version 7.1
WISE WORDS
To report or not to report A lot of the organisations that start implementing Service Level Management fall into the trap of over-reporting. Everything is monitored, and all results are reported back to the client. Negotiate the reporting strategy with your customer during the SLA-negotiations. A report is only valuable if your clients use it for their own work. Another pitfall is the fact that some people only report when things are going wrong. The image you build with an agreement like that is a negative one. The client only hears from IT when there is a problem or when service levels arent met. ALWAYS report on the positive things as well! Its OK to say NO Often, when you start implementing Service Level Management in your organisation youll find that you cant deliver a lot of the users requests. You cant deliver because you dont have the underpinning processes in place, you dont have enough budget and other required resources. Service Level Management is all about managing the expectations of your clients. Internal and external agreements The beauty of implementing ITIL is that everybody in the organisation speaks the same language, and therefore you need to be very strict with your choice of words. A Service Level Agreement is an internal agreement with your clients. An agreement with an external party is called an underpinning contract. An agreement within the IT group itself is called an OLA (Operational Level Agreement).
87
Version 7.1
This page has been left blank.
88

C. ITIL IT Service Management Beginners Guide v7.1

Transféré par

Informations du document

Description originale:

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

C. ITIL IT Service Management Beginners Guide v7.1

Transféré par

Droits d'auteur :

Formats disponibles

V 7.

Copyright: The Art of Service Pty Ltd 2007

Copyright: The Art of Service Pty Ltd, 2004-2007

Copyright: The Art of Service Pty Ltd, 2004-2007

Copyright: The Art of Service Pty Ltd, 2004-2007

ITIL Service Management Courses

Copyright: The Art of Service Pty Ltd, 2004-2007

ITIL Service Management

Copyright: The Art of Service Pty Ltd, 2004-2007

Input Activity Activity Goal

Processes, Services and Functions

Copyright: The Art of Service Pty Ltd, 2004-2007

Copyright: The Art of Service Pty Ltd, 2004-2007

Benefits of Adopting ITIL

Service Operation Continuous Service Improvement

Copyright: The Art of Service Pty Ltd, 2004-2007

Copyright: The Art of Service Pty Ltd, 2004-2007

Copyright: The Art of Service Pty Ltd, 2004-2007

Copyright: The Art of Service Pty Ltd, 2004-2007

Implementing ITIL Service Management Practices

Copyright: The Art of Service Pty Ltd, 2004-2007

Copyright: The Art of Service Pty Ltd, 2004-2007

IT Service Management Tools

The Cost of a Tool

Copyright: The Art of Service Pty Ltd, 2004-2007

ITIL Service Management Practices and Vendors

Copyright: The Art of Service Pty Ltd, 2004-2007

Benefit/risk analysis Implementing service design Measurement and control

Continual Service Improvement

Copyright: The Art of Service Pty Ltd, 2004-2007

Copyright: The Art of Service Pty Ltd, 2004-2007

ITIL SERVICE MANAGEMENT PRACTICES

Copyright: The Art of Service Pty Ltd, 2004-2007

Copyright: The Art of Service Pty Ltd, 2004-2007

Service Strategy Process: Financial Management for IT Services

Service Strategy Practice: Demand Management

Service Strategy Practice: Service Portfolio Management

Copyright: The Art of Service Pty Ltd, 2004-2007

Service Design Process: Security Management

Security Management has two objectives:

Copyright: The Art of Service Pty Ltd, 2004-2007

Copyright: The Art of Service Pty Ltd, 2004-2007

Copyright: The Art of Service Pty Ltd, 2004-2007

Copyright: The Art of Service Pty Ltd, 2004-2007

Relationships with other processes

Copyright: The Art of Service Pty Ltd, 2004-2007

Service Level Management

IT Service Continuity Management

Copyright: The Art of Service Pty Ltd, 2004-2007

Security section of the Service Level Agreement

The Security section of the Operational Level Agreement

Copyright: The Art of Service Pty Ltd, 2004-2007

Copyright: The Art of Service Pty Ltd, 2004-2007

Copyright: The Art of Service Pty Ltd, 2004-2007

Service Design Process: Service Catalogue Management

Service Design Process: Supplier Management

Copyright: The Art of Service Pty Ltd, 2004-2007

Service Design Process: Availability Management

Copyright: The Art of Service Pty Ltd, 2004-2007

Service Design Process: Capacity Management

ANECDOTE Why Bother?

Copyright: The Art of Service Pty Ltd, 2004-2007