The ITIL V3 Factsheet Benchmark Guide: An Award-Winning ITIL Trainers Tips On Achieving ITIL V3 And ITIL Foundation Certification For ITIL Service Management, Second Edition

FOREWORD Thank you for your interest in our ITIL® Factsheets. These process factsheets have been very helpful to many o...

Author: Ivanka Menken | Gerard Blokdijk | Claire Engle

248 downloads 1337 Views 5MB Size Report

This content was uploaded by our users and we assume good faith they have the permission to share this book. If you own the copyright to this book and it is wrongfully on our website, we offer a simple DMCA procedure to remove your content from our site. Start by pressing the button below!
Report copyright / DMCA form

DOWNLOAD PDF

FOREWORD Thank you for your interest in our ITIL® Factsheets. These process factsheets have been very helpful to many of our clients in preparing for their ITIL Service Management Practices certification exams and in their daily jobs. This version of the factsheets is based on ITIL v3 and will give you the most up-to-date information about the framework. It also offers an overview of the inter-process relationships: vital information for everyone who needs to fully understand the benefits of the ITIL® framework. The strength of the ITIL® framework and the Service Lifecycle is not in the individual processes, but in the synergy and structure they create together to support the IT Service Management organization. I am certain that you will enjoy these factsheets and refer back to them over and over again.

Regards Ivanka Menken Executive Director The Art of Service Pty Ltd http://www.theartofservice.com/

Notice of Rights: © The Art of Service. All rights reserved. No part of this book may be reproduced or transmitted in any form by any means, electronic, mechanical, photocopying, recording, or otherwise, without the prior written permission of the publisher. Notice of Liability: The information in this book is distributed on an “As Is” basis without warranty. While every precaution has been taken in the preparation of the book, neither the author nor the publisher shall have any liability to any person or entity with respect to any loss or damage caused or alleged to be caused directly or indirectly by the instructions contained in this book or by the products described in it. Trademarks: Many of the designations used by manufacturers and sellers to distinguish their products are claimed as trademarks. Where those designations appear in this book, and the publisher was aware of a trademark claim, the designations appear as requested by the owner of the trademark. All other product names and services identified throughout this book are used in editorial fashion only and for the benefit of such companies with no intention of infringement of the trademark. No such use, or the use of any trade name, is intended to convey endorsement or other affiliation with this book. 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.

1

Write a Review & Receive a Bonus Emereo eBook of Your Choice: Up to $99 RRP FREE! If you recently bought this book we would love to hear from you! Submit a review of this purchase and you’ll receive an additional free eBook of your choice from our catalog at http://www.emereo.org.

How Does it Work? Submit your review of this title via the online store where you purchased it. For example, to post a review on Amazon, just log in to your account and click on the Create Your Own Review button (under Customer Reviews) on the relevant product page (you’ll find plenty of example product reviews on Amazon). If you purchased from a different online store, simply follow their procedures.

What Happens When I Submit my Review? Once you have submitted your review, send us an email via [email protected], and include a link to your review and a link to the free eBook you’d like as our thank-you (from http://www.emereo.org – choose any book you like from the catalog, up to $99 RRP). You will then receive a reply email back from us, complete with your bonus eBook download link. It's that simple.

Copyright The Art of Service Brisbane, Australia │ Email: [email protected] │Web: http://theartofservice.com │eLearning: http://theartofservice.org Phone: +61 (0)7 3252 2055

2

TABLE OF CONTENTS FOREWORD .............................................................................................. 1 Write a Review & Receive a Bonus Emereo eBook of Your Choice: Up to $99 RRP FREE! ......................................................................................... 2 TABLE OF CONTENTS ................................................................................ 3 Service Strategy Processes ...................................................................... 4 FINANCIAL MANAGEMENT FOR IT SERVICES ........................................... 5 SERVICE PORTFOLIO MANAGEMENT ......................................................10 DEMAND MANAGEMENT .......................................................................16 Service Design Processes ....................................................................... 20 SERVICE CATALOGUE MANAGEMENT .....................................................21 SERVICE LEVEL MANAGEMENT ..............................................................25 CAPACITY MANAGEMENT ......................................................................30 AVAILABILITY MANAGEMENT ................................................................35 IT SERVICE CONTINUITY MANAGEMENT .................................................40 INFORMATION SECURITY MANAGEMENT ................................................45 SUPPLIER MANAGEMENT ......................................................................51 Service Transition Processes .................................................................. 56 TRANSITION PLANNING AND SUPPORT ..................................................57 CHANGE MANAGEMENT ........................................................................59 SERVICE ASSET AND CONFIGURATION MANAGEMENT .............................64 RELEASE & DEPLOYMENT MANAGEMENT ................................................69 SERVICE VALIDATION & TESTING .........................................................74 EVALUATION ......................................................................................79 KNOWLEDGE MANAGEMENT .................................................................80 Service Operation Functions .................................................................. 84 SERVICE DESK FUNCTION ....................................................................85 TECHNICAL MANAGEMENT FUNCTION ....................................................89 IT OPERATIONS MANAGEMENT FUNCTION..............................................92 APPLICATION MANAGEMENT FUNCTION .................................................95 Service Operation Processes .................................................................. 98 EVENT MANAGEMENT ..........................................................................99 INCIDENT MANAGEMENT .................................................................... 104 REQUEST FULFILLMENT ..................................................................... 109 PROBLEM MANAGEMENT .................................................................... 113 ACCESS MANAGEMENT ...................................................................... 118 CSI Processes ...................................................................................... 122 THE 7-STEP IMPROVEMENT PROCESS .................................................. 123 SERVICE MEASUREMENT AND REPORTING ........................................... 127 GLOSSARY ............................................................................................ 131


3

service strategy Service Strategy Processes This section contains the factsheets for: • • •

Financial Management for IT Services Service Portfolio Management Demand Management


4

service strategy FINANCIAL MANAGEMENT FOR IT SERVICES Why 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. 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; and  Outsourcing — Annuity-based contractual arrangement that details how an organization will provide 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. 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; and  To assist management decisions on IT investment by providing detailed cost analysis regarding changes to IT Services.

Financial Management (for IT Services) Budgeting • Document the known budget cost of infrastructure • Estimate variable budget items • Production of the actual budget Accounting • Deals with variations away from the expected budget • Maintains accounts and cost centre information Charging • Production of invoices based on agreed charging (and collection of funds)

Inputs and outputs IT Financial Management responsibilities do not exist solely within the IT finance and accounting domain. Rather, many parts of the enterprise interact to generate and consume IT financial information.  Service valuation – quantifies, in financial terms, the funding sought by the business and IT for services delivered, based on the agreed value of those services. • Provisioning Value • Service Value Potential  Demand modeling  Service portfolio management  Service provisioning optimization  Planning confidence  Service investment analysis  Accounting  Compliance  Variable cost dynamics


5

service strategy Activities  Service Valuation • Direct versus indirect costs • Labor costs • Variable cost elements • Translation from cost account data to service value  Service provisioning models and analysis • Managed services • Shared services • Utility-based provisioning • On-shore, off-shore or near-shore? • Service provisioning cost analysis  Funding model alternatives • Rolling plan funding • Trigger-based plans • Zero-based funding  Business Impact Analysis (BIA)


6

service strategy Key Decisions  Cost recovery, value centre or accounting centre?  Chargeback: to charge or not to charge?  Financial Management implementation checklist • Track 1 – Plan • Track 2 – Analyze • Track 3 – Design • Track 4 – Implement • Track 5 – Measure Terminology Service Asset A Service Asset is any capability or resource of a service provider. Service Valuation A measurement of the total cost of delivering an IT Service, and the total value of the business of that IT Service. Service valuation is used to help the business and the IT Service provider agree on the value of the IT Service. Service Warranty Service warranty for a service provides the customer a level of reassurance and guarantee to meet agreed requirements. Service Utility Service Utility defines the functionality of an IT Service from the customer’s perspective (i.e. what the service does). Accounting Centre Costing inputs with 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 Notional Charging creates 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 behavior 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. Cost The costs fall into 3 broad categories:  Staff - administration for Financial Management;  Extra hardware and book keeping software; and  Support Tools. Once costs are visible, and particularly when Real Charging is in place, the demand for some services may fall. This results in reduced revenue but is not really a cost of implementation, as it is in the organization's interest to identify and reduce inefficient use of IT resources.


7

service strategy


8

service strategy


9

service strategy

SERVICE PORTFOLIO MANAGEMENT Why The purpose of a Service Portfolio is to describe a provider’s services in terms of the business value. These services articulate business needs and how the provider responds to those needs. By definition, the “business value terms” correspond to marketing terms, and in doing so, provide means for comparing service competitiveness across alternative providers. Objective The Service Portfolio is divided into three categories:  Service Pipeline (proposed or in development);  Service Catalogue (Live or available for deployment); and  Retired Services (decommissioned services).

Service Portfolio Management aims to clarify the following questions:     

Why should a customer buy these services? Why should they buy these services from us? What are the pricing or chargeback models? What are our strengths and weaknesses, priorities and risks? How should our resources and capabilities be allocated?


10

service strategy Inputs and outputs The decisions should be correlated to budgetary and financial plans (budget allocations should enforce the allocation of resources). During this exercise Service Portfolio Management will engage with the other lifecycle phases:  Newly chartered services are promoted to Service Design;  Existing services will be refreshed in the Service Catalogue; and  Retired services are forwarded to Service Transition. Activities  Define: Collates information from all existing services as well as every proposed service (this includes any services in the conceptual phase). The scope covers all the services the organization would provide if it had unlimited resources, capabilities and time.  Analyze: The ‘Analyze’ exercise is performed to find the perspectives, plans, patterns and positions. This information is used to guide the analysis and the desired outcomes of Service Portfolio Management. Understanding their options helps senior management to make informed investment decisions, with regards to service initiatives. Questions asked here include: • What are the long term goals of the service? • What services are required to meet those goals? • What capabilities and resources are required to deliver and support these services? • How will we get there?  Approve: The two previous activities lead to a good understanding of what the future holds. This exercise is concerned with completing the final draft of the portfolio. The outcomes for existing services fall into six categories: The 6 Rs: • Retain • Replace • Rationalize • Re-factor • Renew • Retire  Charter: This exercise is concerned with communicating decisions and allocating sufficient resources and charter services. Decisions will be communicated via a clear and unambiguous report that includes detailed action points for implementation.


11

service strategy Terminology Service Asset A Service Asset is any capability or resource of a service provider. These types of assets are used by organizations to create value in the form of goods and services. It is relatively easier to acquire resources compared to capabilities. Service Valuation Service Valuation provides the business and IT with the measurements to agree on the value of IT Services (cost vs. benefit analysis). Value is created by combining warranty and utility. Business case A model of what a service is expected to achieve; the justification for pursuing a course of action to meet organizational goals. The assessment of service investments in terms of potential benefits and the resources and capabilities required to provision and maintain it. Utility Functionality offered by a product or service to meet a particular need. Utility is often summarized as ‘what it does’. Warranty A promise or guarantee that a product or service will meet its agreed requirements. TTB Transform the Business. RTB Run the Business. GTB Grow the Business. Service Pipeline A database or structured document listing all IT services that are under consideration or development, but are not yet available to customers. Service Catalogue Database or structured document with information about all LIVE IT Services, including those available for deployment, and is available to customers. Retired Services Decommissioned Services.


12

service strategy Utility + Warranty = Value

Performance supported? Constraints removed?

UTILITY

Fit for purpose?

Value

Available enough? Capacity enough? Continuous enough?

WARRANTY

Fit for use?

Secure enough?

Cost      

Personnel – Release staff Accommodation – Physical location (set-up and ongoing) Software – Tools (set-up and ongoing) Hardware – Infrastructure (set-up) Education – Training (set-up and ongoing) Procedures – External consultants etc. (set-up).


13

service strategy


14

service strategy


15

service strategy DEMAND MANAGEMENT Why Demand Management is a critical aspect of service management. Poorly managed demand is a source of risk for service providers because of uncertainty in demand. Objective Demand Management is responsible for understanding and strategically responding to business demands for services by:  

Analyzing patterns of activity and user profiles; and Provisioning capacity in line with strategic objectives.

Activities  Activity-based Demand Management Unlike goods, services cannot be manufactured in advance and stocked, in anticipation of demand. There is no ‘here is one I prepared earlier’. The productive capacity of resources available to a service is adjusted accordingly to demand forecasts and patterns. Some types of capacity can be quickly increased as required and quickly released when not in use. The arrival of demand can be influenced using either financial constraints or pricing incentives or physical constraints.  Business activity patterns and user profiles Business processes are the primary source of demand for services. Patterns of business activity (PBA) influence the demand patterns seen by the service providers. It is very important to study the customers business to identify, analyze and understand such patterns to provide a sufficient foundation for capacity management. Analyzing and tracking the activity patterns of the business process make it possible to predict demand for services in the catalogue that support the process. Every additional unit of demand generated by business activity is allocated to a unit of service capacity. Activity-based Demand Management can link the demand patterns to ensure that the customer’s business plans are synchronized with the service management plans of the service provider. Service production cannot occur without the concurrent presence of demand that consumes the output. It is a pull-system where consumption cycles stimulate production cycles. Consumption produces demand and production consumes demand.

Business activity influences patterns of demand for services © Crown Copyright 2007 Reproduced under license from OGC Copyright The Art of Service Brisbane, Australia │ Email: [email protected] │Web: http://theartofservice.com │eLearning: http://theartofservice.org Phone: +61 (0)7 3252 2055

16

service strategy Terminology Business Relationship Manager (BRM) A role responsible for maintaining the relationship with one or more customers. Often combined with the Service Level Manager role. Core service An IT service that delivers basic outcomes desired by one or more customers. Pattern of Business Activity (PBA) A workload profile of one or more business activities. Patterns of business activity are used to help the IT Service Provider understand and plan for different levels of business activity. Service Level Package (SLP) A defined level of utility and warranty for a particular service package. Each SLP is designed to meet the needs of a particular pattern of business activity. User Profile A pattern of user demand for IT Services. Each user profile includes one or more patterns of business activity.

Cost     

Personnel – Release staff Accommodation – Physical location (set-up and ongoing) Software – Tools (set-up and ongoing) Hardware – Infrastructure (set-up) Education – Training (set-up and ongoing).


17

service strategy


18

service strategy


19

service design Service Design Processes This section contains the factsheets for:       

Service Catalogue Management Service Level Management Capacity Management Availability Management IT Service Continuity Management Information Security Management Supplier Management.


20

service design SERVICE CATALOGUE MANAGEMENT Why This process ensures that a Service Catalogue is produced, maintained and contains accurate information on all operational services and those being developed.

Objective Provide a widely available, single source of consistent information on all agreed services for authorized users.

Inputs and outputs  Inputs • Business information from the organization’s business and IT strategy, plans and financial plans, and information no their current and future requirements from the Service Portfolio • Business Impact Analysis, providing information on the impact, priority and risk associated with each service or changes to service requirements • Business requirements • The Service Portfolio • The CMS • Feedback from all other processes  Outputs • The documentation and agreement of a ‘definition of the service’ • Updates to the Service portfolio • The Service Catalogue: should contain details and the status of every live and transitioning service.

Activities The Service Catalogue has two aspects, the Business Service Catalogue and the Technical Service Catalogue. Key activities include:  Agreeing on and documenting a service definition with all relevant parties  Interfacing with Service Portfolio Management to agree on the contents of the Service Portfolio and Service Catalogue  Producing and maintaining a Service Catalogue and its contents  Interfacing with the business and IT Service Continuity Management on the dependencies of business units and their business processes with the supporting IT services, contained within the Business Service Catalogue  Interfacing with support teams, suppliers and Configuration management on interfaces and dependencies between IT services and the supporting services, components and CIs contained within the Technical Service Catalogue service design  Interfacing with Business Relationship management and Service Level management to ensure information is aligned to the business process.


21

service design

The Business Service Catalogue and the Technical Service Catalogue © Crown Copyright 2007 Reproduced under license from OGC

Terminology Operational Level Agreement (OLA) A written agreement between an IT Service Provider and another part of the same organization. Service Level Agreement (SLA) Agreement between an IT Service Provider and a customer. Service Level Requirement (SLR) A customer requirement for an aspect of an IT Service. SLRs are based on business objectives and are used to negotiate agreed Service Level Targets. Business Impact Analysis (BIA) BIA is the activity in Business Continuity Management that identifies vital business functions and their dependencies. Configuration Item (CI) Any component that needs to be managed in order to deliver an IT Service.

Cost      

Personnel – Release staff Accommodation – Physical location (set-up and ongoing) Software – Tools (set-up and ongoing) Hardware – Infrastructure (set-up) Education – Training (set-up and ongoing) Procedures – External consultants etc. (set-up)


22

service design


23

service design


24

service design SERVICE LEVEL MANAGEMENT Why As enterprises become increasingly dependent on IT, they demand a higher quality of service. By creating an IT Service Management (ITSM) strategy, enterprises are able to maximize end-user productivity, improve operational effectiveness and enhance overall business performance. Additionally, the effort creates a forum for communication between the IT organization and the business units. Also an ITSM strategy provides the basis for integrating IT measurement into operational and strategic IT management. In most cases, however, service management is not well-defined or not defined at all. Service Level Management principles form the basis on how to contribute to an ITSM culture to ensure that the right services with the appropriate quality are delivered, at the right cost, to end-users. Although Service Level Management (SLM) is focused heavily on CSI, this process also plays a major part in the Service Design book, especially its involvement in Service Catalogue Management and Supplier Management. Objective To maintain and improve IT Service quality, through a constant cycle of agreeing, monitoring and reporting upon IT Service achievements and instigation of actions to eradicate poor service - in line with business or cost-justification. Through these methods, a better relationship between IT and its Customers can be developed.  The objectives of SLM are to: • Define, document, agree, monitor, measure, report and review the level of IT services provided; • Provide and improve the relationships and communication with the business and customers; • Ensure that specific and measurable targets are developed for all IT services; • Monitor and improve customer satisfaction with the quality of service delivered; • Ensure that IT and the customers have a clear and unambiguous expectation of the level of service to be delivered; and • Ensure that proactive measures to improve the levels of service delivered are implemented wherever it is cost-justifiable to do so. Inputs and outputs  Inputs: • Business information • Business Impact Analysis • Business requirements • The strategies, policies and constraints from Service Strategy • The Service Portfolio and Service Catalogue • Change information • CMS • Customer and user feedback, complaints and compliments  Outputs: • Service reports • Service Improvement Plan (SIP) • The Service Quality Plan • Document templates • Service Level Agreements (SLAs) • Service Level Requirements (SLRs) • Operational Level Agreements (OLAs) • Reports on OLAs and underpinning contracts • Service review meeting minutes and actions • SLA review and service scope review meeting minutes • Revised contracts. Copyright The Art of Service Brisbane, Australia │ Email: [email protected] │Web: http://theartofservice.com │eLearning: http://theartofservice.org Phone: +61 (0)7 3252 2055

25

service design Activities  Determine, negotiate, document and agree requirements for mew or changed services in SLRs, and manage and review them through the service  Monitor and measure service performance achievements of all operational services against targets within SLAs  Collate, measure and improve customer satisfaction  Produce service reports  Conduct service review and instigate improvements within an overall Service Improvement Plan (SIP)  Review and revise SLAs, service scope OLAs, contracts, and any other underpinning agreements  Develop and document contracts and relationships with the business, customers and stakeholders  Develop, maintain and operate procedures for logging compliments and complaints  Provide the appropriate management information to aid performance management and demonstrate service achievement  Make available and maintain up-to-date SLM document templates and standards.

Terminology Operational Level Agreement (OLA) A written agreement between an IT Service Provider and another part of the same organization. Service Catalogue A database or structured document with information about all live IT services, including those available for deployment. The Service Catalogue is the only part of the Service Portfolio published to customers. Includes information about deliverables, prices, contact points, ordering and request processes. Service Improvement Plan (SIP) A formal plan to implement improvements to a process or IT service. Service Level Agreement (SLA) Agreement between an IT Service Provider and a customer. Service Level Requirement (SLR) A customer requirement for an aspect of an IT Service. SLRs are based on business objectives and are used to negotiate agreed Service Level Targets. Service Quality Plan (SQP) – not specifically an SLM term, but strategically linked 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. Underpinning Contract (UC) service design A contract between an IT Service provider and a third party. The third party provides goods or services that support delivery of an IT service to a customer.


26

service design Cost The costs associated with implementing and executing SLM include:     

Staff costs (salaries, training, recruitment costs, consultancy - if needed), both initial and ongoing Accommodation costs (physical space for staff, documentation space, etc.) Support tools (monitoring and reporting, plus some element of integrated Service Management tools) Hardware on which to run these tools Marketing costs e.g. production of Service Catalogue.

The cumulative effect of Change Management should lead to a gradual improvement in service quality and an overall reduction in the cost of service provision.


27

service design


28

service design


29

service design CAPACITY MANAGEMENT Why 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 infrastructure of an organization (e.g. remote storage of back-up data, for example). Failure to consider these issues will lead to 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. Inputs and outputs  Inputs • Business information • Service and IT information • Component performance and capacity information • Service performance issues • Service information • Financial information • Change information • Performance information • CMS • Workload information  Outputs • The Capacity Management Information System (CMIS) • The Capacity Plan • Service performance information and reports • Workload analysis and reports • Ad hoc capacity and performance reports • Forecasts and predictive reports • Thresholds, alerts and events Activities  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.  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.  Component 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 capacity are monitored and measured, and that the collected data is recorded, analyzed and reported. Copyright The Art of Service Brisbane, Australia │ Email: [email protected] │Web: http://theartofservice.com │eLearning: http://theartofservice.org Phone: +61 (0)7 3252 2055

30

service design  The underpinning activities of Capacity Management: • Tuning and optimization activities • Utilization monitoring • Threshold management and control • Demand management • Modeling and trending • Application sizing.

Iterative Activities (Performance Management)  Analysis  Tuning  Implementation  Monitoring Other Activities  Demand management  Application sizing  Modeling  Storage of Capacity Data  Capacity Plan development and maintenance.


31

service design

Terminology Capacity The maximum throughput that a Configuration Item or IT Service can deliver whilst meeting agreed Service Level Targets. Capacity Plan A Capacity plan is used to manage the resources required to deliver IT Services. The plan contains scenarios for different predictions of business demand, and costed options to deliver the agreed Service Level targets.

Cost The costs associated with establishing a Capacity Management process include:  Monitoring tools (for performance and utilization) covering hardware, operating system and application Capacity. These tools should be capable of monitoring and collecting data from all required host, network and client environments  CDB (Capacity Database) for holding a historic record of all service, technical, utilization, financial and business data  Modeling tools for performing simulation modeling and statistical analysis  Project management - implementation of Capacity Management should be treated as a project  Staff costs - recruitment, training and consultancy costs associated with the set-up of the Capacity Management process  Accommodation - provision of an adequate working environment and facilities, which may be distributed.  Annual maintenance and required upgrades of all hardware and software tools  On-going staff costs including salaries, further training and ad-hoc consultancy  Recurring accommodation costs such as leasing, rental and energy costs.


32

service design


33

service design


34

service design AVAILABILITY MANAGEMENT Why 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 “highavailability” 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 optimize the capability of the IT Infrastructure, services and supporting organization to deliver a costeffective and sustained level of Availability that matches or exceeds the current and future needs of the business.

Inputs and outputs  Inputs: • Business information • Business impact information • Previous Risk Analysis • Service information • Financial Information • Change and release information • Configuration management • Service targets • Component information • Technology information • Past performance • Unavailability and failure information  Outputs: • Availability Management Information System (AIMS) • The Availability Plan for the proactive improvement of IT services and technology • Availability and recovery design criteria and proposed service targets for new or changed services • Service availability, reliability and maintainability reports of achievements against targets, including input for all service reports • Component availability • Revised risk analysis reviews and reports • Monitoring, management and reporting requirements for IT services and components • Availability management test schedule • Planned and preventative maintenance schedules • Projected Service Outage (PSO)


35

service design Activities The Availability Management process has two key elements: reactive and proactive activities.  Reactive Activities: • Monitoring the actual availability delivered versus agreed targets service design • Establishing measures of availability and agreeing availability targets with the business • Identifying unacceptable levels of availability that impact the business and users • Reviewing availability with the IT support organization • Continual improvement activities to optimize availability.  Proactive Activities: • Identifying Vital Business functions (VBFs) • Designing for availability • Base product and components • Systems management • Service management processes • High-availability design • Special solutions with full redundancy.  Root cause analysis of low availability • Relationship with the Problem Management process  Producing & maintaining an Availability Plan  Reporting. Availability % = (Agreed Service Time - Downtime / Agreed Service Time) X 100%

Terminology Availability Key indicator of the service provided. It should be defined in the Service Level Agreement. Reliability Reliability of the service is made up out of the reliability of Service Components and the resilience of the IT Infrastructure. Serviceability rd Contractual arrangements with 3 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.


36

service design Other Process Relationships The connection between Incident Management (detection), Problem Management (diagnosis), Change Management (repair time) and Availability Management is shown in the following diagram:

The following metrics are commonly used in Availability Management:  Mean Time to Restore Services - MTTRS: 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.  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 MTRS, 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.

Cost      

Personnel – Staff (set-up and ongoing) Accommodation – Physical location (set-up and ongoing), also for documentation Software – Tools (set-up and ongoing), monitoring and reporting tools Hardware – Infrastructure (set-up and ongoing), perhaps you need a dedicated database Education – Training (set-up and ongoing) Procedures – External consultants etc. (set-up).


37

service design


38

service design


39

service design IT SERVICE CONTINUITY MANAGEMENT Why 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. 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 The Objective for ITSCM is to support the overall Business Continuity Management process by ensuring that the required IT technical and service facilities (including computer systems, networks, applications, telecommunications, technical support and Service Desk) can be recovered within required, and agreed, business timescales. Inputs and outputs  Inputs: • Business information • IT information • A Business Continuity Strategy and set of Business Continuity Plans • Financial information • Change information • Configuration Management System • Business Continuity management and Availability Testing Schedules • IT Service Continuity Plans.  Outputs: • A revised ITSCM policy and strategy • A set of ITSCM plans, including all Crisis Management, Emergency response and Disaster Recovery plans • Business impact Analysis exercises and reports • Risk Analysis and Management reviews and reports • An ITSCM testing schedule • ITSCM test scenarios • ITSCM test reports and reviews. Activities Stage 1: Initiation     

Policy Setting Specify terms of reference and scope Define the project organization and scope Allocate Resources Agree on project and quality plans

Stage 2: Requirements and Strategy  Business Impact Analysis  Risk Analysis  Discuss recovery options (link to SLM)


40

service design Stage 3: Implementation  Write Continuity plans, including: • Emergency Response Plan • Damage Assessment Plan • Salvage Plan • Crisis Management and PR Plan  Implement stand-by arrangements  Implement recovery options  Test the plans  Develop and implement procedures and working instructions. Stage 4: Ongoing operation    

Education, awareness and training - IT Staff need to be aware and trained to use the plans Review – to ensure deliverables from the ITSCM process remain current Testing – establish a program of regular testing Link ITSCM to Change Management to keep plans and recovery options up-to-date.

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) rd A contract with 3 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)


41

service design Cost       

Production of the evacuation plan Risk analysis and execution of continuity planning Take measures regarding risk management Provide options for replacement Maintain the plan Testing and reviewing the plan Educate staff.


42

service design


43

service design


44

service design INFORMATION SECURITY MANAGEMENT Why In recent times, 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 crisis 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 with regard to security measures, if “you fail to plan, you plan to fail”. Objective To align IT security with business security and ensure that information security is effectively managed in all service and Service management activities. Inputs and outputs  Inputs • Business information • Corporate governance and business security policies and guidelines • IT information • Service information • Risk Analysis processes and reports • Details of all security events and breaches • Change information • Configuration Management System • Details of partner and supplier access  Outputs • An overall information Security management Policy • Security Management Information System • Revised security risk assessment processes and reports • A set of security controls • Security audits and audit reports • Security test schedules and plans • Reviews and reports of security breaches and major incidents • Policies, processes and procedures for managing partners and suppliers and their access to services and information. Activities  Production, review and revision of an overall Information Security Policy and a set of supporting specific policies  Communication, implementation and enforcement of the security policies  Assessment and classification of all information assets and documentation  Implementation, review, revision and improvement of a set of security controls and risk assessment and responses  Monitoring and management of all security breaches and major security incidents  Analysis, reporting and reduction of the volumes and impact of security breaches and incidents  Schedule and completion of security reviews, audits and penetration tests.


45

service design

Produce and maintain an Information Security Policy

Communicate, implement and enforce adherence to all security policies

Monitor and manage security incidents and breaches

Assess and Categorize information assets, risks and vulnerabilities

Regularly assess, review and report security risks and threats

Report, review and reduce security breaches and major incidents

Security Management Information System

Information Security Policy (s)

Impose and review risk security controls, review and Implement risk mitigation

Security reports and information

Security controls

Security risks and responses

IT Security Management process © Crown Copyright 2007 Reproduced under license from OGC


46

service design Terminology Confidentiality Protecting information against unauthorized access and use. Integrity Accuracy, completeness and timeliness of the information. Availability The information should be accessible at any agreed time. This depends on the continuity provided by the information processing systems. Security Baseline The security level adopted by the IT organization for its own security and from the point of view of good ‘due diligence’. Security Incident Any incident that may interfere with achieving the SLA security requirements; materialization of a threat. Verifiability Ability to verify that information is used correctly and that security measures are effective. Security Baseline The security level adopted by the IT organization for its own security and from the point of view of good ‘due diligence’.

Relationship with other ITIL processes  Information Security Management sets policy for all other processes  Availability Management performs risk assessment for Confidentiality, Integrity and Availability (CIA) on Data. Security Management uses this information for IT Security  Change Management and Release Management implement changes regarding security measures and security policy  Service Level Management has security measures as part of a Service Catalogue, SLA’s and other SLM-documents  Access Management helps to protect the confidentiality, integrity and availability (CIA) of assets; therefore it is the execution of policies and actions defined in Information Security and Availability Management.

Cost      

Awareness Production of the security plan Measures taken regarding security management Maintaining the plan Testing and reviewing the plan Education of staff.


47

service design

Threat Prevention/ Reduction Incident Detection/ Repression Damage Correction/ Recovery Control Evaluation © Crown Copyright 2007 Reproduced under license from OGC

Security Measures Reduction: firewall, virus checkers, locks on doors, procedures Detection: review of logs, virus detection, alarm systems Repression: unplug infected system, detain unauthorized person Correction: invoke security incident process Evaluation: conduct post security incident review.


48

service design


49

service design


50

service design SUPPLIER MANAGEMENT Why This process is responsible for ensuring that all contracts with suppliers support the needs of the business and that all contractual commitments are met.

Objective The main objectives of Supplier Management are to:  Obtain value for money from supplier and contracts  Ensure the underpinning contracts and agreements with suppliers are aligned to business needs, and support and align with agreed targets in SLRs and SLAs, in conjunction with SLM  Manage relationships with suppliers  Manage supplier performance  Negotiate and agree contracts with suppliers and manage them through their lifecycle  Maintain a supplier policy and a supporting Supplier and Contract Database (SCD).

Supplier strategy & policy

Evaluation of new suppliers & contracts

Supplier categorization & maintenance of the SCD

Establish new Suppliers & contracts

Supplier & contract Management & performance Supplier & Contract Database SCD Supplier reports and information

Contract renewal and/or termination

Supplier Management process © Crown Copyright 2007 Reproduced under license from OGC


51

service design Activities All Supplier Management process activity should be driven by Service Strategy and policy. In order to achieve consistency and effectiveness in the implementation of the policy, a Supplier and Contract Database (SCD) should be established. The information within the SCD will provide a complete set of reference information for all Supplier Management procedures and activities. Although Supplier Management is firmly placed within the Service Design Phase of the Lifecycle, some of the activities are carried out in the other Lifecycle Phases too.     

Supplier categorization and maintenance of the SCD (occurs within the Service Design phase) Evaluation and setup of new suppliers and contracts (occurs within the Service Design phase) Establishing new suppliers (occurs within the Service Transition phase) Supplier and Contract Management and performance (occurs within the Service Operation phase) Contract renewal and termination (occurs within the Service Operation phase).


52

service design Terminology Supplier and Contract Database (SCD) A database or structured document used to manage supplier contracts throughout their lifecycle. Service Level Agreement (SLA) An agreement between an IT Service Provider and a customer. Service Level Requirement (SLR) A customer requirement for an aspect of an IT service. Underpinning Contract (UC) A contract between an IT Service Provider and a third party.

Cost      



53

service design


54

service design


55

service transition Service Transition Processes This section contains the factsheets for:       

Transition planning and support Change Management Release and deployment management Service asset and configuration management Service validation and testing Evaluation Knowledge Management.


56

service transition TRANSITION PLANNING AND SUPPORT Why Effective Transition Planning and Support can significantly improve a service provider’s ability to handle high volumes of change and releases across its customer base. An integrated approach to planning improves the alignment of the Service Transition plans with the customer, supplier and business change Project Plans. Objective The objective of this process is to:  Plan and coordinate the resources to establish successfully a new or changed service into production within the predicted cost, quality and time estimates  Ensure that all parties adopt the common framework of standard re-usable processes and supporting systems in order to improve the effectiveness and efficiency of integrated planning and coordination activities  Provide clear and comprehensive plans that enable the customer and business change projects to align their activities with the Service Transition plans. Inputs and outputs  Inputs • Authorized RFC • Service Design package • Release package definition and design specification • Service Acceptance Criteria (SAC)  Outputs • Transition strategy • Integrated set of Service Transition plans. Activities  Transition strategy • Purpose, goals and objectives • Context e.g. service customer, contract portfolios • Scope – inclusions and exclusions • Applicable standards, agreements, legal, regulatory and contractual requirements • Organizations and stakeholders involved • Framework for Service Transition • Criteria, people and approach • Deliverables from transition activities including mandatory and optional documentation • Schedule of milestones • Financial requirements  Prepare for Service Transition • Review and acceptance of inputs from other service lifecycle stages • Review and check the input deliverables, e.g. SDP, Service Acceptance Criteria and evaluation report • Identifying, raising and scheduling RFCs • Checking that the configuration baselines are recorded in Configuration Management before the start of Service Transition • Checking transition readiness.  Planning and coordinating Service Transition • Planning on individual Service Transition • Integrated planning • Adopting program and project management best practices • Reviewing the plans.


57

service transition Terminology Request for Change (RFC) A formal proposal for a change to be made. An RFC includes details of the proposed change, and may be recorded on paper or electronically. Service Acceptance Criteria (SAC) A set of criteria used to ensure that an IT Service meets its functionality and quality requirements and that the IT Service Provider is ready to operate the new IT service when it has been deployed. Service Design Package (SDP) Document(s) defining all aspects of an IT service and its requirements through each stage of its lifecycle. A SDP is produced for each new IT service, major change, or IT service requirement.

Cost      

Personnel – Staff (set-up and ongoing) Accommodation – Physical location (set-up and ongoing) Software – Tools (set-up and ongoing) Hardware – Infrastructure (set-up) Education – Training (set-up and ongoing) Procedures – External consultants etc. (set-up).


58

service transition CHANGE MANAGEMENT Why 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, and 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 objective 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. Not every change is an improvement, but every improvement is a change!

The 7 Rs of Change Management cover the questions that must be answered for all changes. 1. 2. 3. 4. 5. 6. 7.

Who RAISED the change? What is the REASON for the change? What is the RETURN required from the change? What are the RISKS involved in the change? What RESOURCES are required to deliver the change? Who is RESPONSIBLE for the build, test and implementation of the change? What is the RELATIONSHIP between this change and other changes?

Inputs and outputs  Inputs • Policy and strategies for change and release • Request for change • Change proposal • Plans – change, transition, release, deployment, test, evaluation and remediation • Current change schedule and PSO • Current assets or configuration items e.g. baseline, service package, release package • As-planned configuration baseline • Test results, test report and evaluation report.  Outputs • Rejected RFCs • Approved RFCs • Change the services, service or infrastructure resulting from approved RFCs • New, changed or disposed assets or configuration items, e.g. baseline, service package, release package • Change schedule • Revised PSO • Authorized change plans • Change decisions and actions • Change documents and records • Change Management reports. Copyright The Art of Service Brisbane, Australia │ Email: [email protected] │Web: http://theartofservice.com │eLearning: http://theartofservice.org Phone: +61 (0)7 3252 2055

59

service transition Activities         

Planning and controlling changes Change and release scheduling Communications Change decision making and change authorization Ensuring there are remediation plans Measurement and control Management reporting Understanding the impact of change Continual improvement.

**Emergency changes follow the same steps, but usually in a different order. The CAB/EC approves an emergency change immediately and the building, testing and implementation are done before the paperwork. But don’t forget the documentation!

Terminology Normal Change A change that follows all of the steps of the change process Standard Change A pre-approved change that is low risk, relatively common and follows a procedure or work instruction. Emergency Change A change that must be introduced as soon as possible; e.g. to resolve a major incident or implement a security patch. 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. ITEC IT Executive Committee, made up of members from the organizations senior management.

Cost      

Personnel – Staff (set-up and ongoing) Accommodation – Physical location (set-up and ongoing) Software – Tools (set-up and ongoing) Hardware – Infrastructure (set-up) Education – Training (set-up and ongoing) Procedures – External consultants etc. (set-up).

The two major costs of Change Management are for staff and software tools support. Copyright The Art of Service Brisbane, Australia │ Email: [email protected] │Web: http://theartofservice.com │eLearning: http://theartofservice.org Phone: +61 (0)7 3252 2055

60

service transition Create RFC

Change proposal (optional)

Record the RFC requested Review RFC Change Management

Ready for evaluation

Assess and evaluate change Ready for decision Authorize Change proposal

Work orders

Authorize Change Change authority

authorized Plan updates

Change Management

schedule

Co-ordinate change implementation Change Management Evaluation report

Work orders

Update change and configuration information in CMS

Initiator

Implemented*

Review and close change record close *Includes build and test the change

Example of process flow for a normal change © Crown Copyright 2007 Reproduced under license from OGC


61

service transition


62

service transition


63

service transition

SERVICE ASSET AND CONFIGURATION MANAGEMENT Why This process ensures the integrity of service assets and configurations in order to support the effective and efficient management of the IT organization.

Objective The objective is to define and control the components of services and infrastructure and maintain accurate configuration information on the historical, planned and current state of the services and infrastructure.

Inputs and outputs  Inputs: • Authorized RFC • Service package, SLP • SDP, including service model and SAC • IT service continuity plan and related business continuity plan • Service management and operations plans and standards • Technology and procurement standards and catalogues • Acquired service assets and components and their documentation • Build models and plans • Environment requirements and specifications • Release policy and release design from Service Design • Release and deployment models including template plans • Exit and entry criteria for each stage of release and deployment  Outputs: • Release and deployment plans • Completed RFCs for the release and deployment activities • Service notification • Updated service catalogue • New tested service capability and environment • New or changed Service Management documentation • Service package that defines the requirements from the business/customer for the service • SLP that defines the service level requirements • SLA, underpinning OLAs, and contracts • Service model • New or changed service reports • Tested continuity plans • Complete and accurate configuration item list • Service capacity plan that is aligned to the relevant business plans • Service Transition Report.


64

service transition Activities Management and 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  Configuration Item (CI) 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 service transition SLAs  Also identify the relationship between CIs and the attributes for every CI. Configuration control The objective of configuration control is to ensure that only authorized and identifiable CIs are recorded in the CMDB upon receipt. Status accounting and reporting Status reports should be produced on a regular basis, listing, for all CIs under control, their current version and change history. 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. Configuration Management Database (CMDB)  Backup, Administration, Housekeeping.


65

service transition

Cost      

Personnel – Audit verification staff, database management team (set-up and ongoing) Accommodation – Physical location (set-up and ongoing) Software – Tools (set-up and ongoing) Hardware – Infrastructure (set-up) Education – Training (set-up and ongoing) Procedures – External consultants etc. (set-up).


66

service transition


67

service transition


68

service transition RELEASE & DEPLOYMENT MANAGEMENT Why 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 2008, 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 The Objective of Release and Deployment Management is to build, test and deliver the capability to provide the services specified by Service Design. This includes the processes, systems and functions to package, build, test and deploy a release into production and prepare for Service Operation.

Inputs and outputs  Inputs: • Authorized RFC • Service package, SLP • SDP, including service model and SAC • IT service continuity plan and related business continuity plan • Service management and operations plans and standards • Technology and procurement standards and catalogues • Acquired service assets • Build models and plans • Environment requirements and specs for build, test, release, training, disaster recovery, pilot and deployment • Release policy and release design from Service Design • Release and deployment models including template plans • Exit and entry criteria for each stage of release and deployment  Outputs: • Release and deployment plan • Completed RFCs for release and deployment activities • Service notification • Updated service catalogue with the relevant information about the new or changed service • New tested service capability and environment • New or changed Service Management documentation • Service package that defines the requirements from the business/customer for the service • SLP that defines service level requirements • SLA, underpinning OLAs and contracts • Service model • New or changed service reports • Tested continuity plans • Complete and accurate configuration item list with an audit trail • Service capacity plan • Deployment ready release package (baselines) for future deployments • Service Transition Report.


69

service transition Activities  Planning • Release and deployment plans • Pass/fail criteria • Build and test prior to production • Planning pilots, release packaging and build • Deployment planning • Financial/commercial planning  Preparation for build, test and deployment  Build and test • Release and build documentation • Acquire and test input configuration items and components • Release packaging • Build and manage the test environments  Service testing and pilots • Service rehearsals • Plan – prepare for the day • Do – deliver the rehearsal • Check – document the day • Act – take action following the rehearsal • Pilots  Prepare and plan for deployment  Perform transfer, deployment and retirement  Verify Deployment  Early life support  Review and close a deployment  Review and close Service Transition. Release management should be used for:  Large or critical hardware deployment, 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 deployment, 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. Release design options and considerations:  ‘Big Bang’ vs. Phased  Push & Pull  Automation vs. Manual.


70

service transition

Terminology Release A collection of hardware, software, documentation, processes or other components required to implement one or more approved changes to IT services. Release Unit Components of an IT service that are normally released together, e.g. one release unit could be a Desktop PC, including hardware, software, licenses, documentation etc. Definitive Spares (DS) – (previously known as DHS) Physical storage of all spare IT components and assemblies maintained at the same level as within the live environment. Definitive Media Library (DML) (previously known as the DSL) One or more locations in which the definitive and approved versions of all software configurations items are securely stored. The DML may also contain associated CIs such as licenses and documentation. Configuration Management Database (CMDB) A database used to store configuration records throughout their lifecycle.

Cost      



71

service transition


72

service transition


73

service transition SERVICE VALIDATION & TESTING Why Service Validation contributes to quality assurance – establishing that the service design and release will deliver a new or changed service or service offering that is fit for purpose and fit for use. Testing is a vital area within Service Management and has often been the unseen underlying cause of what was taken to be inefficient Service Management processes. If services are not tested sufficiently then their introduction into the operational environment will bring rise in:  Incidents – failures in service elements and mismatches between what was wanted and what was delivered impact on business support  Service Desk calls for assistance – services that are not functioning as intended are inherently less intuitive causing higher support requirements  Problems and errors – that are harder to diagnose in the live environment  Costs - since errors are more expensive to fix in production than if found in testing  Services - that are not used effectively by the users to deliver the desired value. Objective The objectives of this process are to:  Provide confidence that a release will create a new or changed service or service offerings that deliver the expected outcomes and value for the customers within the projected costs, capacity and constraints  Validate that a service is ‘fit for purpose’ – it will deliver the required performance with desired constraints removed  Assure a service is ‘fit for use’ –it meets certain specifications under the specified terms and conditions of use  Confirm that the customer and stakeholder requirements for the new or changed service are correctly defined and remedy any errors or variances early in the service lifecycle as this is considerably cheaper than fixing errors in production. Inputs and outputs  Inputs: • The service package • SLP • Service provider interface definitions • The Service Design package • Release and deployment plans • Acceptance Criteria • RFCs  Outputs: • Configuration baseline of the testing environment • Testing carried out • Results from those tests • Analysis of the results. Activities  Validation and test management  Plan and design test  Verify test plan and test design  Prepare test environments  Perform tests  Evaluate exit criteria and report  Test clean up and closure.


74

service transition Terminology Acceptance Formal agreement that an IT service, process, plan or other deliverable is complete, accurate reliable and meets its specified requirements. Acceptance is usually preceded by evaluation or testing and is often required before proceeding to the next stage of a project or process. Evaluation Responsible for assessing a new or changes IT service to ensure that risks have been managed and to help determine whether to proceed with the change. Fit for Purpose Describes whether the process, CI, IT service etc. is capable of meeting its objectives or service levels. Test The activity that verifies that a CI, IT Service, process etc. meets its specified or agreed requirements. Validation The activity that ensures a new or changed IT service, process, plan or other deliverable meets the needs of the business. Validation ensures that business requirements are met even though these may have changed since the original design phase.

Cost      

Personnel – Audit verification staff, database management team (set-up and ongoing) Accommodation – Physical location (set-up and ongoing) Software – Tools (set-up and ongoing) Hardware – Infrastructure (set-up) Education – Training (set-up and ongoing) Procedures – External consultants etc. (set-up).


75

service transition

Level 1

Define Customer/Busines s

Validate Service Packages, Offerings and contracts

Service Review Criteria/Plan • Contract, Service Package, SLP, SPI

1b

1a

Level 2

Define Service Requirements

• SLR • Draft SLA

2a

Design Service Solution

Level 3

2b

• SDP including: • Service Model • Capacity and resource plans

Design Service Release 4a

Service Release Test Criteria

Baseline point

Service Release Package Test 4b

Component and Assembly Test 5b

5a Levels of configuration and testing

3b

• Release Design • Release plan Develop Service Solution

Level 5

BL

Service Operational Readiness Test

Service Operational Criteria/Plan

3a

Level 4

Service Acceptance Test

Service Acceptance Criteria/Plan

Service Component Build and Test

Deliveries from internal and external suppliers

Internal and external suppliers

The V Model concept of establishing acceptance requirements against the requirements and design can apply, with each iterative design being considered for the degree of integrity and competence that would justify release to the customer for trail and assessment. The left hand side represents the specification of the service requirements down to the detailed Service Design. The right hand side focuses on the validation and test activities that are performed against the specifications defined on the left hand side, there is direct involvement by the equivalent party on the right hand side. It shows that service validation and acceptance test planning should start with the definition of service requirements. E.G customers who sign off the agreed service requirements will also sign off the service Acceptance Criteria and test plan.

Example of service V-model © Crown Copyright 2007 Reproduced under license from OGC


76

service transition


77

service transition


78

service transition EVALUATION Why Evaluation is a generic process that considers whether the performance of something is acceptable, value for money etc. – and whether it will be proceeded with, accepted into use, paid for, etc. Evaluation is concerned with value. Specifically, effective evaluation will establish the use made of resources in terms of delivered benefit and this information will allow a more accurate focus on value in future service development and Change Management. Objective The objective of this process is to:  Evaluate the intended effects of a service change and as much of the unintended effects as is reasonably practical given capacity, resource and organizational constraints  Provide good quality outputs from the evaluation process so that Change Management can expedite an effective decision about whether a service change is to be approved or not. Activities        

Service evaluation terms Evaluation process Evaluation plan Understanding the intended effect of a change Factors for considering the effect of a service change Evaluation of predicted performance Evaluation of actual performance Risk management • Deviations – predicted vs. actual performance • Test plan and results.

Inputs and outputs  Inputs • Service package • SDP and SAC • Test results and report  Outputs • Evaluation report for Change Management. Terminology Service Acceptance Criteria (SAC) A set of criteria used to ensure that an IT Service meets its functionality and quality requirements and that the IT Service Provider is ready to operate the new IT service when it has been deployed. Service Design Package (SDP) Document(s) defining all aspects of an IT service and its requirements through each stage of its lifecycle. A SDP is produced for each new IT service, major change, or IT service requirement. Cost     

Personnel – Release staff Accommodation – Physical location (set-up and ongoing) Software – Tools (set-up and ongoing) Hardware – Infrastructure (set-up) Education – Training (set-up and ongoing). Copyright The Art of Service Brisbane, Australia │ Email: [email protected] │Web: http://theartofservice.com │eLearning: http://theartofservice.org Phone: +61 (0)7 3252 2055

79

service transition KNOWLEDGE MANAGEMENT Why An organization’s ability to deliver a quality service or process rests, to a significant extent, on its ability to respond to circumstances. To enable this to happen, those involved must have a sound understanding of the situation, the options, consequences and benefits. An example of this knowledge in the Service Transition phase may include:  Identity of stakeholders  Acceptable risk levels and performance expectations  Available resource and timescales. The relevance and quality of the knowledge rests in turn on the accessibility, quality and continued relevance of the underpinning data and information available to service staff. Objective Knowledge Management is responsible for gathering, analyzing, storing and sharing knowledge and information within the organization to enable informed decision. The primary purpose is to improve efficiency by reducing the need to rediscover knowledge. This is achieved by:  Enabling the service provider to be more efficient and improve the quality of the service, reduce costs, increase satisfaction  Ensuring staff have a clear and shared understanding of the value that their services provide to customers and how benefits are realized  Ensuring that, as required, service provider staff have adequate information on: • Who is currently using their services • The current states of consumption • Service delivery constraints • Difficulties faced by customers in realizing the expected benefits from a service. Inputs and outputs  Inputs • Service package • SDP and SAC • Test results and report  Outputs • Evaluation report for Change Management Activities  Knowledge Management strategy – specifically Knowledge Management will identify and plan for the capture of relevant knowledge and the consequential information and data that will support it.  Knowledge transfer – this is the activity through which one unit (e.g. group or department) is affected by the experiences of another. The form of knowledge transfer must suit those who will use it, examples of criteria/examples that can be used are: • Learning styles • Knowledge visualization • Driving behavior • Seminars, webinars and advertising • Journals and newsletters.


80

service transition  Data and information management – knowledge rests on the management of the information and data that underpins it. For this process to be efficient it requires answers to some key input questions, such as how the data and information will be used, what conditions will need to be monitored, what data is available, what are the associated costs, legislative and requirements etc. • Establishing data and Information requirements • Establishing data and information management procedures • Evaluation and improvement.

Data, Information, Knowledge and Wisdom (DIKW) © Crown Copyright 2007 Reproduced under license from OGC

Terminology Service Knowledge Management System (SKMS) A set of tools and databases used to manage knowledge and information. Configuration Management System (CMS) A set of tools and databases used to manage an IT Service Provider’s configuration data. Known Error Database (KEDB) A database containing all Known Error Records. Definitive Media Library (DML) One or more locations in which the definitive and approved versions of all software configuration items are securely stored. Cost     

Personnel – Release staff Accommodation – Physical location (set-up and ongoing) Software – Tools (set-up and ongoing) Hardware – Infrastructure (set-up) Education – Training (set-up and ongoing).


81

service transition


82

service transition


83

service operation Service Operation Functions This section contains the factsheets for: • • • •

Service Desk Technical Management Applications Management IT Operations Management. IT Operations Management

Service Desk

Technical Management

Mainframe Server Network Storage Databases Directory Services Desktop

IT Operations Control Console Mgt Job Scheduling Backup & restore Print & Output

Application Management

Financial Management HR Apps

Facilities Management Data Centers Recovery Sites Consolidation Contracts

Business Apps

Middleware Internet/Web


84

service operation SERVICE DESK FUNCTION Why Cost reductions are a necessity in today's economy and internal support groups are a frequent cost reduction target. Service Desks and desktop support teams need to ensure that their services are clearly defined and aligned with business needs. 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. Objective The primary aim of the Service Desk is to restore the ‘normal service’ to the users as quickly as possible. This could involve anything that is required to allow the users to return to working satisfactorily. 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 4 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  Follow the Sun: using “round the world” service desk structure to provide 24 hour support. 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  Logging and categorizing incidents and complaints  Initial assessment of requests, attempting to resolve them or referring to someone who can, based on agreed service levels  Monitoring and escalation procedures relative to appropriate SLA  Keeping users informed of progress  Management of the full request lifecycle, including closure and verification with customer  Communicating planned changes of service levels to customers  Updating the CMS under the direction and approval of Configuration Management if so agreed. Service Desk technology  Communication technology such as Computer Telephony Integration (CTI) or Voice Over Internet Protocol (VOIP)  Interactive Voice Response systems (IVR)  E-mail, fax servers (fax via e-mail or the internet), forwarding calls to pagers, mobile phones, laptop and palmtop computers  Intranet and Internet self-service platforms  Knowledge, search and diagnostic tools  Automated operations and network management tools.


85

service operation Terminology Incident An unplanned interruption to an IT service or reduction in the quality of an IT service. Failure of a configuration item that has not yet affected service is also an incident. Request for Change (RFC) A formal proposal for a change to be made. An RFC includes details of the proposed change, and may be recorded on paper or electronically. Service Request A request from a user for information or advice, or for a standard change or for access to an IT service. Single Point of Contact (SPOC) Providing a single consistent way to communicate with an organization or business unit. Usually a Service Desk.

Cost      

Personnel – To staff the Service Desk (set-up and ongoing) Accommodation – Physical location (set-up and ongoing) Software – Tools (set-up and ongoing) Hardware – Infrastructure (set-up) Education – Training (set-up and ongoing) Procedures – External consultants etc. (set-up).


86

service operation


87

service operation


88

service operation TECHNICAL MANAGEMENT FUNCTION Why As the custodian of technical knowledge and expertise related to managing the IT Infrastructure, the Technical Management function provides technical skills and resources needed to support the ongoing operation of the IT Infrastructure. Technical Management also plays an important role in providing the resources to support the IT Service Management lifecycle. It ensures resources are effectively trained and deployed to design, build, transition, operate and improve the technology to deliver and support IT Services.

Objective To help plan, implement and maintain a stable technical infrastructure to support the organization’s business processes through:  Well designed and highly resilient, cost-effective topology  The use of adequate technical skills to maintain the technical infrastructure in optimum condition  Swift use of technical skills to speedily diagnose and resolve any technical failures that do occur.

Activities  Identifying the knowledge and expertise required to manage and operate the IT infrastructure and to deliver IT services.  Documentation of the skills that exist in the organization, as well as those that need to be developed.  Initiating training programs to develop and refine the skills in the appropriate technical resources and maintaining training records for all technical resources.  Design and delivery of training for users, the Service Desk and other groups.  Recruiting or contracting resources with skills that cannot be developed internally, or where there are insufficient people to perform the required Technical Management activities.  Procuring skills for specific activities where the required skills are not available internally or in the open market, or where it is more cost-effective to do so.  Research and development of solutions which can be used to simplify, automate or reduce costs.  Modeling and workload forecasting.

Cost      



89

service operation


90

service operation


91

service operation IT OPERATIONS MANAGEMENT FUNCTION Why IT Operations is the function responsible for the daily operational activities needed to manage the IT Infrastructure. This is done according to the performance standards defined during Service Design. In some organizations this is a single, centralized department, while in others some activities and staff are centralized and some are provided by distributed and specialized departments.

Objective  Maintenance of the status quo to achieve stability of the organization’s day-to-day processes and activities  Regular scrutiny and improvements to achieve improved service at reduced costs, while maintaining stability  Swift application of operational skills to diagnose and resolve any IT operations failures that occur.

Activities IT Operations Managements has two unique functions, which are usually organized in the following structure: Operations Control: oversees the execution and monitoring of the operational activities and events in the IT infrastructure. E.g. console management, job scheduling, backup and restore, print and output management, and maintenance activities. Facilities Management: management of the physical IT environment, usually data centers or computer rooms. In some organizations, many physical components have been outsourced and Facilities Management may include the management of the outsourcing contracts. E.g. data centers, recovery sites, and contracts etc.

Cost      



92

service operation


93

service operation


94

service operation APPLICATION MANAGEMENT FUNCTION Why Applications Management is responsible for managing Applications throughout their lifecycle. By supporting and maintaining operational applications, Applications Management plays an important role in design, testing and improvement of applications that part form of IT Services.

Objective This function plays a key role in identifying functional and manageability requirements for application software, and deciding whether an application will be built in-house or purchased from an external source. Working side by side with Technical Management, Applications Management ensures the knowledge required to design, test, manage and improve IT services is identified, developed and refined. By performing this role Application Management is able to ensure that the organization has access to the right type and level of human resources to manage applications and therefore meet business objectives. This starts in Service Strategy and is expanded in Service Design, tested in Service Transition and refined in Continual Service Improvement.

Activities While most Application Management teams or departments are dedicated to specific applications or sets of applications, there are a number of activities which they have in common e.g.:  Identifying the knowledge and expertise required to manage and operate applications in the delivery of IT services.  Initiating training programs to develop and refine the skills in the appropriate Application Management resources and maintaining records for these resources.  Recruiting or contracting resources with skills that cannot be developed internally, or where there are insufficient numbers of staff to perform the required activities.  Design and delivery of end-user training.  Research and development of solutions that can help expand the Service Portfolio  Ensuring all system documentation is up to date and complete and that relevant staff are familiar with the contents etc.

Cost      



95

service operation


96

service operation


97

service operation Service Operation Processes This section contains the factsheets for:     

Event Management Incident Management Request Fulfillment Problem Management Access Management.

This page has been intentionally left blank


98

service operation EVENT MANAGEMENT Why An event can be defined as any detectable or discernable occurrence that has significance for the management of the IT Infrastructure or the delivery of IT service and evaluation of the impact a deviation might cause to the services. Events are typically notifications created by an IT service, Configuration Item (CI) or monitoring tool. Effective Service Operation is dependent on knowing the status of the infrastructure and detecting any deviation from normal or expected operation. This is provided by good monitoring and control systems, which are based on two types of tools:  Active monitoring tools that poll key CIs to determine their status and availability. Any expectations will generate an alert that needs to be communicated to the appropriate tool or team for action; and  Passive monitoring tools that detect and correlate operational alerts or communications generated by CIs. Objective The objective of Event Management is to provide the entry point for the execution of many Service Operation processes and activities. In addition, it provides a way of comparing actual performance and behavior against design standards and SLAs. Inputs and outputs  Interface with business applications and/or business processes to allow potentially significant business events to be detected and acted upon.  The primary ITSM relationships are with Incident, Problem and Change Management.  Capacity and Availability Management are critical in defining what events are significant, what appropriate thresholds should be and how to respond to them.  Configuration Management is able to use events to determine the current status of any CI in the infrastructure.  Asset Management can use Event Management to determine the lifecycle status of assets.  Events are a rich source of information that can be processed to inclusion in Knowledge Management systems. Activities  Event Occurs – Events occur continuously, but not all of them are detected or registered. It is therefore important that everybody involved in designing, developing, managing and supporting IT services and the IT infrastructure that they run on understands what kind of events need to be detected.  Event Notification – Most CIs are designed to communicate certain information about themselves in one of two ways: • A device is interrogated by a management tool, which collects certain targeted data. This is often called polling. • The CI generates a notification when certain conditions are met. The ability to produce these notifications has to be designed and built into the CI, for example, a programming hook inserted into an application.  Event Detection – Once an Event notification has been generated, it will be detected by an agent running on the same system, or transmitted directly to a management tool specifically designed to read and interpret the meaning of the event.  Event Filtering – The purpose of filtering is to decide whether to communicate the event to a management tool or to ignore it. If ignored, the event will usually be recorded in a log file on the device, but no further action will be taken.


99

service operation  Significance of Events – Every organization will have its own categorization of the significance of an event, but it is suggested that at least these three broad categories be represented: • Informational: This refers to an event that does not require any action and does not represent an exception. They are typically stored in the system or service log files and kept for a predetermined period. • Warning: A warning is an event that is generated when a service or device is approaching a threshold. Warnings are intended to notify the appropriate person, process or tool so that the situation can be checked and appropriate action taken to avoid an exception. • Exception: An exception means that a service or device is currently operating abnormally. Typically this means that an OLA or SLA has been breached and the business has been impacted. Exceptions could represent a total failure, impaired functionality or degraded performance.  Event Correlation – If an event is significant, a decision has to be made about exactly what the significance is and what actions need to be taken to deal with it. It is here that the meaning of the event is determined.  Trigger – If the correlation activity recognizes an event, a response will be required. The mechanism used to initiate that response is also called a trigger. There are many different types of triggers, each designed specifically for the task it has to initiate. Some examples could include: • Incident triggers that generate a record in the Incident Management system. • Change Triggers that generate an RFC • Scripts that execute specific actions • Paging systems that will notify a person or team of an event via mobile phone • Database triggers that restrict access of a user to specific records or fields, or that create or delete entries in the database.  Response Selection – At this point of the process, there are a number of response options available: • Event logged – There will be a record of the event and any subsequent actions. • Auto response –The trigger will initiate the action and then evaluate whether it was completed successfully. If not, an Incident or Problem Record will be created. Examples of auto responses include: rebooting a device, restarting a service, locking a device or application to protect it against unauthorized access. • Alert and human intervention – If the event requires human intervention, it will need to be escalated. The purpose of the alert is to ensure that the person with the skills appropriate to deal with the event is notified. The alert will contain all the information necessary for the person to determine the appropriate action. • Incident, problem or change? – Some events will represent a situation where the appropriate response will need to be handled through the Incident, Problem or Change Management process. • Open an RFC – There are two places in the Event Management process where an RFC can be created: o When an exception occurs o Correlation identifies that a change is needed. • Open an Incident Record – As with an RFC and incident can be created as soon as an exception is detected, or when the correlation engine determines that a specific type or combination of events represents an incident. • Open or link to a Problem Record – It is rare for a Problem Record to be opened without related incidents. In most cases this step refers to linking an incident to an existing Problem record. This will assist the Problem Management teams to reassess the severity and impact of the problem, and may result in a changed priority to an outstanding problem. • Special types of incident – In some cases an event will indicate an exception that does not directly impact any IT Service e.g. unauthorized entry to a data centre. In this case the incident will be logged using an Incident Model that is appropriate for this type of exception e.g. a Security Incident.


100

service operation

 Review Actions – As thousands of events are generated on a daily basis, it is not possible to review every one. However, it is important to check that any significant events or exceptions have been handled appropriately, or to track trends or counts of event types, etc. In many cases this can be done automatically.  Close Event - Some events will remain open until a certain action takes place, for example an event that is linked to an open incident. However, most events are not ‘opened’ or ‘closed’. Informational events are simply logged and then used as input to other processes, such as Backup and Storage Management. Auto-response events will typically be closed by the generation of a second event.

Event Management activities

Terminology Event A change of state that has significance for the management of a configuration item or IT service. Trigger An indication that some action or response to an event may be needed. Alert A warning that a threshold has been reached, something has changed, or a failure has occurred.

Cost      

Personnel – Support staff (set-up and ongoing) Accommodation – Physical location (set-up and ongoing) Software – Tools (set-up and ongoing) Hardware – Infrastructure (set-up) Education – Training (set-up and ongoing) Procedures – External consultants etc. (set-up).


101

service operation


102

service operation


103

service operation INCIDENT MANAGEMENT Why While efficiencies can be made from process improvement (e.g. outsourcing and staff reductions), mechanisms need to be in place to determine baselines and ongoing measurements of performance. Fundamental evolution from a reactive help desk support model, to a consolidated IT service desk with Incident Management, brings the need to demonstrate the value of service quality. That 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. Inputs and outputs The interfaces with Incident Management include:  Problem Management  Configuration Management  Change Management  Capacity Management  Availability Management  SLM. Activities Incident identification and logging (Service Desk responsibility)  Record basic details of the incident  Alert specialist support group(s) as necessary. Categorization, prioritization and initial diagnosis  Categorize 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 workaround) or a route to in-line support.  Functional or hierarchical escalation where necessary Resolution and recovery  Resolve the incident using the solution/workaround or, alternatively, to raise an RFC (including a check for resolution)  Take recovery actions.


104

service operation 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 service operation • 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.  Note – Service Requests and Major Incidents have their own process.

Results A structured, consistent approach to Incident Management ensuring effective and efficient handling of incidents in line with SLAs.


105

service operation Terminology Incident An unplanned interruption to an IT service or a reduction in quality of an IT service. Functional Escalation Transferring an incident, problem or change to a technical team with a higher level of expertise to assist in an escalation. Hierarchic Escalation Informing or involving more senior levels of management to assist in an escalation. Workaround Reducing or eliminating the impact of an incident or problem for which a full resolution is not yet available.

Cost      

st

nd

rd

Personnel – To resolve issues at 1 , 2 , 3 level support Accommodation – Physical location Software – Tools Hardware – Infrastructure Education – Training Procedures – To educate external consultants, etc.


106

service operation


107

service operation


108

service operation REQUEST FULFILLMENT Why Request Fulfillment is the process for dealing with Service Requests – many of them actually smaller, lowerrisk changes – initially reported to the Service Desk. For something to be a Service Request, some prerequisites must be defined and met. E.g. it needs to be proven, repeatable, pre-approved, and made into a procedure. In order to resolve one or more incidents, problems or known errors, some form of change may be necessary. Smaller, often standard changes can be handled through a Request Fulfillment process, but larger, higher-risk or infrequent changes must go through a formal Change Management process. Objective Request Fulfillment is the process of dealing with Service Requests from the users. The objectives of the Request Fulfillment process are:  To provide a channel for users to request and receive standard services for which a pre-defined approval qualification process exists  To provide information to users and customers about the availability of services and the procedure for obtaining them  To source and deliver the components of requested standard services (e.g. licenses and software media)  To assist with general information, complaints or comments. Inputs and outputs The primary interfaces with Request Fulfillment are:  Service Desk/Incident Management  Asset Management, Release Management and Configuration Management. Activities  Menu selection – Request Fulfillment offers great opportunities for self-help practices where users can generate a Service Request using technology links into Service Management tools. Ideally, users should be offered a ‘menu’-type selection via a web interface, so that they can select and input details of Service Requests from a pre-defined list.  Financial approval – One important step that is likely to be needed when dealing with a service request is that of financial approval. Most requests will have some form of financial implications, regardless of the type of commercial arrangements in place. The cost of fulfilling the request must first be established. It may be possible to agree fixed prices for ‘standard’ requests – and prior approval for such requests may be given as part of the organization’s overall annual financial management. In all other cases, an estimate of the cost must be produced and submitted to the user for financial approval. If approval is given, in addition to fulfilling the request, the process must also include charging for the work done – if charging is in place.  Other approval – In some cases further approval may be needed – such as compliance related or wider business approval. Request Fulfillment must have the ability to define and check such approvals where needed.  Fulfillment – The actual fulfillment activity will depend upon the nature of the Service Request. Some simpler requests may be completed by the Service Desk, acting as the first-line support, while others have to be forwarded to specialist groups and/or suppliers for fulfillment. Some organizations may have specialist fulfillment groups, or they may outsource some fulfillment activities to a third party supplier. The Service Desk will monitor and chase progress and keep users informed throughout, regardless of the actual fulfillment source.  Closure – When the Service Request has been fulfilled it must be referred back to the Service Desk for closure. The Service Desk will check that the user is satisfied with the outcome.


109

service operation Cost      



110

service operation


111

service operation


112

service operation PROBLEM MANAGEMENT Why The fact that computers are now an omnipresent element of most organizations’ infrastructure has lead to the requirement to fully optimize their use. End-users will face issues in their use of computer systems. In ITIL terms we refer to these as incidents. A pattern of incidents is a problem. 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 objective 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. Inputs and outputs The primary relationship is between Problem Management and Incident Management. Other key interfaces include the following:  Service Transition • Change Management • Configuration Management • Release and Deployment Management  Service Design • Availability Management • Capacity Management • IT Service Continuity  Continual Service Improvement • Service Level Management  Service Strategy • Financial Management. Activities Problem Management consists of two major processes: Reactive Problem Management: generally executed as part of Service Operation. Proactive Problem Management: initiated in Service Operation, but generally driven as part of Continual Service Improvement.


113

service operation The activities are:  Problem detection and logging • Use incident guidelines for problem identification • Log all relevant details of a problem so that a full historic record exists • Other processes (e.g. Availability, Security) could log problems prior to incident occurring.  Problem categorization and prioritization • Categorize the problem by functional areas of the IT organization • Assess urgency frequency and impact to assign priority.  Problem Investigation and Diagnosis • Assign to IT functional area for further investigation • Apply appropriate level of resources and expertise to find a resolution proportionate to priority level.  Workarounds and raising a Known Error Record • In cases where a workaround is found, it is important that the problem record remains open, and details of the workaround are always documented within the Problem Record. • As soon as the diagnosis is complete, and particularly where a workaround has been found (even though it may not be a permanent resolution), a Known Error Record must be raised and placed in the KEDB – so if further incidents or problems arise, they can be identified and the service restored more quickly.  Problem resolution • Problem record closed when known error located and workaround identified.  Problem closure • Problem record closed when known error located and workaround identified.  Major Problem Review and errors detected in the development environment. After every major problem, while memories are still fresh, a review should be conducted to learn any lessons for the future. Specifically the review should examine: • Those things that were done correctly • Those things that were done wrong • What could be done better in the future • How to prevent recurrence • Whether there has been any third-party responsibility and whether follow-up actions are needed.

service operation

Such reviews can be used as part of training and awareness activities for staff – any lessons learned should be documented in appropriate procedures, working instructions, diagnostic scripts or Known Error Records.


114

service operation Terminology Problem A cause of one or more incidents. The cause is not usually known at the time a problem record is created. Known Error A problem that has a documented root cause and a workaround. Workaround Reducing or eliminating the impact of an incident or problem for which a full resolution is not yet available. Proactive Problem Management The objective of Proactive Problem Management is to identify problems that might otherwise be missed.

Results  Accurate workaround database  Accurate overview of Known Errors  Insight into weak areas in the IT infrastructure  More proactive service support  Bridging Incident Management and Change Management  Decrease in support cost because of better IT staff allocation.

Cost      



115

service operation


116

service operation


117

service operation ACCESS MANAGEMENT Why Access Management is the process of granting authorized users the right to use a service, while preventing access to non-authorized users. Objective Access Management provides the right for users to be able to use a service or group of services. It is therefore the execution of policies and actions defined in Information Security and Availability Management. It enables the organization to manage the confidentiality, availability and integrity or the organization’s data and intellectual property. Access Management can be initiated by a Service Request through the Service Desk. Inputs and outputs  Inputs • Human Resources • Change Management • Information Security Management • Service Level Management  Outputs • Configuration Management. Activities  Requesting Access – Access can be requested using one or any number of mechanisms e.g.: • A Standard Request • A Request for Change • A Service Request (submitted via the Request Fulfillment system) • Executing a pre-authorized script or option. Rules for requesting access are normally documented as part of the Service Catalogue.  Verification – Access Management needs to verify every request for access to an IT service from two perspectives: • That the user requesting access is who they say they are. • That they have a legitimate requirement for that service.  Providing Rights – Access Management does not decide who has access to which IT Services. Access Management executes the policies and regulations defined during Service Strategy and Service Design. Access Management enforces decisions to restrict or provide access, rather than making the decision. As soon as a user is verified, Access Management will provide that user with rights to use the requested service. In most cases this will result in a request to every team or department involved in supporting that service to take the necessary action. Ideally, these tasks should be automated.  Monitoring identity status – As users work in the organization, their roles change as do their needs to access services e.g. job changes, promotions/demotions, resignation or death etc. Access Management should understand and document the typical User Lifecycle for each type of user and use it to automate the process. Access Management tools should provide features that enable a user to be moved from one state to another or from one group to another, easily and with an audit trail.  Logging and tracking access – Access Management should not only respond to requests. It is also responsible for ensuring that the rights that they have provided are being properly used. Information Security Management plays a vital role in detecting unauthorized access and comparing it with the rights that were provided by Access Management. Access Management may also be required to provide a record of access for specific services during forensic investigations. If a user is suspected of breaches of policy, inappropriate use of resources, or fraudulent use of data, Access Management may be required to provide evidence of dates, times and even content of that user’s access to specific services. Copyright The Art of Service Brisbane, Australia │ Email: [email protected] │Web: http://theartofservice.com │eLearning: http://theartofservice.org Phone: +61 (0)7 3252 2055

118

service operation  Removing or restricting rights – Just as Access Management provides rights to use a service, it is also responsible for revoking those rights. Again, this is not a decision that it makes on its own. Access Management will execute the decisions and policies made during Service Strategy and Design and also decisions made by managers within the organization. Removing access is usually done in the following circumstances: • Death; • Resignation; • Dismissal; or • User has changed roles etc.

Terminology Identity A unique name that is used to identify a user, person or role. The identity is used to grant rights to that user, person or roles. Rights Entitlements, or permissions, granted to a user or role. For example, the right to modify particular data or to authorize a change. Directory Service An application that manages information about IT infrastructure available on a network, and corresponding user access rights.

Cost      



119

service operation


120

service operation


121

csi CSI Processes This section contains the factsheets for:  The 7-Step Improvement Process  Service Measurement and Reporting

This page has been intentionally left blank


122

csi THE 7-STEP IMPROVEMENT PROCESS Fundamental to Continual Service Improvement is the concept of measurement. CSI uses the 7-Step Improvement Process.

At the beginning of the Service Lifecycle, Service Strategy and Service Design will identify this information. Continual Service Improvement uses this information to find where we are now and identify the ideal situation for both business and IT.

Note: Steps one and two specifically relate to the Service Strategy and Service Operation phase objectives, which have been agreed for measuring services and service management processes. Steps one and two are also consistently reviewed during the other steps as issues arise. In the past, these two steps have often been overlooked. This is because with the constantly changing and hectic environment, people gather data before asking what should be collected and for what purpose. Another reason is that in general when it comes to IT, the IT organization assumes they know what’s best for their customer. However, the reality is that the IT organization and the customer have not met to discuss what should be measured or what the purpose is of gathering data in the first place. It is essential that detailed agreements with regards to measurement and reporting requirements are recorded within the SLA to avoid customer dissatisfaction issues.

Identify Vision Strategy • Tactical Goals • Operational Goals

1. Define what you should measure

7. Implement corrective action

2. Define what you can measure Goals

3. Gather the data Who? How? When? Integrity of data?

6. Present and use the information, assessment summary, action plans, etc.

5. Analyze the data Relations? Trends? According to plan? Targets met? Corrective action?

4. Process the data Frequency? Format? System? Accuracy?

The 7-Step Improvement Process © Crown Copyright 2007 Reproduced under license from OGC


123

csi Step One - Define what you should measure Talk to the business, find out what your customer’s needs are and discuss with IT Management how those needs can be met. The Service Catalogue is a customer-facing tool that can be used in discussion with customer’s service level requirements.

Step Two – Define what you can measure Each organization has limitations on what it can measure. If you cannot measure something then, it should not appear in an SLA. Identify what tools you have in place to measure, and what they actually do measure.

Step Three – Gathering the data This requires you having some form of monitoring in place, through various tools. If quality is the key objective, then monitoring should focus on the effectiveness of the data you are gathering. Define who is gathering data, how it is gathered, regularity of data gathered, and the integrity of the data.

Step Four – Processing the data This step is used to develop insight into the performance of the service/process. Using report generating technologies, key issues include frequency of processing data, format for output, and accuracy of data.

Step Five – Analyzing the data Data Analysis transforms the information gathered into useable knowledge. Verification against goals and objectives is expected here to validate objectives and that value is being added.

Step Six – Presenting and using the information This step required you to turn your knowledge into wisdom by utilizing reports, graphs etc. Through a consideration of the audience (Business, Senior IT Mgt, Internal IT), information is shared so that all levels can gain insight into their needs and expectation.

Step Seven – Implementing corrective action The last step requires you to use the knowledge gained to optimize, improve and correct services, as part of its CSI process.


124

csi


125

csi


126

csi SERVICE MEASUREMENT AND REPORTING Why Service Measurement is the process responsible for defining how to measure IT Service Management and IT Service improvements. Service Measurement co-ordinates the data collection for measurements from the other processes and functions. There are four main reasons to monitor and measure:  To validate  To direct  To justify  To intervene. Service Measurement is a key concept of Continual Service Improvement. Measurement of all the process metrics takes place throughout the Lifecycle phases. Continual Service Improvement uses the results of these measurements to identify and establish improvements. A lot of data is collated and measured by IT, however only a small subset is of real interest and importance to the business. This is where reporting comes into play.

Objective For all types of organizations, IT services have become an essential means for conducting business and staying competitive in today’s market. As we become more reliant on these IT services our expectations for availability, reliability and stability increase too. This is why it is essential to have a structured bridge that aligns the business with IT and allows for integration. In alliance with this strategy, Service Measurement and Reporting must also develop to measure and report against the entire service lifecycle, as opposed to focusing against the performance of an individual component.

The Continual Service Improvement Model © Crown Copyright 2007 Reproduced under license from OGC


127

csi Terminology Baseline A benchmark used as a reference point e.g.:  An ITSM Baseline can be used a starting point to measure the effect of a SIP.  A Performance Baseline can be used to measure changes in performance over the lifetime of an IT service.  A Configuration Management Baseline can be used to enable the IT infrastructure to be restored to a known configuration if a change or release fails. Metric Something that is measured and reported to help manage a process, IT service or activity.

Cost      



128

csi


129

csi


130

glossary GLOSSARY Alert A warning that a threshold has been reached, something has changed, or a failure has occurred. Alerts are often created and managed by System management tools and are managed by the Event Management process. Application Sizing The activity responsible for understanding the resource requirements needed to support a new application, or a major change to an existing application. It helps to ensure that the IT Service can meet its agreed Service Level Targets for capacity and performance. Asset Any resource or capability. Assets of a Service Provider include anything that could contribute to the delivery of a service. Baseline A benchmark used as a reference point. Configuration Item (CI) Any component that needs to be managed in order to deliver an IT Service. Configuration Management Database (CMDB) A database used to store Configuration Records throughout their lifecycle. Configuration Management System (CMS) A set of tools and databases that are used to manage an IT Service Provider’s configuration data. DML Definitive Media Library. Function A team or group of people and the tools they use to carry out one or more processes or activities. Incident An unplanned interruption to an IT service, or a reduction in the quality of an IT service. Failure of a configuration item that has not yet impacted service is also an incident. Known Error A problem that has a documented root cause and a workaround. KEDB Known Error Database. Maintainability A measure of how quickly and effectively a CI or IT service can be restored to normal after a failure. Maintainability is often measured and reported as MTRS. Modeling A technique used to predict the future behavior of a system, process, IT service, CI etc. MTBF Mean Time Between Failures (Uptime).


131

glossary MTBSI Mean Time Between Service Incidents. MTRS Mean Time to Recover Service (Downtime). Operational Level Agreement (OLA) An agreement between an IT Service Provider and another part of the same organization. An OLA supports the IT Service Provider’s delivery of IT services to customers. The OLA defines the goods and services to be provided and the responsibilities of both parties. Process A structured set of activities designed to accomplish a specific objective. Process Owner Role responsible for ensuring that a process is fit for purpose. Remediation Recovery to a known state after a failed Change or Release. Request for Change (RFC) A formal proposal for a change to be made. An RFC includes details of the proposed change, and may be recorded on paper or electronically. Service A means of delivering value to customers by facilitating outcomes customers want to achieve without the ownership of specific costs and risks. Service Owner A role that is accountable for the delivery of a specific IT service. Service Assets Any capability or resource of a service provider. Serviceability Measures Availability, Reliability, Maintainability of IT services/CIs under control of external suppliers. Service Improvement Plan (SIP) A formal plan to implement improvements to a process or IT service. Service Knowledge Management System (SKMS) A set of tools and databases that are used to manage knowledge and information. The SKMS includes the Configurations Management System, as well as other tools and databases. Service Level Agreement (SLA) An agreement between an IT Service Provider and a customer. The SLA describes the IT service, documents Service Level Targets, and specifies the responsibilities of the IT Service Provider and the customer. Service Level Management (SLM) The process responsible for negotiating Service Level Agreements and ensuring these are met. SLM is also responsible for ensuring that all IT Service Management processes, OLAs and underpinning contracts are appropriate for the agreed Service Level Targets.


132

glossary Service Level Requirements (SLR) A customer requirement for an aspect of an IT service. SLRs are based on business objective and are used to negotiate Service Level Targets. Status Accounting Reporting of all current and historical data about each CI throughout its lifecycle. Supplier and Contracts Database (SCD) A database or structured document used to manage supplier contracts throughout their lifecycle. Service Improvement Plan (SIP) A formal plan to implement improvements to a process or IT service. Trigger An indication that some action or response to an event may be needed. Tuning The activity responsible for planning changes to make the most efficient use of resources. Tuning is part of Performance Management, which also includes performance monitoring and implementation of the required changes. Underpinning Contract (UC) A contract between an IT Service Provider and a third party. The third party provides goods or services that support delivery of an IT service to a customer. The UC defines targets and responsibilities that are required to meet agreed Service Level Targets in an SLA. Utility Functionality offered by a product or service to meet a particular need. Often summarized as ‘what it does’. Vital Business Function (VBF) A function of a business process that is critical to the success of the business. VBFs are an important part of Business Continuity Management, IT Service Continuity Management and Availability Management. Warranty A promise or guarantee that a product or service will meet its agreed requirements.


133

The ITIL V3 Factsheet Benchmark Guide: An Award-Winning ITIL Trainers Tips On Achieving ITIL V3 And ITIL Foundation Certification For ITIL Service Management, Second Edition

IT-Management mit ITIL® V3

ITIL V3 Foundation Exam The Study Guide

Service strategy (ITIL)

Continual Service Improvement (ITIL)

Service Operation Book (ITIL)

Service Transition (ITIL)

Service Design (ITIL)

Acheter des services informatiques avec ITIL v3

ITIL Capacity Management

ITIL IT Service Management - 100 Most Asked Questions on IT Service Management and ITIL Foundation Certification, Training and Exams

Prozesse optimieren mit ITIL

ITIL Release Management: A Hands-on Guide

ITIL Security Management realisieren GERMAN

The ITIL V3 Service Management Awareness Pocket Guide - The ITIL V3 Pocket Toolbook: A Quick Reference Guide to all the processes and activities for Improving Quality and Speed

IT-Management mit ITIL® V3: Strategien, Kennzahlen, Umsetzung

ITIL V3 Foundation Complete Certification Kit - 2009 Edition: Study Guide Book and Online Course

Service Transition Based on ITIL: A Management Guide

ITIL (Informatik im Fokus) GERMAN

ITIL V3 Release, Control and Validation (RCV) Full Certification Online Learning and Study Book Course - The ITIL V3 Intermediate RCV Capability Complete Certification Kit

Foundations of IT Service Management Based on ITIL, Volume 3

Foundations of IT Service Management: Based on ITIL Arabic

Effective IT Service Management: To ITIL and Beyond!

Effective It Service Management: To Itil and Beyond!

Effective IT Service Management To ITIL and Beyond!

Prozesse optimieren mit ITIL, 2.Auflage

ITIL V3 capability module operational support and analysis : exam prep study guide : how to pass on your first try : ensure your ITIL certification now with study notes and ITIL practice questions & exam tips

ITIL V3 Foundation Bridge Certification Exam Preparation Course in a Book for Passing the ITIL V3 Foundation Bridge Exam - The How To Pass on Your First Try Certification Study Guide

The Introduction to the ITIL Service Lifecycle Book

Овладевая ITIL. Скептическое руководство для ответственных лиц

ITIL Service Manager Exam Preparation Course in a Book for Passing the ITIL Service Managers V2 Exam - The How To Pass on Your First Try Certification Study Guide

The ITIL V3 Factsheet Benchmark Guide: An Award-Winning ITIL Trainers Tips On Achieving ITIL V3 And ITIL Foundation Certification For ITIL Service Management, Second Edition

IT-Management mit ITIL® V3

ITIL V3 Foundation Exam The Study Guide

Service strategy (ITIL)

Continual Service Improvement (ITIL)

Service Operation Book (ITIL)

Service Transition (ITIL)

Service Design (ITIL)

Acheter des services informatiques avec ITIL v3

ITIL Capacity Management

ITIL IT Service Management - 100 Most Asked Questions on IT Service Management and ITIL Foundation Certification, Training and Exams

Prozesse optimieren mit ITIL

ITIL Release Management: A Hands-on Guide

ITIL Security Management realisieren GERMAN

The ITIL V3 Service Management Awareness Pocket Guide - The ITIL V3 Pocket Toolbook: A Quick Reference Guide to all the processes and activities for Improving Quality and Speed

IT-Management mit ITIL® V3: Strategien, Kennzahlen, Umsetzung

ITIL V3 Foundation Complete Certification Kit - 2009 Edition: Study Guide Book and Online Course

Service Transition Based on ITIL: A Management Guide

ITIL (Informatik im Fokus) GERMAN

ITIL V3 Release, Control and Validation (RCV) Full Certification Online Learning and Study Book Course - The ITIL V3 Intermediate RCV Capability Complete Certification Kit

Foundations of IT Service Management Based on ITIL, Volume 3

Foundations of IT Service Management: Based on ITIL Arabic

Effective IT Service Management: To ITIL and Beyond!

Effective It Service Management: To Itil and Beyond!

Effective IT Service Management To ITIL and Beyond!

Prozesse optimieren mit ITIL, 2.Auflage

ITIL V3 capability module operational support and analysis : exam prep study guide : how to pass on your first try : ensure your ITIL certification now with study notes and ITIL practice questions & exam tips

ITIL V3 Foundation Bridge Certification Exam Preparation Course in a Book for Passing the ITIL V3 Foundation Bridge Exam - The How To Pass on Your First Try Certification Study Guide

The Introduction to the ITIL Service Lifecycle Book

Овладевая ITIL. Скептическое руководство для ответственных лиц

ITIL Service Manager Exam Preparation Course in a Book for Passing the ITIL Service Managers V2 Exam - The How To Pass on Your First Try Certification Study Guide

Recommend Documents