itil v2 foundation complete certification kit: study guide book and online course

ITIL v2 Foundation Complete Certification Kit - Study Guide

©The Art of Service

Foreword___________________________ As an education and training organization within the IT Service Management (ITSM) industry, we have watched with enthusiasm as the ITIL framework has grown and progressed since its conception in the 1980’s. The evolution of the core principles and practices provided by the standard provides the holistic guidance needed for an industry that continues to mature and develop at a rapid pace. Our primary goal is to provide the quality education and support materials needed to enable the understanding and application of the ITIL version 2 framework in a wide-range of contexts. This comprehensive book is designed to complement the in-depth accredited eLearn ITIL v2 Foundation course provided by The Art of Service. The interactive eLearn course uses a combination of narrated PowerPoint presentations, with multiple choice assessments, which will ultimately prepare you for the ITIL v2 Foundation certification exam. We hope you find this book to be a useful tool in your educational library and wish you well in you IT Service Management career! The Art of Service © The Art of Service Pty Ltd

‘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.’

ITIL® is a Registered Community Trade Mark of OGC (Office of Government Commerce, London, UK), and is

Registered in the U.S. Patent and Trademark Office.

ITIL v2 Foundation Complete Certification Kit - Study Guide


How to access the associated ITIL v2 Foundation eLearning Program:

1. Direct your browser to: www.theartofservice.org 2. Click ‘login’ (found at the top right of the page) 3. Click ‘Create New Account’. If you already have an existing account, please move on to

step 5. 4. Follow the instructions to create a new account. You will need a valid email address to

confirm your account creation. If you do not receive the confirmation email check that it has not been automatically moved to a Junk Mail or Spam folder.

5. Once your account has been confirmed, email your User-ID for your new account to [email protected]

6. We will add your account to the ITIL v2 Foundation eLearning Program and let you know how to access the program from now on.

Minimum system requirements for accessing the eLearning Program:

Processor : Pentium III (600 MHz) or higher RAM : 128MB (256MB recommended) OS : Windows 98, NT, 2000, ME, XP, 2003, Mac OSX Browser : Internet Explorer 5.x or higher (Cookies and JavaScript Enabled), Safari Plug-Ins : Macromedia Flash Player 9 Other Hardware

: 16-bit Sound Card, Mouse, Speakers or headphones

Display Settings

: 1024x768 pixels

Internet Connection

: Due to multimedia content of the site, a minimum connection speed of 256kbs is recommended. If you are behind a firewall and are facing problems in accessing the course or the learning portal, please contact your network administrator for help

If you are experiencing difficulties with the Flash Presentations within the eLearning Programs please make sure that:

1) You have the latest version of Flash Player installed, by visiting http://www.adobe.com/shockwave/download/download.cgi?P1_Prod_Version=ShockwaveFlash

2) You check that your security settings in your web browser don't prevent these flash modules playing. There is support for these issues at the following page: http://kb.adobe.com/selfservice/viewContent.do?externalId=tn_19166&sliceId=2#no_content

ITIL v2 Foundation Complete Certification Kit - Study Guide 3


Table of Contents

FOREWORD____________________________ 1

1 INTRODUCTION________________________ 5

1.1 WHAT IS IT SERVICE MANAGEMENT? 5 1.2 THE FOUR PERSPECTIVES (ATTRIBUTES) OF ITSM 7 1.3 WHAT IS ITIL? 8 1.4 PROCESSES VS. SERVICES 10 1.5 FUNCTIONS 12 1.6 ROLES & RESPONSIBILITIES WITHIN ITIL V2 13 1.7 BUSINESS AND IT ALIGNMENT 14

2 COMMON TERMINOLOGY___________ 15

3 SERVICE DELIVERY PROCESSES______ 19

3.1 SERVICE LEVEL MANAGEMENT 20 3.1.1 SERVICE CATALOGUE 21 3.1.2 SERVICE IMPROVEMENT PLAN (SIP) 21 3.1.3 SERVICE QUALITY PLAN (SQP) 21 3.1.4 DESIGNING SLAS 22 3.1.5 TERMINOLOGY 24 3.1.6 INTERFACES WITH OTHER PROCESSES 25 3.1.7 QUIZ QUESTIONS 26 3.2 FINANCIAL MANAGEMENT 27 3.2.1 TERMINOLOGY 28 3.2.2 INTERFACES WITH OTHER PROCESSES 29 3.2.3 QUIZ QUESTIONS 30 3.3 CAPACITY MANAGEMENT 31 3.3.1 SUB-PROCESSES 32 3.3.2 ACTIVITIES 33 3.3.3 INTERFACES WITH OTHER PROCESSES 34 3.3.4 QUIZ QUESTIONS 35 3.4 AVAILABILITY MANAGEMENT 36 3.4.1 ACTIVITIES 37 3.4.2 AVAILABILITY METRICS 39 3.4.3 TERMINOLOGY 40 3.4.4 INTERFACES WITH OTHER PROCESSES 41 3.4.5 QUIZ QUESTIONS 42 3.5 IT SERVICE CONTINUITY MANAGEMENT 43 3.5.1 ITSCM STAGES 43 3.5.2 TERMINOLOGY 45 3.5.3 INTERFACES WITH OTHER PROCESSES 46 3.5.4 QUIZ QUESTIONS 47 3.6 SECURITY MANAGEMENT (SEPARATE ITIL V2 BOOK) 48 3.6.1 ACTIVITIES 49 3.6.2 INTERFACES WITH OTHER PROCESSES 51 3.6.3 QUIZ QUESTIONS 52



4 SERVICE SUPPORT FUNCTION & PROCESSES_ 53

4.1 CONFIGURATION MANAGEMENT 54 4.1.1 ACTIVITIES 55 4.1.2 TERMINOLOGY 56 4.1.3 INTERFACES WITH OTHER PROCESSES 57 4.1.4 QUIZ QUESTIONS 58 4.2 SERVICE DESK (FUNCTION) 59 4.2.1 ACTIVITIES 60 4.2.2 TERMINOLOGY 60 4.2.3 QUIZ QUESTIONS 61 4.3 WHAT IS THE DIFFERENCE BETWEEN AN INCIDENT AND A PROBLEM? 62 4.4 INCIDENT MANAGEMENT 63 4.4.1 ACTIVITIES 64 4.4.2 INTERFACES WITH OTHER PROCESSES 65 4.4.3 QUIZ QUESTIONS 66 4.5 PROBLEM MANAGEMENT 67 4.5.1 ACTIVITIES 67 4.5.2 TERMINOLOGY 68 4.5.3 INTERFACES WITH OTHER PROCESSES 69 4.5.4 QUIZ QUESTIONS 70 4.6 CHANGE MANAGEMENT 71 4.6.1 ACTIVITIES 72 4.6.2 TERMINOLOGY 73 4.6.3 INTERFACES WITH OTHER PROCESSES 74 4.6.4 QUIZ QUESTIONS 75 4.7 RELEASE MANAGEMENT 76 4.7.1 ACTIVITIES 77 4.7.2 TERMINOLOGY 78 4.7.3 INTERFACES WITH OTHER PROCESSES 79 4.7.4 QUIZ QUESTIONS 80 4.7.5 QUIZ ANSWERS 82

5 CERTIFICATION_____________________ 83

5.1 ITIL V2 CERTIFICATION PATHWAYS 83

6 ITIL FOUNDATION EXAM TIPS______ 84

7 REFERENCES______________________ 85



1 Introduction________________________

1.1 What is IT Service Management? IT Service Management is the management of all processes that co-operate to ensure the quality of live services, according to the levels of service agreed with the customer. It addresses the initiation, design, organization, control, provision, support and improvement of IT services, tailored to the needs of the customer organization. The term IT Service Management (ITSM) is used in many ways by different management frameworks and organizations seeking governance and increased maturity of their IT organization. Standard elements for most definitions of ITSM include:

• Description of the processes required to deliver and support IT Services for customers.

• The purpose primarily being to deliver and support the products or technology needed by the business to meet key organizational objectives or goals.

• Definition of roles and responsibilities for the people involved including IT staff, customers and other stakeholders involved.

• The management of external suppliers (partners) involved in the delivery and support of the technology and products being delivered and supported by IT.

The combination of these elements provide the capabilities required for an IT organization to deliver and support quality IT Services that meet specific business needs and requirements. IT Service Management gives the following benefits to the customer:

Provision of IT services becomes more customer-focused and the relationship between the service provider and the customer is improved through agreements about service quality

The services are better described, in customer language and in more appropriate detail

The availability, reliability, cost and other quality aspects of the service are better managed

Communication with the IT organization is improved by agreeing on points of contact



IT Service Management gives the following benefits to the organization as a whole:

The IT organization develops a clearer structure, is more efficient and is more focused

The IT organization is more in control of the infrastructure and the services it has responsibility for

An effective process structure provides a framework for the effective outsourcing of the IT services

Best Practice encourages a cultural change

Frameworks can provide coherent frames of reference for internal communication (and with suppliers) for the standardization and identification of procedures.



1.2 The Four Perspectives (Attributes) of ITSM

There are four perspectives (“4P’s”) or attributes to explain the concept of ITSM.

• Partners/Suppliers Perspective: Takes into account the importance of Partner and External Supplier relationships and how they contribute to Service Delivery. • People Perspective: Concerned with the “soft” side: IT staff, customers and other stakeholders e.g. Do staff have the correct skills and knowledge to perform their roles? • Products/Technology Perspective: Takes into account IT services, hardware & software, budgets, tools. • Process Perspective: Relates to end-to-end delivery of service based on process flows.

Quality IT Service Management ensures that all of these four perspectives are taken into account as part of the continual improvement of the IT organization.



1.3 What is ITIL? The Information technology Infrastructure Library (ITIL) is merely a set of books. There are 8 core components (books) of the ITIL Framework. These books combine to form a natural bridge between the Business and Technology the business uses to achieve its objectives:

Planning to implement Service Management: this volume explains how an organization might expect to benefit from ITIL and how to set about reaping those benefits. The Business Perspective (2 books): this volume is concerned with helping business managers to understand IT service provision. ICT Infrastructure Management: this volume focuses on processes, organization and tools needed to provide a stable IT and communications infrastructure. Applications Management: this volume a guide for business users, developers and service managers of how applications can be managed from a service management perspective. Software Asset Management: this volume has been developed to assist with understanding what Software Asset Management (SAM) is and to explain what is required to perform it effectively and efficiently as identified in industry 'best practice.'

Service Support

Service Delivery

Security Management

The Business

Perspective

ICT Infra-structure

Mgt.

Planning to Implement Service Management

Applications Management

The Bu S i ne s s

The Te chno l ogy Software Asset Management



20

Service LevelManagement

FinancialManagement

Capacity Management

Availability Management IT Service ContinuityManagement

IncidentManagement

Problem Management

Change Management

Configuration Management

Release Management

Service Desk

Security Management

Security Management: this volume gives guidance on how to approach IT Security Management and how to align the level of security with the Service Level Requirements from the business. Service Support focuses on ensuring that the customer has access to appropriate services to support the business functions. Issues covered include service desk, incident management, problem management, configuration management, change management, and release management. It expands the necessary interactions between these and other core IT service management disciplines and updates best practice to reflect recent changes in technology and business practices. Service Delivery covers all aspects that must be taken into consideration by service providers who must offer business users adequate support. Issues covered include Service Level Management, Financial Management for IT Services, IT Service Continuity Management, Availability Management Contingency Planning, and Capacity Management. The purpose of Service Delivery is to show the links and the principal relationships between all the Service Management and other Infrastructure Management processes. Most people don’t even know that the ITIL library contains 9 books because most certification programs only contain the Service Support and Service Delivery concepts. When you do your exam with EXIN (and this certification kit builds towards the EXIN accreditation), Security management is included as part of the course materials. But the other books are hardly ever touched on in the certification programs. The 12 concepts (11 processes and 1 function) that will be the focus of this ITIL v2 Foundation program are:



1.4 Processes vs. Services A process is a set of coordinated activities combining and implementing resources and capabilities in order to produce an outcome and provide value to customers or stakeholders. There are four characteristics of every process: 1) They are measurable, 2) They deliver specific results 3) They deliver outcomes to customers or stakeholders 4) They respond to specific events (triggers) Example to illustrate business and IT alignment: What is the Goal? To bake a cake What are the inputs? Ingredients (eggs, milk, flour, sugar, chocolate etc) What are the activities? Mix ingredients, pre-heat oven, bake, cool, decorate. What are the measures? How much ingredients to use, how long to bake, temperature etc. What are the norms? The recipe. Description of process (inputs, outputs, procedures). What are the outputs? CAKE!!!! How would you measure effectiveness? The finished cake meets the defined standards (“doing the right things”)



How would you measure efficiency? The cake is made with minimum effort and time (“doing things right”) Unlike a project, a process is never ending. In this example, baking a specific cake (e.g. a birthday cake for Jane) is a project. The activities, inputs, outputs, goals, measures and norms defined, makes up the process for baking cakes. A process owner is responsible for improvements and ensuring that the process is fit for the desired purpose. They are accountable for the outputs of that process. In the ‘cake’ example the process owner would be the head chef – accountable for the finished product. A service is a means of delivering value to Customers by facilitating the outcomes customers want to achieve without the ownership of specific costs or risks A service owner is accountable for the delivery of a specific IT Service and is responsible for continual improvement and management of change affecting Services under their care. In the ‘cake’ example the service owner would be the bakery owner – accountable for the service provided. Both process owners and service owners are accountable for the process or service under their care. However they may not be responsible for performing many of the actual activities required for the process or service. A Process Manager is responsible for the operational management of a process. There may be several Managers for the one process. Each of these terms and definitions are important for your Foundation knowledge and understanding of the v2 framework, and in preparation for your Foundation exam. Chapter 2 of this certification book has more general terms and concepts that you will need to be familiar with. We will look at process specific terminology and acronym definitions as we progress through the Service Delivery and Service Support processes.



1.5 Functions

Functions refer to the people and automated measures that execute a defined process, an activity or combination of both. The functions are needed to manage the ‘steady state’ operation IT environment. Just like in sports where each player will have a specific role to play in the overall team strategy, IT Functions define the different roles and responsibilities required for the overall Service Delivery and Support of IT Services.

A Function is defined as: A team or group of people and the tools they use to carry out one or more Processes or Activities

Functions provide units of organization responsible for specific outcomes. For example, The Service Desk function is responsible for performing activities from the ITIL process Incident Management.

NOTE: The Service Desk is the only function formally acknowledged within the ITIL version2 framework.



Differences in RACI roles The differences in roles are normally based on guidelines such as:

• Accountable (e.g. the buck stops here) • Person with YES/NO authority, sign-off, approval, veto; • Should be no more than ‘one per row’;

• Responsible (e.g. the doer) • Takes initiative to accomplish a task/function/decision; • Develops alternatives • Consults and informs others

• Consulted (e.g. kept in the loop) • Asked for input prior to decision/action; • Part of two-way communication • Can be initiated or solicited;

• Informed (e.g. keep in the picture)

• Told about a decision/action usually after the fact; • Permission is not sought from this person; • One-way communication; • May be prior to going public to a wide audience.

1.6 Roles & Responsibilities within ITIL v2 Achieving successful integration of the ITIL v2 framework requires roles and responsibilities to be clearly defined. Clarity on ‘who does what’ allows processes to remain consistent and efficient in the delivery and support of services. ITIL v2 recognizes that each service provider may implement and allocate roles differently. It does not specify how roles and responsibilities should be documented. Matrices, in various forms, can be used for this purpose. For example, RACI matrices identify who is responsible, accountable, consulted or

informed within each process or activity. Alternately, a detailed description of each role, for example, the auditor, can be used to clearly state their responsibilities and what needs to be achieved.



1.7 Business and IT Alignment It is important to illustrate the alignment between the Business and IT. The objective tree is a tool that can be used to understand and explain to other how the Business and IT should be aligned. This image provides an example of an objective tree. The corporate goals and objectives flow down to the business process level. Business processes are supported by the IT organization. IT goals and objectives flow down in the (IT) business processes and are supported by technical processes and functions. This way all activities, processes and IT services are aligned to the corporate goals and objectives. IT Service Management enables the IT group to provide effective and efficient Information Systems to meet the requirements of the business processes. This in turn enables the organization to meet its Business Objectives. ITSM may also be critical in providing the business with a source of competitive advantage in the market place.

If we don’t manage the IT Services appropriately we cannot rely on these services to be available when we need. If this occurs we cannot adequately support our business processes effectively and efficiently. And therefore we cannot meet or support our overall organization’s objectives!!!

Example to illustrate business and IT alignment: Business: A fashion store What are some of your organization’s objectives or strategic goals? We want to make a lot of money $$$! We want to have a good image and reputation. What Business Processes aide in achieving those objectives? Retail, marketing, buying, procurement, HR etc. What IT Services are these business processes dependent on? Web site, email, automatic procurement system for buying products, Point of Sale Services We have ITSM in order to make sure the IT Services are: What we need (Service Level Management, Capacity Management) Available when we need it (Availability MGT, Incident MGT etc.) Provisioned cost-effectively (Financial MGT, Service Level MGT)



2 Common Terminology___________ Critical to our ability to participate with and apply the concepts from the ITIL v2 framework is the need to be able to speak a common language with other IT staff, customers, end-users and other involved stakeholders. This next section documents some of the common terminology that is used throughout the books. Additional process specific concepts and terms will be covered in more detail, throughout chapters 3 and 4. Term

Definition

Availability

Ability of a component or service to perform its required function as a stated instant or over a stated period of time. Note: Availability is usually expressed as a ratio of the time that the service is actually available for use by the business to the agreed service hours.

Baseline

Snapshot of the state of a service is actually available for use by the business to the agreed service hours. A useful tool for later comparison.

Capabilities

The functions and processes utilized to manage services. Capabilities are intangible assets of an organization and cannot be purchased, but must be developed and matured over time.

Change record

Record containing details of which configuration items are affected and how they are affected by the authorized change.

Configuration Items (CI)

Component of an infrastructure or an item which is, or will be, under the control of configuration management. Note: configuration items may vary widely in complexity, size and type, ranging from an entire system including all hardware, software and documentation, to a single module or a minor hardware component.



Configuration Management Database (CMDB)

Database containing all the relevant details of each configuration item and details of the important relationships between them.

Customer Refers to the person who “pays” for the service, or has the authority to request a service.

Function A team or group of people and the tools they use to carry out one or more Processes or Activities. Functions provide units of organization responsible for specific outcomes.

Good Practice (also referred to as Best Practice) That which is successful in “wide industry use”

Incident Any event which is not part of the standard operation of a service and which causes or may cause an interruption to , or a reduction in, the quality of that service.

ITIL IT Infrastructure Library

ITSM IT Service Management

IT Infrastructure

All the hardware, software, networks, facilities, services and support elements that are required to develop, test, deliver, monitor, control and support IT Services.

Operational Level Agreement (OLA)

Internal agreement which supports the IT organization in the delivery of services

Problem

Unknown root cause of one or more existing or potential Incidents.

Process

A set of coordinated activities combining and implementing resources and capabilities in order to produce an outcome and provide value to customers or stakeholders.



Procedure

A set of specific steps that describe how an activity should be carried out, and by whom.

Release

Collection of new and/or changed configuration items which are tested and introduced into the live environment together.

Request for change Form or screen used to record details of a request for change to any configuration item within a service or infrastructure.

Resources A generic term that includes IT Infrastructure, people, money or anything else that might help to deliver an IT service. Resources are also considered to be tangible assets of an organization.

Service Catalogue

Written statement of available IT services, default levels, options, prices and which business processes or customers use them

Service Desk

Customer facing support group who do a high proportion of the total support work.

Service Level Agreement (SLA)

Written agreement between a service provider and a customer that documents services and agreed service levels.

Service Level Requirements

Detailed recording of the customer’s needs, forming the design criteria for a new or modified service

Service Management

Management of services to meet the business requirements.

Service Provider

An organization supplying services or products to customers. The Service Provider maybe internal or external.



Specification

A standard that sets out ‘detailed requirements’, using the prescriptive ‘shall’, to be satisfied by a product, material process or system. In ISO/IEC 20000 the verbs shall (and should) refer to aspects of the management processes, also including policy, procedures, plans and objectives.

Underpinning Contract (UC)

Contract with an external supplier that supports the IT organization in their delivery of services

(End) User

An organization’s staff member/employee who “uses” the IT service.

Vital Business Function (VBF)

Business critical functions of the business, supported by an IT service.

Work-around

Method of avoiding an Incident or Problem, either by employing a temporary fix or technique that means a customer is not reliant on a CI that is known to cause failure...

Work Instruction

A detailed set of instructions that describe exactly how a low-level activity must be carried out.



3 Service Delivery Processes______

This section contains the following processes:

• Service Level Management • Financial Management for IT Services • Capacity Management • Availability Management • IT Service Continuity Management • Security Management (A separate book to Service Delivery, but included in this

section)



Service LevelManagement

CapacityManagement

FinancialManagement

IT ServiceContinuity

Management

AvailabilityManagement

3.1 Service Level Management

OBJECTIVE: To maintain and improve IT Service Quality through a constant cycle of agreeing, negotiating, monitoring and reporting upon IT Service achievements and instigation of cost-justifiable improvements.

Service Level Management focuses on the management of services based on tangible records of services, service level targets and the characteristics of the workload. This process is fundamental to achieving a reasonable balance between service cost, quality and workloads. Through negotiation and formal agreement of Service Level Agreements (SLAs), Service Level Management establishes an understanding of the responsibilities of the service provider and of the customers. SLAs are further supported by Operational Level Agreements (OLAs) and Underpinning Contracts (UCs). Service level management is a series of activities including:

• Composing a service catalogue • Agreeing on the service to be provided • Monitoring the service levels • Reporting on results • Reviewing service levels

This process should encourage both the service provider and the customer to develop a proactive relationship to ensure that they have a joint responsibility for the service. Customer satisfaction is an important part of service level management but it should be recognized as being a subjective measurement, whereas service targets within the SLA should be objective measurements.



Specifically SLM is concerned with:

• Designing and planning the SLM process and Service Level Agreement (SLA) Structure.

• Determining the requirements of customers groups to produce Service Level Requirements (SLRs)

• Negotiating and Agreeing upon the relevant Service Level targets with customers to produce Service Level Agreements

• Negotiating and Agreeing upon the support elements required by the internal IT groups to produce Operational Level Agreements (internal) and with External Suppliers for Underpinning Contracts (external).

• Produce and maintain Service Catalogue • Guarding Agreements with customer • Monitoring Service Levels • Reporting to Customer

3.1.1 Service Catalogue Service Level Management must ensure that a Service Catalogue is produced, maintained and contains accurate information on all operational services and those ready for deployment. A Service Catalogue is a written statement of all current and available IT services, default levels and options.

3.1.2 Service Improvement Plan (SIP)

Service Level Management will create a SIP. This is a formal plan or program that is developed when the IT Service Provider is not currently delivering a service that meets the legitimate Service Level Requirements (SLR’s) of the business representative or when greater cost effectiveness is achievable. The SIP should include clear milestones, which will enable the business representative to judge whether or not timely progress is being made.

3.1.3 Service Quality Plan (SQP)

Service Level Management will also be accountable for the SQP. This plan underlies the service strategy, detailing the internal targets to be achieved within an agreed period, typically one to two years, to improve agreed service levels and the business perception of service quality.



3.1.4 Designing SLAs SLAs can be either Customer or Service based,

Customer based SLA: Separate SLA for each customer, covering multiple services. This may be used when individual customers have very different needs and requirements. Service based SLA: SLA covers one service for all customers of that service. This type of SLA is used when the requirements of the IT service differs little between customers. Typical contents of SLAs include:

• Introduction • Service description • Mutual responsibilities • Scope • Service hours • Service availability • Reliability • Customer support • Contact points & escalation • Service performance • Batch turnaround times • Security • Charging etc.

It is also common for a combination of SLAs to be used.



Multi-level SLAs:

o Corporate level - All generic issues are covered, which are the same for the entire organization. E.g. the Corporate Security Baseline, e.g. Passwords, ID cards etc.

o Customer level - Those issues specific to a customer can be dealt with. E.g. Security requirements of one department within the organization are higher than another.

o Service Level - All issues relevant to a specific service (in relation to this customer)

can be covered e.g. the email services for a particular department needs encryption and secure backups.

This structure reduces the duplication of effort while still providing customization for customers and services (inheritance). Information contained within an SLA must be measureable. The language used should always be clear and concise in order to aid understanding. SLAs are not used as legal documents for imposing penalties; otherwise they are in conflict with the goal of improving relationships between customers and the IT Service provider.



3.1.5 Terminology

• Service Level Achievements - The Service Levels that are realized • SIP (Service Improvement Plan) Actions, phases and delivery dates for

improvement of a service. • SQP (Service Quality Plan) – not specifically an SLM term, but strategically linked

to management information for steering the IT organization • Process parameters of the Service Management processes and the operational

management • Key Performance Indicators: • Incident Management: resolution times for levels of impact • Change Management: processing times and costs of routine changes • OLA (Operational Level Agreement)A written agreement with another internal IT

department to support the SLA • UC (Underpinning Contract) a written agreement with an external IT supplier



3.1.6 Interfaces with Other Processes



3.1.7 Quiz Questions Question 1 A Process owner is responsible for which of the following?

a) Purchasing tools to support the Process b) Defining the targets that will be used to evaluate process performance c) Ensuring that availability targets specified in SLAs are met d) Carrying out all the activities defined in the Process

Question 2 Functions are best described as?

a) Self-Contained units of organizations b) Inter-related activities with a defined goal or output c) Closed loop control systems d) A team of IT staff who provide a single point of contact for all user communication

Question 3 Of the following which is not part of Service Level Management?

a) Service Level Requirement b) Service Desk. c) Service Catalogue d) Service Improvement Plan

Question 4 Processes can be described as?

a) Activities designed to make delivering IT Services more effective and efficient b) People and the tools they use to carry out activities that gain revenue c) Inter-related activities carried out for the purpose of creating value for customers or

stakeholders d) Capabilities used to reduce IT costs

Question 5 You have been asked to send some information about the services you provide to a customer in another city. Which document do you need to send them?

a) Operational Level Agreement b) Underpinning contract c) Service Catalogue d) Service Level Agreement.



3.2 Financial Management

The IT services market can be divided by the primary methods of purchases made by end-users and service providers:

• Discrete — Project-specific contractual arrangement, with a predetermined scope of work to be completed within a given time period

• Outsourcing — Annuity-based contractual arrangement that details how an organization will provision services on an ongoing basis at a specified level of competency. Outsourcing arrangements usually last between two and five years, but may be either shorter or longer.

In both cases it is vital to have a Financial Management process implemented. Control of IT spending is fundamental to the effective and efficient running of an IT organization.

OBJECTIVE: To provide cost-effective stewardship of the IT assets and resources used in providing IT Services

The aims for any IT Services organization should include:

To be able to fully account for the spend on IT Services and to be able to assign these costs to the services delivered to the organization's Customers

To assist management decisions on IT investment by providing detailed cost analysis regarding changes to IT Services

Budgeting is involved with the planning and controlling of activities within the organization. Corporate and strategic planning considers the long-term objectives of a business.



Budgeting then defines the financial plans for meeting those objectives during the period covered by the budget (one to five years). There are two ways of budgeting:

• Incremental budgets • Zero-based budgets

Accounting identifies and understands the costs that IT is responsible for, in order for the IT organization to be run as a business. Costs must always be determined, even when they are not charged to customers. In practice, many service providers will be involved in charging for IT services. However, as charging is an optional activity, it is not covered by the standard. Service providers are recommended that where charging is in use, the mechanism for doing so is fully defined and understood by all parties.

Charging is an optional activity within Financial Management for IT Services. The decision whether the IT department will charge customers for the actual provision of IT services is made at a strategic level – not from within the IT department. Charging must be linked to controllable aspects for customers as they may wish to alter their behaviour/usage of services based on the charges they incur. Notional charging is a technique whereby a customer is informed of what the charge would be for the service used, although no actual funds change hands; often used as a stage in the introduction of full charging to an organization. There are several Charging Policies (Pricing):

• Cost Price (Simple recovery of costs associated with provision of services) • Cost Price + (Cost price plus a percentage mark up value) • Going Rate (Deriving charge based on other departments charges) • Market Price (Price charged by a third party provider) • Fixed Price (Agreed price independent of actual usage of services)

3.2.1 Terminology

• Accounting Centre - Simply costing inputs with maybe some elements of budgeting (no billing)

• Recovery Centre - Account fully for all IT spend and recover costs from the customer

• Profit Centre - The IT organization operates as a separate business unit • Notional Charging - To create cost-awareness without the physical exchange of

money. “If we were going to charge you, this is how much you would have to pay” • Differential Charging - To try to influence behaviour use of services at peak times

may attract penalty fees and likewise use of services at non-peak times attracts overall lower charges for the customer.



3.2.3 Quiz Questions Question 6 Which of the following is not a part of Financial Management for IT Services?

a) Charging. b) Budgeting. c) Accounting. d) Procurement.

Question 7 Which ITIL process is responsible for drawing up a charging system?

a) Availability Management b) Change Management c) Financial Management for IT Services d) Service Level Management.

Question 8 Which information does the "Financial Management for IT Services" process deliver to Service Level Management?

a) the cost of hiring new IT staff b) The costs of the Financial Management system c) The total costs Applications d) How much has been spent on IT services per client.

Question 9 Which of the following is a responsibility of Service Level Management?

a) Design the configuration management system from a business perspective b) Create technology metrics to align with customer needs c) Creation of a Service Catalogue d) Train service desk on how to deal with customer complaints about service

Question 10 Which of the following statements are CORRECT about Functions? 1. They provide structure and stability to organizations 2. They are self-contained units with their own capabilities and resources 3. They rely on processes for cross-functional coordination 4. They are costlier to implement compared to processes

a) 1, 2 and 3 only b) 1, 2 and 4 only. c) All of the above. d) None of the above



Business Strategy

Business Plan

IS / IT Strategy

IS / IT Business Plan

Capacity Management

Requirements Reports & Advice

3.3 Capacity Management Every application makes its own demands on the IT environment. Some are unavoidable, such as the continuing spread of applications for enterprise resource planning (ERP), supply chain management or human-resources management. Also new applications are emerging (e.g., those employing multimedia content) that will impact IT with their heavy demands for bandwidth. Finally, additional applications are required to support the growing IT infrastructures of organizations (e.g. remote storage of back-up data, for example).

Failure to consider these issues will lead to under and negative effects on the business, as the capacity of the IT Environment simply does not match the requirements of the business.

OBJECTIVE: The Capacity Management process understands the business requirements (the required Service Delivery), the organization's operation (the current Service Delivery) and the IT Infrastructure (the means of Service Delivery). It ensures that all the current and future Capacity and performance aspects of the business requirements are provided cost-effectively Configuration Management.

It is all about managing the right capacity, at the right location, at the right moment, for the right customer, against the right costs, in order to meet the current and future capacity and performance demands.



3.3.1 Sub-Processes

Business Capacity Management: This sub-process is responsible for ensuring that the future business requirements for IT Services are considered, planned and implemented in a timely fashion. This can be achieved by using the existing data on the current resource utilization by the various services to trend, forecast or model the future requirements. These future requirements come from business plans outlining new services, improvements and growth in existing services, development plans etc.

Service Capacity Management: The focus of this sub-process is the management of the performance of the live, operational IT Services used by the Customers. It is responsible for ensuring that the performance of all services, as detailed in the targets in the SLAs and SLRs, is monitored and measured, and that the collected data is recorded, analyzed and reported. As necessary, action is taken to ensure that the performance of the services meets the business requirements. This is performed by staff with knowledge of all the areas of technology used in the delivery of end-to-end service, and often involves seeking advice from the specialists involved in Resource Capacity Management.

Resource Capacity Management: The focus in this sub-process is the management of the individual components of the IT Infrastructure. It is responsible for ensuring that all components within the IT Infrastructure that have finite resource are monitored and measured, and that the collected data is recorded, analyzed and reported. As necessary, action must be taken to manage the available resource to ensure that the IT Services that it supports meet the business requirements. In carrying out this work, the Capacity Management process is assisted by individuals with specialist knowledge in the particular areas of technology.



Business CapacityManagementBusiness CapacityManagement

Service Capacity ManagementService Capacity Management

Resource Capacity ManagementResource Capacity Management

Capacity PlanningCapacity Planning

ReportingReporting

CDB

ModellingModellingApplicationSizing

ApplicationSizing

DemandMgt.

DemandMgt.

Iterative ActivitiesIterative Activities

Storage ofCM data

Storage ofCM data

3.3.2 Activities Iterative Activities (Performance Management)

• Analysis • Tuning - Modifications made for better utilizations of current infrastructure (under

the control of Change Management) • Implementation • Monitoring

Other Activities

• Demand management - Aims to influence the use of capacity, perhaps by incentive or penalty, in circumstances where unmanaged demand is likely to exceed the ability to deliver. Demand Management is achieved by assigning resources according to priorities.

• Application sizing - Determining the service level, resource and cost implications of any new application or any major addition or enhancement to an existing application.

• Modelling – A set of tools and techniques used to predict the performance of a specified system under a given volume and variety of work. Modelling is used to predict the availability and performance of services.

• Capacity Management Database – Used by all activities in the process for storage of Capacity Data e.g. technical, business, financial, service and utilization data.

• Capacity Plan development and maintenance – the Capacity Plan predicts demand for IT services and outlines the resources needed to meet this. It will contain costed possible scenarios for IT services together with a recommended option.



3.3.4 Quiz Questions Question 11 Of the following which is not an activity or sub-process of the Capacity Management process?

a) Business Capacity Management b) Financial Capacity Management c) Resource Capacity Management. d) Service Capacity Management

Question 12 What is the name of the activity within the Capacity Management process whose purpose is to predict the future capacity requirements of new and changed services?

a) Application Sizing b) Demand Management c) Modelling d) Tuning

Question 13 In which ITIL process are negotiations held with the customer about the availability and capacity levels to be provided?

a) Availability Management b) Capacity Management c) Financial Management for IT Services d) Service Level Management

Question 14 Which of the following is NOT an activity of Capacity Management?

a) Modelling b) Tuning c) Maintenance d) Application Sizing

Question 15 Which of the following is a responsibility of Service Level Management?

e) Design the configuration management system from a business perspective f) Create technology metrics to align with customer needs g) Creation of a Service Catalogue h) Train service desk on how to deal with customer complaints about service



3.4 Availability Management

Gartner research shows that people and/or process failures directly cause an average of 80 percent of mission-critical application service downtime. The other 20 percent is caused by technology failure, environmental failure or a disaster. The complexity of today's IT infrastructure and applications makes “high-availability” systems management difficult. Applications requiring high levels of availability must be managed with operational disciplines – including network monitoring, systems management activities, etc. - to avoid unnecessary and potentially devastating outages. Availability Management is a proactive operations management discipline, which has direct and high returns from an application availability perspective. This discipline involves the use of automated tools to avoid problems (e.g., automatically increasing available file space when a threshold is reached) and job scheduling to reduce operator error and improve the availability of batch applications and data.

OBJECTIVE: To optimise the capability of the IT Infrastructure, services and supporting organisation to deliver a Cost effective and sustained level of Availability that enables the business to satisfy its business objectives.

.



3.4.1 Activities 1. Determining availability requirements

• Input from Service Level Management The service Level Manager discusses with the client what their needs for service are (Service Level Requirements) Based on these requirements, the availability manager can determine the availability requirements. 2. Determining vital business functions (VBF’s)

• Input for IT Service Continuity Management Naturally, some business processes are more critical than others. For example the payroll function is considered to be very important, but not vital. When the payroll system doesn’t work, you can always pay the employees the same amount as last pay-date. Although very important, payroll is considered a non-vital business function. Invoicing however if often considered to be vital, as you can’t collect money without sending an invoice. IT systems that support this function should have higher availability expectations and the appropriate systems and support to achieve and sustain these higher levels. 3. Business impact analysis – a formal analysis of the affect on the business if a specific

set of IT services are not available. It will also identify the minimum set of services that an organization will require to continue operating.

• Risk Analysis Management (input for IT Service Continuity Management) This activity is trying to identify the impact to the business of service unavailability. It is part of our risk analysis and risk management activities. The outcomes of these activities are utilized in various processes: availability mgt, IT Service continuity Mgt and Information Security Mgt. 4. Defining availability, reliability and maintainability targets

• Input for Service Level Agreements (SLAs) and other contracts Based on the first three steps, we are now ready to create the achievable and sustainable availability targets. In order to do this, we need to get input from all technical areas within the IT group. (as well as suppliers) 5. Monitoring & trend analysis

• MTBF (Mean Time between Failures) • MTBSI (Mean Time between System Incidents) • MTTR (Mean Time to Repair) • Planned downtime, unscheduled downtime, Extended (excess) Downtime • Frequent (scheduled) backups

6. Root cause analysis of low availability o Relationship with the Problem Management process

This is a pro-active activity as the unavailability hasn’t happened and/or an incident hasn’t been recorded yet.



7. Producing & maintaining an Availability Plan This plan has to be updated at least once every year! 8. Reporting

Availability % = (Actual availability / agreed availability) * 100%

Be very careful here! Availability percentages are measured against AGREED availability, not 24 hours per day.... This reporting has to happen as often as the customer requires, within reason of course, and this can be each fortnight, month, quarter – whatever steering mechanism the business needs from an availability point of view. The reporting to the business goes via Service Level Management.



3.4.2 Availability Metrics

Time

Recovery

Uptime, Time between failuresDowntime, Time to repair

Resolution time

Response

time

Repair

time

Recovery

time

Detection

time

Time Between System Incidents

Incident Incident

The following metrics are commonly used in Availability Management:

• Mean Time to Repair - MTTR: average time between the occurrence of a fault and service recovery (or the downtime).

• Mean Time Between Failures - MTBF: mean time between the recovery from one

incident and the occurrence of the next incident (or the uptime).

• Mean Time Between System Incidents - MTBSI: mean time between the occurrences of two consecutive incidents. The MTBSI = MTTR + MTBF.

The ratio of MTBF to MTBSI shows if there are many minor faults or just a few major faults. Availability reports may include the following metrics:

• Rate of availability (or unavailability) in terms of MTTR, MTBF and MTBSI • Overall uptime and downtime, Number of faults • Additional information about faults which actually or potentially result in a higher

than agreed unavailability.



3.4.3 Terminology

• Availability – This is an umbrella term that includes reliability (including resilience), maintainability, serviceability and security. A common definition of availability is ‘the ability of component or IT service (under combined aspects of its reliability, maintainability and security) to perform its required function as a stated instant or over a stated period of time’. Service availability is sometimes expressed as an availability percentage i.e. the proportion of time that the service is actually available for use by the customers within the agreed service time.

• Reliability – The ability of a component or IT service to perform a required function under stated conditions for a stated period of time. Reliability is now often taken to include resilience.

• Serviceability - Contractual arrangements with 3rd parties in regards to maintenance • Maintainability - The ability of the IT group to maintain the IT infrastructure in

operational state and available according to the agreed service levels • Security - Confidentiality, Integrity and Availability (CIA) of DATA • Vital Business Function - The business critical element of the business process that

is supported by the IT service. • Resilience - The ability of individual components to absorb or be flexible in times of

stress.



3.4.5 Quiz Questions Question 16 The main objective of Availability Management is?

a) To provide maximum availability for IT Services b) To ensure that service availability matches or exceeds the agreed needs of the business c) To ensure that all targets in Service Level Agreements (SLAs) for customers are continually

delivered d) To guarantee availability levels for services and components

Question 17 What is another term for Downtime?

a) Mean Time Between Failures (MTBF) b) Mean Time to Repair Service (MTRS) c) Mean Time Between System Incidents (MTBSI) d) Relationship between MTBF and MTBSI

Question 18 On a file server, what is the name of the average amount of time between the recovery points of one incident until the next incident occurs?

a) MTBSI. b) MTBF c) MTTR. d) Detection

Question 19 Which of the following is a good use of a baseline?

a) The desired end state of a project b) A marker or starting point for later comparison c) The current desktop models in use. d) The type of testing to be done for release

Question 20 In which ITIL process are negotiations held with the customer about the availability and capacity levels to be provided?

e) Availability Management f) Capacity Management g) Financial Management for IT Services h) Service Level Management



Assurance

Education &Awareness

Review& Audit Testing

ChangeManagement

Perform Initial Testing

Recovery Plans & Procedures

Stand-by Arrangements & Risk Reduction Measures

Organization & Impl. planning

Business Continuity Strategy

Risk Assessment

Business Impact Analysis

Define Scope of BCM

Initial Testing

Assurance

Education &Awareness

Review& Audit Testing

ChangeManagement

Perform Initial Testing

Recovery Plans & Procedures

Stand-by Arrangements & Risk Reduction Measures

Organization & Impl. planning

Business Continuity Strategy

Risk Assessment

Business Impact Analysis

Define Scope of BCM

Initial Testing

Stage 1 Initiation

Stage 2 Requirements &Strategy

Stage 3 Implementation

Stage 4 OperationalManagement

3.5 IT Service Continuity Management The biggest lesson enterprises should learn when building a resilient infrastructure is that they are mostly on their own. There are some tools, products and services to help. Outside network service provider offerings can be less than adequate and often the job of integration falls largely on the shoulders of the enterprise – as no one understands your business better than you.

The other lesson is that major damage to the infrastructure can result in the failure of the enterprise. This is easy to understand in the financial services sector, but with more and more sectors relying on communications, real-time applications and storage-area networks, loss of the infrastructure can bring any enterprise to its knees.

OBJECTIVE: is to support the overall Business Continuity Management process by ensuring that the required IT technical and services facilities (including computer systems, networks, applications, telecommunications, technical support and Service Desk) can be recovered within required, and agreed, business timescales.

3.5.1 ITSCM Stages



This diagram, on the previous page, shows the four stages of ITSCM, incorporating each of the activities that take place to ensure that IT organizations are as prepared and organized as possible in the event of a disaster situation. Stage one is really an activity that has to be done by the business, so IT can figure out what it is that BCM do? The IT organization has to provide details with how they will support this BCM by the continuation of delivery of IT services in times of crisis and disaster. Two of the major data sources for ITSCM are developed within Stage 2, including Business Impact Analysis and Risk Assessment. Performing a Business Impact Analysis (BIA) identifies:

• Critical business processes & Vital Business Functions • Potential damage or loss caused by disruption • Possible escalations caused by damage or loss • Necessary resources required to enable continuity of critical business processes • Time constraints for minimum recovery of facilities and services • Time constraints for complete recovery of facilities and services

Risk Assessment involves:

• Gathering information on assets (IT infrastructure components), • Considering the likelihood of Threats from both Internal & external sources

occurring • Vulnerabilities (the extent of impact or effect on organization)

This risk assessment activity is performed with availability management, as they need to know the impact on the availability of certain risks. Where availability management focuses on the day-to-day impact of risks on availability, IT Service Continuity looks at the effects of prolonged un-availability and the countermeasures that need to be in place to enable a sufficient level of recovery



3.5.2 Terminology Recovery Options

• Do Nothing – Sometimes the business can function without this service • Manual Work around – Administrative actions, takes lot of resource to enter data

back into systems • Reciprocal Arrangements – Agree to use the infrastructure of another organization,

especially for batch processing.

• Gradual Recovery (cold standby) – An empty room available (in house or outsourced service), mobile or fixed, where IT infrastructure can be rebuilt. (Takes longer than 72 hours to recover)

• Intermediate Recovery (warm standby) – A contract with 3rd party recovery

organization to use their infrastructure in a contingency situation. Backup tapes should be available at the crisis site at all times. (Takes 24 to 72 hours to recover)

• Immediate Recovery (hot standby) – Rent floor space at the recovery site with

infrastructure available and data mirrored from the operational systems. Or have a full duplication of system (-components) for instantaneous recovery (or near to). (Takes up to 4 hours to recover)

•

Other ITSCM Terms • Disaster: NOT part of daily operational activities and requires a separate system.

• BCM: Business Continuity Management; Strategies and actions to take place to

continue Business Processes in the case of a disaster.

• BIA: Business Impact Analysis- quantifies the impact loss of IT service would have on the business.

• Risk Assessment: Evaluate Assets, Threats and Vulnerabilities.

• Scope: The scope of IT Service Continuity Management considers all identified

critical business processes and IT service(s) that underpin them.

• Countermeasure: This term can be used to refer to any type of control and is most often used when referring to measures that increase resilience, fault tolerance or reliability of an IT Service



3.5.4 Quiz Questions Question 21 Which are the Service Delivery processes?

a) Availability, Incident, Change, Release, Configuration b) Availability, Capacity, Financial Management for IT Services, IT Service Continuity, Service

Level c) Financial Management for IT Services, Configuration, Availability, Service Level

Management d) IT Service Continuity Management, Service Desk, Change, Service Level Management, IT

Service Continuity Management Question 22 Which ITIL process is involved in performing risk assessments and a business impact analysis to determine appropriate "countermeasures" to be implemented?

a) Availability Management b) Problem Management c) IT Service Continuity Management d) Service Asset & Configuration Management

Question 23 You are in charge of putting an agreement in place between your organization and a supplier of support services from outside your company. What is the name of the document that you must create?

a) Operational Level Agreement (OLA b) Underpinning contract (UC). c) Service Catalogue (SC) d) Service Level Agreement (SLA)

Question 24 Which of the following is an activity of IT Service Continuity Management?

a) Advising end users of a system failure. b) Documenting the fallback arrangements c) Reporting regarding availability. d) Guaranteeing that the Configuration Items are constantly kept up-to-date.

Question 25 Which is NOT an ITSCM Recovery Option?

a) Intermediate Recovery b) Do Nothing c) Gradual Recovery d) Intermittent Recovery



3.6 Security Management (Separate ITIL v2 book) In recent time’s security, privacy and business continuity issues receive the funding and resources they need, even as other areas of the enterprise shrink.

Employees must know the difference between appropriate and inappropriate use of computing resources. This has always been important and is now getting policy-level emphasis. In addition, knowing what to do if there is a security problem has always been important, but until recently, it was assumed that employees and management would have time during a security incident, to read their e-mail, attend emergency meetings and figure out what to do. It is an unfortunate fact that in today’s computerized society that with regard to security measures if you “fail to plan you plan to fail”. Confidentiality of data is a major concern of Security Management, it is essential that there are clear and definitive processes and procedures that are acknowledged by all. For example, the use of USB drives is inherently difficult to physically control, so there must be formal procedures and policies in place, for all parties to follow.

OBJECTIVE: to ensure such a level of security, that the agreed availability of the infrastructure & the IT services, as well as the business functions, is not compromised.



3.6.1 Activities Control (Manage the process itself)

• Define (sub) processes, functions, roles, • Information Security Policy • Develop and Manage procedures, work instructions etc. • Organization structure, • Reporting structure, • Responsibilities and accountability

Plan

• Risk Assessment (connection with Availability Management & IT Service Continuity) • Add security to Service Catalogue, SLAs, OLAs and UCs • IT Policy statements

Implement

• Awareness • Security Incident Handling • Security Incident Registration • Implement security measures as defined in the plans

Evaluate

• Internal audits (e.g. internal EDP auditor) • External audits • Self assessment

Maintenance

• Updating security handbook (link to Change Management) • Maintenance of security measures (link to SLM)

Reporting

• Reporting to SLM on security issues in relation to Service Levels • Build up historical data to perform trend analysis • Report to line management on resource usage



Security needs to be considered in all IT operational and tactical processes. From customer security requirements discussed as part of SLA negotiations to assessment of security risks when reviewing IT Service Continuity. From unauthorized access of the Configuration Management database to detection of security related incidents. Security Management is more about policy setting and overall guidance on Security. Availability Management performs the Confidentiality, Integrity, Availability (CIA) activities in relation to achieving the sustained availability levels agreed with the customers, and will provide information to Security Management about the security baseline

This is how the basic concepts of Security Management fit together. External influences and business drivers feed into and are supported for by Security Management activities, which in turn will be reviewed and continually improved.



3.6.3 Quiz Questions Question 26 Which are the Service Delivery processes?

e) Availability, Incident, Change, Release, Configuration f) Availability, Capacity, Financial Management for IT Services, IT Service Continuity, Service

Level Management. g) Financial Management for IT Services, Configuration, Availability, Service Level

Management, Security Management h) IT Service Continuity Management, Service Desk, Change, Service Level Management, IT

Service Continuity Management Question 27 Security Management works closely with which of the following process areas

a) Availability Management. b) IT Service Continuity Management. c) Incident Management. d) Problem Management

Question 28 What does CIA stand for when discussing security management?

a) Capacity, Incident, Availability. b) Configuration, Involvement, Action. c) Catch, Interrogate, Arrest. d) Confidentiality, Integrity, Availability.

Question 29 The Security Policy should be available to which groups of people?

a) Senior Account managers and all IT staff b) Senior managers, IT executives and the Service Desk c) All customers, users and IT staff d) Security Management staff only

Question 30 A Service owner is responsible for which of the following?

a) Recommending improvements to services under their care b) Defining and documenting Service Requirements c) Carrying out the activities needed to support a Service. d) Reporting service levels back to the customer.



4 Service Support Function & Processes_

This section contains the following processes:

• Configuration Management • Incident Management • Problem Management • Change Management • Release Management

This section contains the following functions:

• Service Desk



4.1 Configuration Management

Configuration Management as a process has been confusing for a lot of people over the years. On the one hand side it is all about managing a database, while on the other side it talks about the management of a process.

Ultimately, the main reason for configuration management is the information we need to have available (in a non-duplicated manner) about the IT components and how they relate to each other. The reason for this is that we need to be able to assess risks to the infrastructure in relation to the Service Levels. IT specialists need to be able to make informed decisions... not guesstimates.

This process collects and manages the information that is needed to achieve this goal. The tools you use need to be flexible. One can have from three or four seats to hundreds of seats. The process is applicable to large teams as well as small. However, companies shouldn't merely consider their size when hunting for Configuration Management tools. They must consider the complexity of the IT Infrastructure problem. The question is not a test of how big the shop is but how complex the management problem is. After all, companies can find themselves needing to grow or expand a unit rapidly. You need a tool that will meet your needs today but that will let you grow as well.

OBJECTIVE: To account for all the IT assets and configurations within the organization and its services and provide accurate information on configurations and their documentation to support all the other Service Management processes. In addition, part of the objective for Configuration Management process is to provide a sound basis for Incident Management, Problem Management, Change Management and Release Management and verify the configuration records against the infrastructure and correct any exceptions.



4.1.1 Activities

Configuration Management Planning: A Configuration Management plan should define:

• The purpose, scope and objectives of Configuration Management • Related policies, standards and processes that are specific to the support group • Configuration Management roles and responsibilities • CI (Configuration Item) naming conventions • The schedule and procedures for performing Configuration Management activities:

configuration identification, control, status accounting, configuration audit and verification

• Interface control with third parties, e.g. Change Management, suppliers • Configuration Management systems design, including scope and key interfaces

Configuration identification: CIs are the components used to deliver a service. The CIs include software, documentation and SLAs. Also identify the relationship between CIs and the attributes for every CI.

Control of CI’s: The objective of configuration control is to ensure that only authorized and identifiable CIs are recorded in the CMDB upon receipt. Configuration status accounting: Status reports should be produced on a regular basis, listing, for all CIs under control, their current version and Change history. Status accounting reports on the current, previous and planned states of the CIs should include:

• Unique identifiers of constituent CIs and their current status, e.g. 'under development', 'under test', 'live'

• Configuration baselines, Releases and their status • Latest software item versions and their status for a system baseline/application • The person responsible for status change, e.g. from 'under test' to 'live' • Change history/audit trail

Configuration verification and audit: Service Desk staff, while registering incidents, can do daily verification. Configuration audits should be considered at the following times:

• Shortly after implementation of a new Configuration Management system • Before and after major Changes to the IT infrastructure • Before a software Release or installation to ensure that the environment is as

expected • Following recovery from disasters and after a 'return to normal' (this audit should

be included in contingency plans) • At random intervals • In response to the detection of any unauthorized CIs

• At regular intervals



4.1.2 Terminology

• Attribute: Specific information about CI’s.

• Business Impact Analysis (BIA) - quantifies the impact loss of IT service would have on the business.

• Business Continuity Management (BCM) - Strategies and actions to take place to

continue Business Processes in the case of a disaster.

• CI Level: Recording and reporting of CI’s at the level that the business requires.

• Configuration Baseline: Configuration established at a specific point in time, captures both the structure and details of a configuration. Used as a reference point for later comparison.

• Configuration Item (CI): ANY component that supports an IT service

• Configuration Management Database (CMDB) Backup, Administration,

Housekeeping

• Countermeasure: This term can be used to refer to any type of control and is most often used when referring to measures that increase resilience, fault tolerance or reliability of an IT Service.

• Disaster: NOT part of daily operational activities and requires a separate system.

• Risk Assessment: Evaluate Assets, Threats and Vulnerabilities.

• Scope: The scope of IT Service Continuity Management considers all identified

critical business processes and IT service(s) that underpin them.

• Status Accounting: Reporting of all current and historical data about each CI throughout its lifecycle.



4.1.4 Quiz Questions Question 31 From the following list, which are goals for Configuration Management? 1. Account for all the IT assets and configurations within the organization and its services 2. Provide accurate information on configurations and their documentation to support all the other Service Management processes 3. Provide a sound basis for Incident Management, Problem Management, Change Management and Release Management 4. Verify the configuration records against the infrastructure and correct any exceptions

a) All. b) 1 only c) 1 & 3 only. d) 2 only

Question 32 Which activity in Configuration Management would help to ascertain which Configuration Items are undergoing maintenance at a particular moment in time?

a) Control b) Verification and audit c) Identification. d) Status accounting

Question 33 What are the four perspectives (attributes) considered for IT Service Management?

a) Process, Product, Pricing, People b) Hardware, Software, Management, Process c) Process, Partner, Product, People d) Technology, Process, Management, People

Question 34 What is another term for ‘uptime’?

a) MTRS b) MTBF c) CMDB d) BCM



4.2 Service Desk (Function)

The Service Desk is a single point of contact (SPOC) for end-users who need help. Without this single point of contact an organization would face major losses in time spent on looking for ways to fix issues and get help. Service Desks and desktop support teams need to ensure that their services are clearly defined and aligned with business needs.

OBJECTIVE: To provide a single point of contact for Customers and facilitate the restoration of normal operational service with minimal business impact on the Customer within agreed service levels and business priorities.

The main types of Service Desks are:

• Call Centre: only call dispatching, no other activities done • Helpdesk: managing, coordinating and resolving incidents • Service Desk: extends the range of services, handling incidents, problems and

questions while providing an interface to other ITIL processes such as Service Level Management, Change Management, Availability Management, Capacity Management and Financial Management for IT

There are 3 different Service Desk structures:

• Local Service Desk: service desk per geographic location supporting local users • Central Service Desk: a central physical Service Desk supporting multiple user

groups across multiple geographic locations • Virtual Service Desk: a non-physical, single point of contact for multiple user

groups, often offering global support.



4.2.1 Activities

The Service Desk performs the first line support for the IT Services. Apart from the Call Centre, all Service Desk types perform the following activities:

• Receiving calls, first-line Customer liaison • Recording and tracking incidents and complaints • Informing Customers of request status and progress • Initial assessment of requests, attempting to resolves them or referring to someone

who can, based on agreed service levels • Monitoring and escalation procedures relative to appropriate SLA • Management of the full request lifecycle, including closure and verification with

customer • Communicating planned changes of service levels to Customers • Coordinating 2nd line and 3rd party support groups • Providing management information • Contributing to Problem identification • Highlighting Customer training and education needs

4.2.2 Terminology

• Incident - Any event which is not part of the standard operation of a service and which causes, or may cause an interruption to, or a reduction in the quality of that service. A failure of a CI that has not yet affected service is also classified as an incident.

• Service Request - Request for information or status of a service (not related to loss

of service) Includes Standard Changes. E.g. Contact details, Service availability, request for common software. In ITIL version 2, Service Requests are classed as a form of incident; however this has been improved in ITIL v3, with the definition of the Request Fulfilment process.

• Request for Change - Request to Move, Add, Change E.g. Asking for changes to

functionality of applications or supporting infrastructure – not a pre-approved change.



4.2.3 Quiz Questions Question 35 Of the following what are activities of the Service Desk? 1. To act as a single point of contact for Customers and end users 2. To facilitate the restoration of normal operational service with minimal business impact on the Customer within agreed service levels and business priorities.

a) First statement only. b) Second statement only. c) Both statements d) Neither statement

Question 36 Which of the following BEST describes a Local Service Desk structure?

a) A Service Desk that also provides onsite technical support to its users b) A Service Desk where analysts only speak one language c) A Service Desk that is situated in the same location as the users it serves d) A Service Desk that could be in any physical location but uses telecommunications and

systems to make it appear that they are in the same location Question 37 Which of the following BEST describes the Service Desk type; ‘Help Desk’?

a) managing, coordinating and resolving incidents b) extends the range of services, handling incidents, problems and questions while providing

an interface to other ITIL processes such as Service Level Management, Change Management, Availability Management, Capacity Management and Financial Management for IT

c) only call dispatching, no other activities done d) a non-physical, single point of contact for multiple user groups, often offering global support



4.3 What is the difference between an Incident and a Problem?

A simple explanation of the difference between an Incident and a Problem is to think of a weed in a garden.

Describing the weed as an Incident: The weed is a nuisance and the gardener needs a ‘quick fix’ to remove it. The gardener may cut, rip, out or mow over the top of this weed to hide it from soil level. For the moment, the weed has gone, however it will grow back in time. Describing the weed as a Problem: The weed must be removed so that it will never grow back. Based on the analysis done about the type of weed and the way we can remove it indefinitely, the gardener may poison, dig out, re-lawn, burn or concrete over the weed to ensure that it will not be a recurring issue.



Investigation & Diagnosis

Classification & Initial Support, Prioritization

Incident Detection/ Recording

Resolution & Recovery

Ow

ners

hip,

Mon

itorin

g, T

rack

ing

and

Com

mun

icat

ion

Incident Closure

Minimum Service Desk Responsibility

Investigation & Diagnosis

Classification & Initial Support, Prioritization

Incident Detection/ Recording

Resolution & Recovery

Ow

ners

hip,

Mon

itorin

g, T

rack

ing

and

Com

mun

icat

ion

Incident Closure

Minimum Service Desk Responsibility

4.4 Incident Management Some enterprises recognize that efficiency can be gained from process improvement (e.g. outsourcing and staff reductions). But, they also know that mechanisms need to be in place to determine baselines, and ongoing measurements of performance.

A fundamental move from a reactive help desk support model, to a consolidated IT service desk, within Incident Management forces the need to demonstrate the value of service quality. This quality is inextricably linked to IT customer satisfaction.

OBJECTIVE: To restore normal service operation as quickly as possible and minimize the adverse impact on business operations, thus ensuring that the best possible levels of service quality and availability are maintained.

From this objective there are two main points to remember:

1. Incident Management is all about QUICK restoration of business operations. It doesn’t say that it has to be pretty or complete. When the end-user can continue their business processes (even with limited IT availability), this would be considered good enough for incident management.

2. Incidents deal with SYMPTOMS. When you delete the symptom the business operation is considered to be restored. It doesn’t mean the underlying cause has been removed, nor does it mean that the incident will never re-occur.

The type of Service Desk you choose will depend on what number of incident management activities will be performed at the Service Desk. The activities that are NOT performed at the Service Desk will be conducted by the technical functions that staff Technical Specialists.



4.4.1 Activities Incident detection and recording (Service Desk responsibility)

• Record basic details of the Incident • Alert specialist support group(s) as necessary

Classification and initial support

• Classifying Incidents • Assigning impact and urgency, and thereby defining priority • Matching against Known Errors and Problems • Informing Problem Management of the existence of new Problems and of

unmatched or multiple Incidents • Assessing related configuration details (daily verification) • Providing initial support (assess Incident details, find quick resolution) • Closing the Incident or routing to a specialist support group, and informing the

User(s). Investigation and diagnosis

• Assessment of the Incident details • Collection and analysis of all related information, and resolution (Including any

Work-around) or a route to n-line support. Resolution and recovery

• Resolve the Incident using the solution/Work-around or, alternatively, to raise an RFC (including a check for resolution)

• Take recovery actions. Incident closure (Service Desk responsibility) When the Incident has been resolved, the Service Desk should ensure that:

• Details of the action taken to resolve the Incident are concise and readable • Classification is complete and accurate according to root cause • Resolution/action is agreed with the Customer - verbally or, preferably, by email or

in writing • All details applicable to this phase of the Incident control are recorded, such that: • The Customer is satisfied • Cost-centre project codes are allocated • The time spent on the Incident is recorded • The person, date and time of closure are recorded.

Ownership, monitoring, tracking and communication (Service Desk responsibility) • Monitor Incidents • Escalate Incidents • Inform User.



4.4.3 Quiz Questions Question 38 What is the best definition of an Incident Model?

a) A type of incident involving an authorized Configuration Item (CI) b) The template used by Service Desk analysts to record incidents c) A set of pre-defined steps to be followed when dealing with a known type of incident d) An Incident that is easy is solved at first contact

Question 39 Incident Management has a value to the business by?

a) Helping to minimize infrastructure cost of adding new technology. b) Enabling users to resolve Problems c) Finding permanent solutions to ineffective business processes d) Contributing to the reduction of outages.

Question 40 Which of the following BEST describes a Workaround?

a) A Service Desk Operator uses a pre-defined technique to restore service as this Incident has been seen before

b) A second level support person uses trial and error to solve an Incident. One of them works, but does not know why

c) After reporting the problem to the Service Desk, the user works on another task while the problem is identified and resolved.

d) A service works now and then, thus allowing the user to continue working with interrupted levels of performance while the support person resolves the problem.

Question 41 Which of the following statements are CORRECT about Functions? 1. They provide structure and stability to organizations 2. They are self-contained units with their own capabilities and resources 3. They rely on processes for cross-functional coordination 4. They are costlier to implement compared to processes

e) 1, 2 and 3 only f) 1, 2 and 4 only. g) All of the above. h) None of the above



4.5 Problem Management

End users will face issues in their use of computer systems. In ITIL terms we refer to these as incidents. A problem can be linked to a singular incident, or a group of related incidents. The differentiator is the focus: incident – symptom and problem - root cause.

Failure to halt the recurrence of incidents leads to lost time and frustrated users. Users who have to ask for the same issue to be fixed day after day will quite rightly lose their patience. Effective problem management halts the recurrence of incidents and has benefits to the individual and the organization as a whole.

OBJECTIVE: The goal of Problem Management is to minimize the adverse impact of Incidents and Problems on the business that are caused by errors within the IT Infrastructure, and to prevent recurrence of Incidents related to these errors.

Main focus of Problem Management is improving the Quality of the IT infrastructure. Through issuing Requests For Change (RFC), Problem management tries to make as many changes to the IT Infrastructure as possible and as such removing a lot of the errors.

4.5.1 Activities The major activities of Problem Management are:

• Problem control • Error control • The proactive prevention of Problems • Identifying trends • Obtaining management information from Problem Management data • The completion of major Problem reviews.

Problem control:

Identifying the real underlying causes.

• Problem identification and recording (link to Incident Management) • Problem classification - in terms of the impact on the business • Problem investigation and diagnosis (link to all other ITIL processes) • CLOSE problem before going into error control

Error control:

• Identify and register Known Errors • Assess Known Errors and identify possible solutions (if necessary!) • Raise RFC to remove Known Errors affecting the IT infrastructure to prevent any

recurrence of Incidents (link to Change Management)



Proactive Problem Management:

• Identifying and resolving Problems and Known Errors before Incidents occur. • Trend analysis • Targeting of preventive action (Working with Availability Management).

Trend Analysis Providing management information Major Problem reviews: On completion of the resolution of every major Problem, Problem Management should complete a major Problem review.

• What was done right? • What was done wrong? • What could be done better next time? • How to prevent the Problem from happening again.

4.5.2 Terminology

Problem - Unknown underlying cause of one or more Incidents (The investigation) Known Error - Known underlying cause. Successful diagnosis of the root cause of a Problem, and a workaround or permanent solution has been identified KEDB - Known Error Database Workaround - A set of predefined steps to take as a means of reducing or eliminating the impact of an Incident or a Problem (e.g. restarting failed Configuration Item). Workarounds for Problems are documented with the Known Error records in the KEDB. These work-arounds are used by Incident Management to speed up the process of dealing with incidents.



4.5.4 Quiz Questions Question 42 What is the difference between a Known Error and a Problem?

a) The underlying cause of a Known Error is known. The underlying cause of a Problem is not known

b) A Known Error involves an error in the IT infrastructure; A Problem does not involve such an error.

c) A Known Error always originates from an Incident. This is not always the case with a Problem

d) With a Problem, the relevant Configuration Items have been identified. This is not the case with a Known Error.

Question 43 Which ITIL process ensures that the IT Services are restored as soon as possible in the case of a malfunction?

a) Change Management b) Incident Management c) Problem Management. d) Service Level Management

Question 44 Which of the following is NOT an activity of Problem Management?

a) Incident Control b) Problem Control c) Error Control d) Proactive problem Management

Question 45 Which of the following would be a focus of a major Problem review?

1) What was done right? 2) What was done wrong? 3) What could be done better next time? 4) How to prevent the Problem from happening again.

a) 1 and 4 only b) 3 and 4 only c) All of the above d) 1,2 and 4 only



Logging & filtering

Classification

Assessment

Authorization

Coordination

Evaluation (PIR)

RFC

build / test / implement

4.6 Change Management

Change is inevitable, and the rate of change in technology is increasing. Businesses, business processes and business models constantly have to adapt to the economic climate, competitive pressures, and the opportunity to create through change and innovation. Change management, as a discipline in distributed computing is somewhat lacking. Yet, change management for IT operations is critical to improving availability, performance and throughput. Strong change management is the backbone for IT operations. Strong IT change management enables an enterprise to change the business process and business model that are so intertwined and dependent on the technology. Any business process change is likely to require significant technology changes. Thus, the IT operations group must step in and address these changes with the business units and applications development organization. Strong operational change management reduces errors, as well as planned and unplanned downtime.

OBJECTIVE: The goal of the Change Management process is to ensure that standardized methods and procedures are used for efficient and prompt handling of all Changes, in order to minimize the impact of Change-related Incidents upon service quality, and consequently to improve the day-to-day operations of the organization.



4.6.1 Activities Activities undertaken will involve:

• Change logging and filtering / acceptance o Does the RFC (request for change) have enough, quality, information o Unique identification number o Filter out impractical RFCs and provide feedback to issuer

• Managing Changes and the Change process o Prioritize RFCs (based on risk assessment) o Categorize RFCs (e.g. minor, significant or major impact)

• The Change Manager will chair the CAB (Change Advisory Board) and the CAB/Emergency Committee

o Assess all RFCs (but not all during the meeting!! CAB is a consulting body) o Impact and resource assessment o Approval based on financial, business and technical criteria o Forward Schedule of Changes (FSC) for the approved changes.

• Coordinate the Change o Supported by release Management, change management coordinates the

building, testing and implementation of the change. The actual activities of build and test are performed outside of the ITIL framework. Often these activities will be part of a project

• Reviewing and closing RFCs

o As part of the implementation, the very last step will be the PIR (Post Implementation Review), which is a responsibility of Change Management. Problem Management is involved as well to identify that the known error has been deleted.

• Management reporting.

Note: Urgent changes follow the same steps, but usually in a different order. The CAB/EC approves an urgent change immediately and the building, testing and implementation are done before the paperwork. But DON’T FORGET THE DOCUMENTATION!



4.6.2 Terminology

• Requests for Change - Every change to the IT Infrastructure has to go through Change Management. A Request for Change (RFC) is formally issued for every change request.

• Change Manager - Responsible for the Change Management process and authorizes all changes

• Change Advisory Board (CAB) - A dynamic group of people (depending on the change) that approve Changes with medium to high priority, risk and impact.

• CAB/EC CAB Emergency committee - approves and authorizes changes with high urgency, risk and impact.

• Change models - Some organizations use change models prior to implementation to estimate the impact of the change. Change Management and Capacity management work together on this.

• FSC - The Forward Schedule of change (FSC) contains details of all approved changes and their proposed implementation date.

• PSA - The Projected Service Availability (PSA) contains details of changes to agreed SLAs and service availability because of the current FSC.



4.6.4 Quiz Questions Question 46 What is the role of the Change Advisory Board/ Emergency Committee (CAB/EC)?

a) To make sure the Change Manager responds urgently to emergency changes b) To assist the Change Manager to implement urgent changes c) To assist the Change Manager in evaluating emergency changes and to decide whether

the change should be approved d) To assist the Change Manager in rushing the emergency change process so that changes

can occur quickly Question 47 The objective of the Change Management process is most accurately described as?

a) Ensuring that all changes are recorded, managed, tested and implemented in a controlled manner

b) Ensuring that emergency changes to IT infrastructure are managed efficiently and effectively

c) Ensuring that changes have appropriate rollback plans in the event of a major incident d) Maximizing services by allowing changes to be made quickly

Question 48 What is the difference between a Known Error and a Problem?

a) A Known Error involves an error in the IT infrastructure; A Problem does not involve such an error.

b) The underlying cause of a Known Error is known. The underlying cause of a Problem is not known

c) A Known Error always originates from an Incident. This is not always the case with a Problem.

d) With a Problem, the relevant Configuration Items have been identified. This is not the case with a Known Error.

Question 49 Which document contains details of all approved changes and their proposed implementation dates?

a) FSC b) PSA c) RFC d) DHS



4.7 Release Management

IT operations groups continue to struggle with the incorporation of application, infrastructure, and operational changes into their IT production environments. According to Meta Group: through 2009, IT operations groups will increasingly seek to maintain/improve change-management service levels by formalizing and adopting processes that enable improved acceptance of change into the production environment (e.g., production acceptance [PA], production control, quality assurance [QA], release management).

OBJECTIVE: To ensure that all technical and non-technical aspects of a release are dealt with in a coordinated approach.

Note: Release Management extends beyond the technical components! It includes user manuals, installation scripts, updates to the Service Catalogue, SLA’s, OLA’s, CMDB, disaster recovery plans… everything!



4.7.1 Activities

Release Management activities include: • Release policy and planning • Release design, build and configuration • Release acceptance • Rollout planning • Extensive testing to predefined acceptance criteria • Sign-off of the Release for implementation • Communication, preparation and training • Audits of hardware & software prior to & following the implementation of Changes • Installation of new or upgraded hardware • Storage of controlled software in both centralized and distributed systems • Release, distribution and the installation of software.

Release Management should be used for:

• Large or critical hardware rollouts, especially when there is a dependency on a related software Change in the business systems, i.e. not every single PC needs to be installed.

• Major software rollouts, especially initial instances of new applications along with accompanying software distribution and support procedures for subsequent use if required.

• Bundling or batching related sets of Changes into manageable-sized units. In addition, Release Management plays an important part in Change Management. Release Management is responsible for the testing & implementation schedule, which in turn, will impact the change schedule. For that reason, Release Management needs to be involved with suppliers to align the external release schedules with the internal ones.



4.7.2 Terminology • Release - A collection of authorized Changes to an IT Service.

• Release Unit - A Release Unit describes the portion of a service of IT infrastructure

that is normally released together according to the organizations release policy. The unit may vary depending on type(s) or item(s) of service asset or service component such as hardware or software.

• Definitive Software Library (DSL) - The secure library in which the definitive

authorized versions of all Software CIs are stored and protected. The DSL should include definitive copies of purchased software (along with license documents or information) as well as software developed on site.

• Definitive Hardware Spares (DHS) - Physical storage of all spare IT components

and assemblies maintained at the same level as within the live environment. These can then be used when needed for additional systems or in the recovery from Incidents.

• Details recorded in the CMDB, controlled by Release Management.

• Full Release - All components of a release unit built tested and implemented together

• Delta Release - Only those CIs in release unit that have changed since last full or

delta release

• Package Release - Multiple release units released at same time

• Major release - contains large areas of new functionality e.g. NEW VERSION 1.0 2.0

• Minor release - contains small enhancements and fixes e.g. VERSION 1.0 1.1 • Emergency fix - contains corrections to a small number of Known Errors e.g.

VERSION 1.0 1.0a



4.7.4 Quiz Questions Question 50 The procurement department of an electronics manufacturing company has recently signed a contract with a new supplier of personal computers. The first new machines arrive and all applications used in the company must be tested on the new machines. The manufacturing company has a well structured production and test environment. Which process manages the rollout of the new machines to the users?

a) Release Management. b) Service Level Management. c) Change Management d) Configuration Management.

Question 51 Data is stored about items held in the DSL and the DHS. Where is this information stored?

a) CDB b) FSC. c) CMDB. d) SLR

Question 52 List the Service Support processes and the one Functional area.

a) Service Desk, Release, Incident, Availability, Configuration, Change b) Service Desk, Release, Incident, Problem, Continuity, Change c) Service Desk, Release, Incident, Problem, Configuration, Change d) Help Desk, Release, Incident, Problem, Configuration, Change



Question 53 The following options are considered within which process? 1. Package Release 2. Delta Release 3. Full Release

a) Incident Management b) Release Management c) Configuration Management d) Service Level Management

Question 54 Which of the following are objectives of the Release Management process? 1. To develop a release policy 2. To ensure that training occurs for new service to operations and support staff 3. To ensure that new services are tested prior to release 4. To provide cost justifiable IT availability that is matched to the needs of the business Question 55 List the Service Support processes and the one Functional area.

e) Service Desk, Release, Incident, Availability, Configuration, Change f) Service Desk, Release, Incident, Problem, Continuity, Change g) Service Desk, Release, Incident, Problem, Configuration, Change h) Help Desk, Release, Incident, Problem, Configuration, Change



4.7.5 Quiz Answers

1. B 2. A 3. B 4. C 5. C 6. D 7. C 8. D 9. C 10. A 11. B 12. A 13. D 14. C 15. C 16. B 17. B 18. B 19. D 20. B 21. B 22. C 23. B 24. B 25. D 26. B 27. A 28. D 29. C 30. A 31. A 32. D 33. C 34. B 35. C 36. C 37. A 38. C 39. D 40. A 41. A 42. A 43. B 44. A 45. C 46. C 47. A 48. B 49. A 50. A 51. C 52. C 53. B 54. A 55. C



5 Certification_____________________

5.1 ITIL v2 Certification Pathways In conjunction, with the launch of ITIL v3 in July 2007, a new certification path was released. This new path encompasses the v2 and all the new v3 Programs, ending in the possible attainment of “Expert Status”. The figure below demonstrates the possible pathways that you could take to achieve the Expert status.

To achieve Expert status, you are required to gain a minimum of 22 points by completing various ITIL® programs: If you intend to gain Expert status via a v2 pathway:

o You must complete the v2 Foundation Program o You must complete either the v2 Manager Program (17 points) and then the ITIL v3

Manager Bridge Program (5 Points), or o You must complete a minimum of 3 Practitioner Programs and the Managing

Across the Lifecycle Program (The numbers on each program indicate the points value.)

It is yet to be finalized how the “Advanced Level” can be achieved, but is expected to be based on demonstration of practical experience in ITIL and IT Service Management.

For more information on certification and available programs please visit our website http://www.artofservice.com.au



6 ITIL Foundation Exam Tips______ Exam Details

• 40 questions • The correct answer is only one of the four • 60 minutes duration • 26 out of 40 is a pass (65%) • Closed book • No notes

Practical Suggestions

• Read the question CAREFULLY • At this level of exam the obvious answer is often the correct answer (if you have

read the question carefully!!) • Beware of being misled by the preliminary text for the question • If you think there should be another choice that would be the right answer, then you

have to choose the “most right” • Use strategies such as “What comes first?” or “What doesn’t belong?” to help with

the more difficult questions. Organising your Exam EXIN facilitates the ITIL v2 Foundation exam. Please contact The Art of Service directly or visit http://www.exin-exams.com to arrange your examination. You can also take your exam at a Prometric Test Centre in your local area by visiting http://www.prometric.com/default.htm, you will be able to access a full list of testing centres and book your exam online. Make sure that you prepare adequately in the lead up to your exam by reviewing your notes, reading any available material and attempting the sample exams. We wish you luck in your exam and future ITSM career!



7 References______________________ ITSMF International (2006). Metrics for IT Service Management, Zaltbommel, Van Haren Publishing The Art of Service (2007) ITIL® Factsheets, Brisbane, The Art of Service The Art of Service (2008) CMDB and Configuration Management Creation and Maintenance Guide, Brisbane, The Art of Service The Art of Service (2008). ITIL v2 Foundation Classroom Program Materials. Brisbane, The Art of Service. The Art of Service (2008) IT Governance, Metrics and Measurements and Benchmarking Workbook, Brisbane, The Art of Service \The Art of Service (2008). ITIL® V3 Foundation Complete Certification Kit. United Kingdom, Emereo Pty Ltd. The Art of Service (2008) Risk Management Guide, Brisbane, The Art of Service www.artofservice.com.au www.theartofservice.com www.theartofservice.org



INDEX* A ability 15, 33, 40 account 7, 27-8, 54, 58 activities, optional 28 agreements 5, 16-17, 24, 47 alignment 3, 10, 14 analysis, business impact 37, 43-5, 47 answer, correct 84 application availability perspective 36 Application Sizing 33, 35 applications 8, 31, 33, 36, 43, 60, 76-7, 80 Applications Management 8 attributes 3, 7, 55, 58 audit 43, 49, 55, 58 availability 5, 15, 33, 35-6, 38-40, 42, 44, 47-8, 50, 52, 63, 80-1 improving 71 availability expectations 37 Availability Management 3, 9, 20, 30, 35-6, 39, 42, 44, 47, 49-50, 52, 59, 61, 68 Availability Management Contingency Planning 9 availability manager 37 Availability Metrics 3, 39 availability mgt 37 Availability MGT 14 availability percentages 38 availability targets, sustainable 37 B bake 10 baselines, � Configuration 55-6 BCM (Business Continuity Management) 43-5, 56, 58 BIA, see Business Impact Analysis Brisbane 85 budgeting 27-8, 30 business 3, 5, 8-10, 14-15, 18, 21, 27-8, 31, 33, 36-8, 40, 42-5, 56, 59, 66-7, 72 [1] Business Capacity Management 32-3, 35 Business Continuity Management, see BCM Business Continuity Management process 43 Business Continuity Strategy 43 business drivers 50 business functions 9, 37, 48 Business Impact Analysis (BIA) 37, 43-5, 47, 56 Business Impact Analysis and Risk Assessment 44 business models 71 business objectives 14, 36 business operations 63 business perception 21 business perspective 8, 30, 35 Business Plan 31-2 business practices 9 business priorities 59, 61 business process change 71 business process level 14 business processes 14, 17, 37, 40, 44-5, 56, 63, 71 ineffective 66 business processes � Time constraints 44 business requirements 17, 31-2 Business Strategy 31 business systems 77 business timescales 43 business unit � Notional Charging 28



business units 71 business users 8-9 Businesses 71 C CAB (Change Advisory Board) 72-3, 75 CAB/EC 72, 75 cake 10-11 cake� example 11 capabilities 5, 10, 15-16, 26, 30, 36, 66 capacity 31, 33, 47, 52 Capacity Management 3, 9, 14, 20, 31, 35, 42 Capacity Management and Financial Management 59, 61 Capacity Management process 31-2, 35 certification 4, 83 certification programs 9 Change Advisory Board (CAB) 72-3, 75 Change Management 4, 9, 30, 33, 49, 55, 59, 61, 67, 70-3, 77, 80 Change Management and Capacity management work 73 Change Management and Release Management 54, 58 change management process 71, 73, 75 Change Manager 72, 75 charge 28, 47 charge customers 28 CI (Configuration Items) 15, 17-18, 47, 55-6, 58, 60, 66, 70, 75 CIA (Confidentiality, Integrity and Availability) 40, 50, 52 CIs 55, 78 CMDB (Configuration Management Database) 16, 50, 55-6, 58, 76, 78, 80 communication 5-6, 43, 63-4 communications infrastructure 8 companies 47, 54, 80 complaints � Informing Customers 60 completion 67-8 components 15, 32, 40, 42, 45, 54-6, 78 concepts 7, 9, 11, 15 Confidentiality 40, 50, 52 Integrity and Availability (CIA) 40, 50, 52 Configuration 47, 52, 56, 80-1 Configuration audits 55 configuration items 15-17, 47, 55, 58, 70, 75 Configuration Items, see CI Configuration Management 4, 9, 15-16, 31, 50, 54-5, 58, 80-1 Configuration Management Database, see CMDB configuration management system 30, 35 configuration management system � 55 configurations 54, 56, 58 contact 5, 26, 59, 61, 66, 84 continuity 44, 80-1 control 5-6, 15-16, 27, 33, 45, 48, 55-6, 58 costs 5, 11, 24, 26-8, 30, 36, 81 countermeasures 44, 47 cross-functional coordination 30, 66 customer complaints 30, 35 customer language 5 Customer liaison � Recording, first-line 60 customer organization 5 customer security requirements 50 customer � Monitoring Service Levels 21 customer � Profit Centre 28 customers 5, 7, 9-11, 15-18, 20-3, 26, 28, 30, 32, 35, 38, 42, 52, 59, 61, 64 [2] right 31 customers groups 21



customers � 60 D damage 43-4 data, collected 32 DATA � Vital Business Function 40 database 16, 54 decision/action 13 Defining availability 37 Definitive Hardware Spares (DHS) 75, 78, 80 Definitive Software Library (DSL) 78, 80 delivery 5, 11, 13, 24, 32, 44 delta release 78, 81 Demand Management 33, 35 Demand Mgt 33 department 23-4, 28 design, suppliers � Configuration Management systems 55 Desk 59, 61 local users � Central Service 59 physical Service 59 DHS (Definitive Hardware Spares) 75, 78, 80 diagnosis 64, 67-8 difference 4, 13, 48, 62, 70, 75 disaster 36, 44-5, 55-6 downtime 39, 42 mission-critical application service 36 DSL (Definitive Software Library) 78, 80 E Effective problem management 67 emergency changes 75 employees 37, 48 enterprise 43, 63, 71 enterprise resource planning (ERP) 31 environment 12, 31, 55 ERP (enterprise resource planning) 31 error control 67, 70 errors 66-7, 70-1, 75 escalation � Service performance xf0b7 Batch 22 exam 9, 84 Expert status 83 F facilities 16, 44 failures 31, 39, 43, 60, 67 faults 39 filtering 71-2 Financial Management 3, 9, 20, 27-8, 30, 35, 42, 47, 52 Financial Management system 30 financial services sector 43 focus 9, 32, 67, 70 Forward Schedule of Changes, see FSC framework 6, 11-13, 15 FSC (Forward Schedule of Changes) 72-3, 75, 80 Functional area 80-1 functionality 60, 78 functions 3-4, 9, 12, 14-16, 18, 26, 30, 37, 45, 49, 53, 59, 66 required 15, 40 G gardener 62 goals, corporate 14



group, multiple user 59, 61 guarantee availability levels 42 H hardware 7, 15-16, 58, 77-8 Help Desk 80-1 helping business managers 8 hours 38, 45 I ICT Infrastructure 8 ICT Infrastructure Management 8 identification, configuration 55 image 14 impact � Change Management 24 Implement Service Management 8 implementation 43, 55, 72-3, 75, 77 incident 4, 16, 18, 37, 39, 42, 47, 50, 52, 60, 62-4, 66-8, 70-1, 75, 78, 80-1 consecutive 39 handling 59, 61 potential 16 record 66 recurrence of 67 registering 55 resolving 61 security 48 singular 67 tracking 60 � Classifying 64 � Monitor Incidents xf0b7 Escalate 64 incident closure 63-4 incident control 64, 70 incident details 64 incident details � collection 64 incident detection 63-4 Incident Management 4, 9, 52, 54, 58, 63, 66-8, 70, 81 � Configuration Management xf0b7 53 incident management activities 63 incident management forces 63 Incident MGT 14 Incident Model 66 incident � 64 industry 8 Information technology Infrastructure Library, see ITIL infrastructure 6, 15-17, 31-3, 36, 40, 43, 45, 48, 54, 58, 60, 67, 70, 73, 75-6, 78 infrastructure components 44 infrastructure cost 66 Infrastructure Library 16 Infrastructure Management processes 9 infrastructure problem 54 infrastructure � 55 ingredients 10 Initial Testing 43 interface 59, 61 INTERFACES 3-4 investigation, business � Problem 67 IT Service Management, see ITSM Iterative Activities 33 ITIL (Information technology Infrastructure Library) 3-85 ITIL process Incident Management 12 ITIL processes 30, 35, 42, 47, 59, 61, 67, 70 ITSCM 44



ITSM (IT Service Management) 3, 5-7, 9, 14, 16, 58, 83, 85 K KEDB 68 Known Errors 67-8, 70, 72, 75, 78 Known Errors and Problems � Informing Problem Management 64 L library, information technology infrastructure 8 link 9, 49, 67 Local Service Desk 59 Local Service Desk structure 61 location 61 loss 43-4, 59-60 low availability 37 M machines 80 maintain/improve change-management service levels 76 maintainability 40 maintenance 33, 35, 49, 58 management 5, 9, 11, 20, 32, 43, 48-9, 54, 58 management problem 54 Maximizing services 75 maximum availability 42 Mean Time 37, 42 Mean Time Between Failures, see MTBF Mean Time Between System Incidents, see MTBSI Mean Time to Repair 37, 39 Mean Time to Repair Service (MTRS) 42, 58 metrics 39, 85 minimal business impact 59, 61 Minimum Service Desk Responsibility 63 Modelling 33, 35 money 14, 17, 28, 37 MTBF (Mean Time Between Failures) 37, 39, 42, 58 MTBSI (Mean Time Between System Incidents) 37, 39, 42 MTRS (Mean Time to Repair Service) 42, 58 MTTR 39, 42 N network service provider offerings 43 normal operational service, restoration of 59, 61 norms 10-11 O objective tree 14 objectives flow 14 OLAs (Operational Level Agreement) 16, 20-1, 24, 26, 47, 49, 76 Operational Level Agreement, see OLAs Operational Level Agreements 16, 20-1, 24, 26, 47 operations 12, 71, 81 normal service 63 organization's 31 operations groups 71, 76 organization 5-8, 12, 14-18, 23, 26-8, 30-1, 37, 44-5, 47, 54, 58-9, 66-7, 71 applications development 71 party recovery 45 Organization & Impl 43 organization � Process parameters 24 organizational objectives 5 organization's Customers 27



organizations release policy 78 outputs 10-11, 26 ownership 11, 63-4 P pathways 83 performance 31-3, 63, 66, 71 person 13, 16, 55, 64 perspectives 3, 7, 58 PIR 71-2 Planning to Implement Service Management 8 Point of Sale Services 14 practices, best 6, 8-9, 16 prices 17, 28 Proactive problem Management 70 Problem 16, 18, 62, 67-8, 70, 75, 80-1 problem control 67, 70 problem identification � highlighting customer training 60 Problem Management 4, 9, 47, 52, 54, 58, 67-8, 70, 72 problem management data � 67 problem management process 37 problem review 68, 70 problems 4, 36, 59, 61, 64, 66-8 problems � informing problem management 64 process owner 11, 26 production environments 76 programs 21, 83 project 11, 42, 72 Projected Service Availability (PSA) 73, 75 provision 5, 28 PSA (Projected Service Availability) 73, 75 Q Quiz Questions 3-4, 26, 30, 35, 42, 47, 52, 58, 61, 66, 70, 75, 80 R recovery 28, 39, 44-5, 64, 78 release 17, 42, 47, 52, 55, 76-8, 80-1 Release Management 4, 9, 76-8, 80-1 release unit 78 reliability 5, 37, 40, 45, 56 repair 37, 39 Reporting service levels 52 request 16-17, 60, 72-3 � Service 60 Requests For Change, see RFCs requirements 5, 14, 18, 21-2, 31-2, 37 resilience 40, 45, 56 resilient infrastructure 43 resolution 64, 68 Resource Capacity Management 32-3, 35 resources 17, 27, 30, 32-3, 44-5, 48, 66 responsibilities 5-6, 12-13, 20, 72 RFCs (Requests For Change) 64, 67, 71-3, 75 Risk Assessment 43-4, 72 risks 11, 44, 54, 73 roles 5, 7, 12-13, 49, 75 support group � Configuration Management 55 root cause 67-8 Root cause analysis of low availability 37 S



Sale Services 14 SAM (Software Asset Management) 8 SC, see Service Catalogue scope 45, 55-6 seats 54 security 9, 40, 48-50 Security Management 3, 8-9, 19, 48, 50, 52 security measures 48-9 Self-Contained units of organizations 26 service asset 78 Service Asset & Configuration Management 47 service availability 40, 60, 73 service availability matches 42 Service Capacity Management 32-3, 35 Service Catalogue (SC) 3, 17, 21, 26, 30, 35, 47, 49, 76 service catalogue � 20 Service Catalogue � Guarding Agreements 21 service component 78 Service Continuity 44, 47, 49-50, 52 Service Continuity Management 3, 9, 19-20, 37, 43, 45, 47, 52, 56 Service continuity Mgt and Information Security Mgt 37 service cost 20 Service Delivery 7-9, 16, 18-19, 31 required 31 Service Delivery and Service Support processes 11 Service Delivery and Support 12 Service Delivery processes 47, 52 Service Delivery Processes 3, 19 Service Desk 4, 9, 12, 17, 26, 43, 47, 52, 55, 59-61, 63-4, 66, 80-1 service desk function 12 Service Desk Operator 66 service desk structures 59 Service Desk type 60-1 service hours 15 Service Improvement Plan 3, 21, 24, 26 SERVICE IMPROVEMENT PLAN, see SIP Service Level Agreement, see SLAs Service Level Agreements 17, 20-1, 26, 37, 42, 47 Service Level Management 3, 9, 14, 20-1, 26, 30, 35, 37-8, 42, 47, 52, 59, 61, 70, 80-1 responsibility of 30, 35 service Level Manager 37 Service Level Requirements see SLRs legitimate 21 service levels 9, 14, 17, 20-1, 23-4, 33, 47, 49, 54, 59-61 service levels � Monitoring 60 service levels � Reporting 20 service levels � Security 40 Service Management 5-6, 8-9, 16-17, 20, 83 service management perspective 8 Service Management processes 24, 54, 58 service managers 8 service owner 11, 52 service providers 5, 9, 13, 17, 20-1, 23, 27-8 service provision 8, 28 service quality 5, 20-1, 63, 71 Service Quality Plan 3, 21, 24 SERVICE QUALITY PLAN, see SQP service recovery 39 Service Requests 60 Service Requirements 52 service strategy 21



Service Support 8-9 Service Support and Service Delivery concepts 9 Service Support Function 53 SERVICE SUPPORT FUNCTION & PROCESSES 4 Service Support processes 80-1 service targets 20 service time 40 service unavailability 37 serviceability 40 services changed 35 documents 17 end-to-end 32 live 5 modified 17 multiple 22 multiple geographic locations � Virtual 59 operational 21 outsourced 45 provision 27 restore 66 supplying 17 services facilities 43 services market 27 services organization 27 services � capacity management 19 services � Time constraints 44 set 8, 10, 16-18, 33, 37, 66, 68, 77 SIP (SERVICE IMPROVEMENT PLAN) 3, 21, 24, 26 SLAs (Service Level Agreement) 17, 20-3, 26, 32, 37, 42, 47, 49, 55, 73, 76 SLAs, based 22 SLM 49 SLM process and Service Level Agreement 21 SLRs (Service Level Requirements) 9, 17, 21, 26, 32, 37, 80 software 7, 15-16, 55, 58, 77-8 Software Asset Management (SAM) 8 SQP (SERVICE QUALITY PLAN) 3, 21, 24 staff 5, 7, 15, 26, 30, 32, 52 stakeholders 5, 7, 10, 16, 26 state 12-13, 15, 42 statement 17, 21, 61 status 55, 60 status accounting 55, 58 storage 33 Strong change management 71 Strong operational change management 71 Study Guide Budgeting 28 Study Guide Multi-level 23 Study Guide Proactive Problem Management 68 Study Guide Question 81 Study Guide Security 50 Study Guide Security Management 9 Study Guide Specifically 21 Study Guide Table of Contents 3 sub-process 32, 35 suppliers 6, 24, 37, 47, 77, 80 support services 47 sustained availability levels 50 symptom 63, 67 System Incidents 39, 42 systems 15, 18, 33, 37, 45, 56, 61, 78



T targets, service level 20-1 technology 5, 8-9, 32, 58, 66, 71 Terminology 3-4, 24, 28, 40, 56, 60, 68, 73, 78 terminology, common 3, 15 terms 5, 11, 15, 39, 42, 45, 56, 58, 67 test 16, 54-5, 71-2 Threats 44-5, 56 tools 7-8, 12, 14-16, 26, 33, 43, 54 Train service desk 30, 35 Tuning 35 U UC, see Underpinning Contract UCs (Underpinning Contracts) 18, 20-1, 24 un-availability, prolonged 44 unavailability 37, 39 Underpinning Contract (UC) 18, 20-1, 24, 26, 47 Underpinning Contracts (UCs) 18, 20-1, 24 uptime 39 users 18, 47, 52, 61, 64, 66-7, 80 V VBF, see Vital Business Function verification 58, 60 Vital Business Function (VBF) 18, 37, 40, 44 Vital Business Functions 44 volume 8-9, 33 W workaround 66, 68 workloads 20 www.artofservice.com.au 83, 85 www.theartofservice.com 85 www.theartofservice.org 85

itil v2 foundation complete certification kit: study guide book and online course

Documents