Slide 1

ITIL V3 Foundation Program

Conducted By: Pulak Kumar Bhagat

Slide 2

Program Objectives
Overview of the topics defined in the best

practices framework for IT Service Management

Explain & discuss ITIL framework

The theory The language, the concepts, the lifecycle

Prepare participants for the exam

INTRO We will explain and engage in discussion on the:

Theory, Language, Lifecycle, Concepts

Of ITIL v3 as it pertains to the set requirements to enable you to prepare yourselves for the certification exam.

Slide 3

Learning Approach
Theory

Exercises
Fact sheets Mock tests

Slide 4

ITIL v3 Foundation Syllabus

Module 1:
ITIL Background ITIL Qualification Scheme Service Management as a Practice Generic concepts & definitions Service Lifecycle Roles definitions Technology & Architecture

Module 2:

Service Strategy
Overview Key Principles & Models Processes

Module 3:
Service Design
Overview Key Principles & Models Processes

Slide 5

ITIL v3 Foundation Syllabus

Module 4:
Service Transition
Overview Key Principles & Models Processes

Module 5:
Service Operation
Overview Key Principles & Models Processes Functions

Module 6:
Continual Service Improvement
Overview Key Principles & Models Processes

Module 7:
Mock Exam

Slide 6

ITIL Background
First published mid-1980s V2 mid 1990s Focus on Business Alignment V3 2007 Focus on Business Integration v3 Builds on the 10 processes and 1 function defined in v2 Owner: Office of Government Commerce (OGC) Published by The Stationary Office (TSO)

NOT a Public Domain Framework

Copyright and Trademark protected

Slide 7

Service Management as a Practice

ITIL v3 as Good Practice
Critique: Partially good practice Requirement: Complete Good Practice can be appropriate Organizations should adopt and adapt Not Standards, just the guidelines

Evolution
Continuous search for improvement

What is Best Practice? The approach to an undertaking that has already been proved to be the most effective. It is derived from the practices of the most effective and successful people in the field. Good Practice ITIL v3 is promoted as good practice (or what everybody should do). Perhaps the term common practice could be used if all companies in an industry adopt the same standards and practices. Evolution There is a continuous search for improvement. FIGURE: Best practices becomes good practices, becomes commodity, generally accepted principles, received wisdom, or regulatory requirements. Some organizations in an industry get ahead, because of their adoption or even development of best practice. Over time, others in the industry adopt the same practice or else go out of business. Once the common practice is in place then the industry operates in a state of good practice.

Slide 8

Service & Service Management

What is a Service?
A means of delivering value to customers by facilitating outcomes that they want to achieve without the ownership of specific costs and risks -ITIL v3 Service Strategy

What is Service Management?

A set of specialized organizational capabilities for providing value to customers in the form of services - ITIL v3 Service Strategy 'Services may be defined by specifications, but Customers outcomes are the genesis of services' Service = Outcomes Not Resources

Service In IT Service Management (ITIL v3), the customer is anybody that makes use of a (IT) service to achieve their own outcomes, and can be a commercial customer of the business or the business itself. Note the difference between a customer and a user basically the customer PAY (directly or indirectly) for the service on behalf of the user. A customer can also be a user. Facilitate outcomes: Enhance the performance of associated tasks & reduce the effect of constraints Result is an increase in the probability of desired outcomes Effect may be: Directly on resources & capabilities associated with the task & constraints Performance of a customer task e.g. business process Note: Broadly speaking, services facilitate outcomes by enhancing the performance and by reducing the grip of constraints.

Slide 9

Service Assets

Capabilities

Resources A9 A8 A7 A6

A1 Management Financial capital A2 Organization Infrastructure A3 Processes Applications A4 Knowledge Information People A5 People

Organizations use them to create value in the form of goods and services.

Slide 10

Service Value

Slide 11

Four Ps of Service Management

Slide 12

Role of IT Governance

Enterprise governance:

Considers the whole picture - ensure that strategic goals are aligned & good management is achieved

Corporate governance: Promoting corporate fairness, transparency & accountability

IT governance: Responsibility of the board of directors & executive management

Integral part of enterprise governance & consists of the leadership, organizational structures and processes that ensure that the organizations IT sustains and extends the organizations strategies and objectives

Slide 13

Quality : Deming's Circle

In the Deming PDCA cycle Workers PLAN preventive measures by finding the causes of variations Managers and workers cooperatively DO the plans, CHECK by observing the results, and ACT by analyzing the results, noting the lessons learned and the predictions made. Quality Circle is participatory management technique that uses statistical analysis of activities to maintain quality products or services. Improve quality (and) you automatically improve productivity. You capture the market with lower price and better quality. You stay in business and you provide jobs. Its so simple. -- W. Edwards Deming.

Slide 14

Gartner Group Maturity Model

Gartner Group Maturity Model helps understand how can service organization move from firefighting to provide the value to organization It says that the organizations IT will usually start with firefighting and then will slowly mature to provide value.

Slide 15

Processes, Roles & Functions

Processes:
A set of coordinated activities - combining & implementing resources and capabilities - in order to produce an outcome - which directly or indirectly, creates value - for the external customer or stakeholder

Functions provide structure and stability to organizations Processes:

Functions provide structure and stability to organizations

Role:
A set of responsibilities - defined in a process - and assigned to a person or team One person or team may have multiple roles

Functions:
Units of organizations - specialized to perform certain types of work - and be responsible for specific outcomes

Structured activity set to accomplish a specific objective Turns one or more inputs into defined outputs Roles, responsibilities, tools & management controls Policies, standards, guidelines, activities, processes, procedures & work instructions

Slide 16

Process Model

The Process Model

Process Model

The generic process elements show:

data enters is processed is output the outcome is measured & reviewed

This basic description underpins any process description. A process is always organized around a set of objectives. The main outputs should be driven by the objectives & should include process metrics, reports & improvement recommendations. A process should have a process owner, responsible that a process meets its objectives and for ensuring its improvement. A process can span organizational and geographic boundaries, often in complex variants creating unique designs and patterns of execution.

Slide 17

Process Characteristics
They are Measurable

They have Specific Results

Processes have Customers They respond to specific events

Processes help to organize work - they are aligned to activity and output, but not necessarily to value. Processes are not strategic - You have to know what you want to achieve or assume that the customer does. CHARACTERISTICS Measurable: Because a process is performance driven, it can be measured in a relevant manner. Managers measure cost, quality and other variables Practitioners are concerned with duration and productivity Processes have specific results A process exist to deliver a specific result(s) that must be individually identifiable and countable. E.g. we can count changes, it is impossible to count how many service desks were completed (Service desk is a function) Processes deliver to customers A process primary results are delivered to a customer or stakeholder, who could be internal or external to the organization, but the process must meet their expectations. Processes respond to a specific event Whether a process is ongoing or iterative, it should be traceable to a specific trigger.

Slide 18

Service Model
Service models describe the structure and dynamics of a service

Service Model Facilitates collaboration & communication in the service life cycle

Slide 19

RACI Model
RACI
Responsible Those responsible to do the task Accountable Only 1 person Consulted Those who are consulted Informed Those informed on progress

RACI-VS
Verifies Those checking if acceptance criteria was met Signs off - Person that approves the V decision (could be the A person)

RASCI
Supportive - Additional resources (supportive role)

The RACI model will be beneficial in enabling decisions to be made with pace and confidence. It clarifies to all involved which activities they are expected to fulfill It identifies any gaps in process delivery and responsibilities RACI is an acronym for the four main roles of: Responsible - The person or people responsible for getting the job done Accountable Only 1 person can be accountable for each task Consulted - The people who are consulted and whose opinions are sought Informed The people that are kept up-to-date on progress Occasionally an expanded version of RACI is used called RACI-VS with 2 further roles as follows: Verifies - The person or group that checks whether the acceptance criteria has been met Signs off - this is the person that approves the V decision and authorizes the product hand off. This could be the A person A third variation of the RACI model is RASCI where the S represents Supportive. This role provides additional resources to conduct the work or plays a supportive role in implementation for example. This could be beneficial for IT service implementation.

Slide 20

Key Roles in Service Management

Process Owner : Accountable for the overall process Service Owner : Accountable for a specific service within an organization regardless of where the underpinning technology components, processes or professional capabilities reside

Responsibility of owners is to:

Be accountable for the final outcomes (end-to-end accountability) Identify areas of improvements and recommending appropriate changes process and service improvement initiatives

Guide

Slide 21

Service Lifecycle

Slide 22

Service Lifecycle
Syllabus
The Service Lifecycle and ITIL ITIL Library:
Structure Scope Components Interfaces

Slide 23

Service Lifecycle & its Phases

What is the Service Lifecycle?
An ongoing, multidimensional approach to effectively and efficiently transform strategy into desired output
Requires:
Specialization & coordination Feedback & control

Should:
Provide structure, stability & strength to SM capabilities Protect investments & provide basis for improvement

The Service Lifecycle can be explained as the ongoing multi-dimensional approach to effectively and efficiently transform strategy into desired output. This is a limiting definition, so lets examine the Service Lifecycle more closely. To be effective and efficient, the lifecycle approach requires: Specialization and coordination AND Feedback and control between the processes and functions within and across the elements of the lifecycle. The Service Lifecycle should: Provide structure, stability, and strength to service management capabilities with durable principles, methods, and tools. Serve to protect investments and provide the necessary basis for measurement, learning, and improvement. The Diagram shows the high-level view of the IT Service Lifecycle: Business strategy dictates IT strategy IT strategy support the business by designing service solutions Designed service solutions are tested and deployed to enable/support the business Whilst in operation, services are maintained and supported to ensure their performance against agreed levels To ensure competitiveness, effectiveness and efficiency, a continual improvement cycle should be adopted
This is not the only pattern of action in the service lifecycle as each element provide points for feedback and control

(governance)

SDP = Service Delivery Package SKMS = Service Knowledge Management System

Slide 24

Service Lifecycle
The Service Lifecycle based on the ITIL architecture
SS:
Axis of rotation Policies & Objective

SD, ST, SO:

Progressive phases Change & Transformation Implement Strategy

CSI:
Learning & Improvement Prioritize strategy improvement

ITIL v3 creates a way of integrating IT processes, people and tools with the Business Strategy and Outcomes through IT services. The volumes of the ITIL Core is based on a Service Lifecycle as represented in the diagram:

Service Strategy (SS) represents policies and objectives and is the axis around which the lifecycle rotates. Service Design (SD), Service Transition (ST) and Service Operation (SO) are progressive phases of the Lifecycle,
representing change and transformation, through which strategy is implemented. and projects according to the strategic objectives.

Continual Service Improvement (CSI) embodies learning and improvement, placing and prioritizing improvement programs
Important: The wheel diagram perfectly illustrates the ongoing challenges of Service Management (and service delivery).

It would be unusual for any organization to starting from nothing - so there is no obvious entry point to the wheel. This journey also never ends - so there is no easy exit point from the wheel.

Slide 25

Service Lifecycle
ITIL v3 Library
Service Strategy (SS)
Focuses on service management as a strategic asset. Defines standards & policies that will be used to design IT services.

Service Design (SD)

Creating or modifying services & infrastructure architecture that are aligned to the business needs.

Service Transition (ST)

Manages the transition of new or changed services into the production environment.

Service Operation

Effectiveness & Efficiency in delivery & support. Maintain Stability. Provide best practice advice & guidance on all aspects of managing the day-to-day operation of IT services. Create & maintain value for customers Plan, Do, Check, Act (PDCA)

Continual Service Improvement

Service Strategy Guidance on principles underpinning the practice of service management Useful to develop policies, guidelines and processes across the Lifecycle Guidance useful in conjunction with the other volumes Covered topics include the development of markets, internal and external, service assets, service catalogue, and implementation of strategy through the Service Lifecycle. Financial Management, Service Portfolio Management, Organizational Development, and Strategic Risks are among other major topics. Service Design Guidance for the design and development of services and processes. Covers design principles and methods for converting strategic objectives into portfolios of services and service assets. Not limited to new services. Includes the changes and improvements necessary to increase or maintain value to customers over the lifecycle of services, the continuity of services, achievement of service levels, and conformance to standards and regulations. Service Transition Guidance for the development and improvement of capabilities for transitioning new and changed services into operations Guidance on Service Strategy requirements encoded in Service Design are effectively realized in Service Operation while controlling the risks of failure and disruption. Combines practices in Release Management, Program Management, and Risk Management Guidance on managing the complexity related to changes to services and processes Guidance is provided on transferring the control of services between customers and service providers. Service Operation Guidance on achieving effectiveness and efficiency in the delivery and support of services to ensure value to customers Strategic objectives are realized, critical capability Guidance to maintain stability in service operations, allowing for changes in design, scale, scope, and service levels. Detailed process guidelines, methods, and tools provided for use in two major control perspectives: reactive and proactive. Knowledge provided to make better decisions on managing availability of services controlling demand optimizing capacity utilization scheduling of operations fixing problems Guidance is provided on supporting operations through new models and architectures shared services utility computing web services

mobile commerce.

Continual Service Improvement Instrumental guidance in creating and maintaining value for customers through better design, introduction, and operation of services Combines principles, practices, and methods from quality management, change management, and capability improvement Realize incremental and large-scale improvements in service quality, operational efficiency, and business continuity Guidance for linking improvement efforts and outcomes with service strategy, design, and transition A closed-loop feedback system established, capable of receiving inputs for change from any planning perspective Based on the Plan, Do, Check, Act (PDCA) model in ISO/IEC 20000

Slide 26

Service Lifecycle
ITIL v3 - Continual Service Improvement

Continual Service Improvement CSI doesnt start after services are in operations. CSI in used throughout the lifecycle.

Slide 27

Processes in each phase

Service Portfolio Mgmt Finance Mgmt Demand Mgmt

Event Mgmt Incident Mgmt Request Fulfillment Problem Management Access Management

Step Improvement Process Service Reporting Service Measurement

Slide 28

Key Concepts
Service Knowledge Management System (SKMS)
Information, in the form of knowledge, to base decisions on.
Consists of:
Staff experiences Peripheral records Supplier / Partner information
Requirements Abilities Expectations

User skill levels

Within IT Service Management, Knowledge Management focuses on the Service Knowledge Management System (SKMS). Underpinned by data, held in a central logical repository or Configuration Management System (CMS) and Configuration Management Database (CMDB). It is a broader concept that covers a much wider base of knowledge, for example: The experience of staff Records of peripheral matters, e.g. user numbers and behavior, organizations performance figures Suppliers and partners requirements, abilities and expectations Typical and anticipated user skill levels. Figure (Left): Data-to-Wisdom maturity. Figure (Right): Simple illustration of the relationship of the three levels: data being gathered within the CMDB feeding through the CMS into the SKMS supporting the informed decision making process.

Slide 29

Service Strategy

Slide 30

Service Strategy
Goal
To help service providers to operate and grow successfully in the long term and provide the ability to think and act in a strategic manner

Main Activities:
Define the market Develop the offerings Develop strategic assets Prepare for execution

Helps Managers tackle higher levels of uncertainty, complexity and conflict, and to select, adapt and tune their IT strategies.

Slide 31

Objective of SS
Objectives
To provide direction for
- Growth - Prioritizing investments and

- Defining outcomes
against which the effectiveness of service can be measured Sets clear direction for everyone for quicker decision Guides entire SD, ST & SO in a coherent manner for effective service operations

Slide 32

SS - Processes
4 Main activities
Activity Activity Activity Activity 1 2 3 4 Define the Market Develop the Offerings Develop Strategic Assets Prepare for Execution
Service Portfolio Mgmt Finance Mgmt Demand Mgmt

Processes
Service Portfolio Management Demand Management Financial Management

Slide 33

Service Portfolio Management

Goal
To manage service portfolios by considering services in terms of the business value they provide

Value
Demonstrate value through ability to anticipate change Maintain traceability to strategy and planning

Value is derived from better service delivery and customer experiences, and begins with documenting services Value: The market space and service portfolio at Service Strategy stage drive effectiveness throughout the lifecycle. valuable in: decision making in terms of the appropriate Service Transition plan, and the resource requirements during business-as-usual service operation. SPM - maximizing value while managing risks and costs. The value realization is derived from better service delivery and customer experiences. Managers are better able to understand quality requirements and related delivery costs. Seek to reduce costs through alternative means while maintaining service quality.

Slide 34

Service Portfolio Management

Objective
SPM is a dynamic & ongoing process set with the following work methods:
Define:
inventory services, ensure business cases and validate portfolio data

Analyze:
maximize portfolio value, align and prioritize and balance supply and demand

Approve:
finalize proposed portfolio, authorize services and resources

Charter:
communicate decisions, allocate resources and charter services

Define: inventory services, ensure business cases and validate portfolio data Analyze: maximize portfolio value, align and prioritize and balance supply and demand Approve: finalize proposed portfolio, authorize services and resources Charter: communicate decisions, allocate resources and charter services.

Slide 35

Generic concepts & definitions

Service Portfolio
Contain accurate information on all services
Includes status whatever stage of the lifecycle Changes governed by policies and procedures Includes third-party services 3 phases:
Service Pipeline Service Catalogue Retired Services

Service Portfolio The Service Portfolio consists of all services, at whatever stage of their lifecycle. 3 PHASES:

Services being developed are in the Service Pipeline. Those that may be offered and consumed by customers constitute the Service Catalogue. Retired services remain in the Service Portfolio

Slide 36

Service Portfolio Management

Service Portfolio Management
A dynamic method for governing investments in service management across the enterprise & managing them for value Service Portfolio
Services at any stage of their lifecycle

Service Pipeline
Developed services

Service Catalogue
Services offered to & consumed by customer

SPM: Figure shows position of Service Pipeline, Catalogue in respect of Portfolio note retired services

Slide 37

Generic concepts & definitions

Business Service Catalogue
The customer view of Service Catalogue.
Relationships to business units & business process that rely on IT services. Facilitates development of more proactive or preemptive SLM process.

Technical Service Catalogue

Underpin Business Service Catalogue - not part of customer view.
Relationships to supporting services, shared services, components & CIs necessary to support provision of service to the business. Facilitates development of SLAs, OLAs & underpinning agreements:
Identify technology required to support a service Identify support group(s) that support components.

The Service Catalogue has two aspects: The Business Service Catalogue This is the customer view of the Service Catalogue. It contains details of all the IT services delivered to the customer. It includes the relationships to the business units and the business process that rely on the IT services. Facilitates the development of a much more proactive or even preemptive SLM process, allowing it to develop more into the field of Business Service Management. The Technical Service Catalogue Should underpin the Business Service Catalogue and not form part of the customer view. It contains details of all the IT services delivered to the customer. It includes the relationships to the supporting services, shared services, components and CIs necessary to support the provision of the service to the business. Beneficial when constructing the relationship between services, SLAs, OLAs and other underpinning agreements and components, as it will identify the technology required to support a service and the support group(s) that support the components. Some organizations maintain either a Business Service Catalogue or a Technical Service Catalogue. More mature organizations maintains both aspects within a single Service Catalogue, which is part of a totally integrated Service Portfolio supported by Service Management. The combination of a Business Service Catalogue and a Technical Service Catalogue is invaluable for quickly assessing the impact of incidents and changes on the business.

Slide 38

Generic concepts & definitions

The Service Catalogue

The figure illustrates the relationship between the two aspects of the Service Catalogue:

Business Service Catalogue Technical Service Catalogue

Slide 39

Service Composition / Decomposition

Slide 40

Generic concepts & definitions

Business Case
A means to identify business imperatives that depend on service management A justification for significant item of expenditure
Model of what a service is expected to achieve Provide data & evidence to justifying reasons for:
Improving service or process Pursuing a course of action

Should present:
Cost Expected benefits

Aim of Service Portfolio Management is to maximizing value while managing risks and costs. The value realization is derived from better service delivery and customer experiences. A business case allow managers to better understand quality requirements and related delivery costs. It seeks to reduce costs through alternative means while maintaining service quality. It is a decision support and planning tool that projects the likely consequences of a business action, which can take on qualitative and quantitative dimensions. A financial analysis, for example, is frequently central to a good business case.

Slide 41

Key Concepts
Risk
Uncertainty of outcome:
Positive opportunity or negative treat Often referenced with Probability

Risk Management should:

Be visible, repeatable & consistent Use a framework - well defined steps Support decision making

Two phases:
Analysis Management

Risk is defined as uncertainty of outcome, whether positive opportunity or negative threat. Managing risks requires the identification and control of the exposure to risk (vulnerability), which may have an impact on the achievement of an objective.

Should be visible, repeatable and consistently applied to support decision making. Makes cost-effective use of a risk framework that has a series of well-defined steps. Aim is to support better decision making through a good understanding of risks and their likely impact.
There are two distinct phases (See Figure): Risk Analysis Concerned with gathering information about exposure to risk so that the organization can make appropriate decisions and manage risk appropriately. Risk Management

Having processes in place to monitor risks, access to reliable and up-to-date information about risks Having the right balance of control in place to deal with those risks Having decision-making processes supported by a framework of risk analysis and evaluation.

Slide 42

Risk & Investment Decision

Slide 43

Financial Management
Financial Management
Quantifies the value of IT Services, assets underlying the provisioning of services, and qualifications of operational forecasting, in financial terms

Slide 44

Concepts & Activities

Important Concepts
Budgeting Accounting

Reporting
Charging

Activities of FM
Service Valuation
Service Provisioning models & analysis Funding model alternatives

BIA Business Impact Analysis

Slide 45

Demand Management
Goal
Understand and influence Customer demand for Services & provide capacity to meet these demand
Please note: - At a Strategic level Demand Management can involve analysis of Patterns of Business Activity and User Profiles - At a Tactical level it can involve use of Differential Charging to encourage Customers to use IT Services at less busy times - It is very closely linked to capacity management

Slide 46

Service Level Package

SLP is 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.

Slide 47

SS - Roles
Director of Service Management Contract Manager Product Manager

Process Owner
Business Representative

Slide 48

Service Design

Slide 49

Service Design
Syllabus
Main goals & objectives Business Value Generic concepts & definitions:
Service Provider Supplier Service Level Agreement Operational Level Agreement Contract Service Design Package Availability

Key Principles & Models:

4 Ps - People, Processes, Products & Partners 5 Major Aspects of Service Design Sourcing approaches & options

Slide 50

Service Design
Syllabus (continued)
Processes:
Service Level Management
High level objectives Scope basic concepts Process activities Key metrics Roles

Challenges

Objectives, basic concepts & roles:

Service Catalogue Management Availability Management Information Security Management

Supplier Management Capacity Management IT Service Continuity Management

Slide 51

Service Design
Definition:
'The design of appropriate & innovative IT services, including their architectures, processes, policies & documentation, to meet current and future agreed business requirements'
This means: Translating strategic plans & objectives and creating designs & specifications for execution through service transition & operations. Combining infrastructure, applications, systems, & processes, with suppliers & partners, to present feasible service offerings

The main purpose of the Service Design stage of the lifecycle is the design of new or changed service for introduction into the live environment. On the definition: - Service Design translates strategic plans and objectives and creates the designs and specifications for execution through service transition and operations. - It provides guidance on combining infrastructure, applications, systems, and processes, along with suppliers and partners, to present feasible service offerings.

Slide 52

Service Design
Goals
To create a realistic service outline with:
Policies Architecture Portfolios Service Models Effective Technology Process & Measurement design

To provide guidance on development of Services, Models & processes

To maintain or increase value

To create a realistic service outline with:

Policies for the design of quality IT solutions, to meet current and future agreed business needs Architecture Portfolios convert strategic objectives into portfolios of services Service Models Effective Technology Process & Measurement design

Service Design assists in deciding on activities to be done (how and what) To maintain or increase value, changes and improvements are necessary

Slide 53

Service Design
Objectives
Provide guidance on the design and development of:
Services Service management processes Design capabilities

Not limited to new services

Includes changes & improvements required to maintain or increase value to customers over the lifecycle of services
Service Design should adopted a holistic approach
For all aspects & areas

To ensure consistency & integration

Within all activities & processes Across the entire IT technology To provide end-to-end business related functionality & quality.

Objectives of Service Design

The Service Design volume provides guidance on the design and development of services and service management processes.

assets.

- It includes design principles and methods for converting strategic objectives into portfolios of services and service - It also provides guidance on the development of design capabilities for service management.

Service Design is not limited to new services It includes the changes and improvements required to maintain or increase value to customers over the lifecycle of services, taking

into account: - The continuity of services, - Conformance to standards and regulations and - Achievement of service levels.
Should adopt a holistic approach

Key Message: - It is important that a holistic approach to all aspects of design is adopted and that when changing or amending any of the individual elements of design all other aspects are considered. - Thus when designing and developing, it shouldnt be done in isolation, but should also consider the impact on: + The overall service, + The Service Portfolio and Catalogue, + The technology, + The Service Management processes and + The necessary measurements and metrics. This will ensure that not only the functional elements are addressed by the design, but also that all of the management and operational requirements are also addressed as a fundamental part of the design and are not added as an afterthought.

Slide 54

Service Design
Business Value
Reduce Total Cost of Ownership (TCO)
Improve quality of service Improve consistency of service

Easier implementation of new or changed services

Improve service alignment More effective service performance

Improve IT governance
More effective Service Management & IT processes Improve information & decision making

Business Value With good Service Design it will be possible to deliver quality, cost effective services and to ensure that the business requirements are being met. Reduced Total Cost of Ownership (TCO) Through properly implemented services, technology and processes Improved quality of service On an operational and service level Improved consistency of service Services will be designed in conjunction with the corporate strategy, architectures etc. Easier implementation of new or changed services Service Design is better integrated Improved service alignment New or changed services are better aligned with the business needs More effective service performance Plans are better integrated especially Capacity, Financial, Availability and IT Service Continuity plans Improved IT governance Enhanced communication and implementation of governance controls. More effective Service Management and IT processes quality and cost effective process designs are developed Improved information and decision making more comprehensive and effective measurements and metrics

Slide 55

SD - Generic Concepts & Definitions

Service Provider
The entity responsible for delivery of a service to customers & business

Supplier

3rd Party who supplies goods/services required to deliver IT Services

Service Level Agreement

Formal agreement between service provider & customer record of agreed service levels

Operational Level Agreement

Any underpinning agreements necessary to deliver the quality of service agreed within the SLA

SERVICE PROVIDER Provide services (e.g. email, billing) to customers (internal/external) SUPPLIER

Any external third parties necessary to provide third and fourth line support of the components required to provide the service e.g. networks, hardware, software

SERVICE LEVEL AGREEMENT SLA describes:

IT Services & Service Level Targets Roles and Responsibilities Covers multiple Services or multiple Customers Should be reviewed regularly to ensure conformance. IMPORTANT: Stand-alone SLAs may not be legally enforceable - represents the goodwill and faith of the parties signing it. In the interest of signatories that SLAs are incorporated into an appropriate contractual framework, to meet the ITIL objective that SLAs are binding agreements.

OPERATIONAL LEVEL AGREEMENT OLA defines: Goods or services provided Roles and responsibilities OLA between: Service Provider & Procurement Service Desk & Support Group

Slide 56

SD - Generic Concepts & Definitions

Contract
Legally binding, covering obligations each entity has to the other; from the first day of the contract, often extending beyond its termination

Service Design Package (SDP)

A SDP details all aspects of the service and its requirements during the design stage through all of the subsequent stages of its lifecycle.

Availability
The proportion of time that a customer is able to access a particular service.

CONTRACT

Agreement between two or more parties. Formal contracts are appropriate for external supply arrangements which make a significant contribution to the delivery and development of the business. A contract is used as the basis for external supplier agreements where an enforceable commitment is required. High-value and/or strategic relationships are underpinned by a formal contract. The formality and binding nature of a contract are not at odds with the culture of a partnering agreement, but rather form the basis upon which trust in the relationship may be founded.

SERVICE DESIGN PACKAGE Produce a Service Design Package for each new service, major change to a service, removal of a service or change to the Service Design Package. The SDP is passed from Service Design to Service Transition and details all aspects of the service and its requirements through all of the subsequent lifecycle stages. AVAILABILITY To perform a agreed function when required. Availability (%) = Agreed Service Time and Downtime Availability is determined by: Reliability Maintainability Serviceability Performance Security. Availability is measured from the customers point of view and recorded in the SLA.

Slide 57

SD - Key Principles & Models

Service Design Perspective - links, inputs & outputs

The diagram:

overview of the links inputs and outputs involved in the each of the stages of the service lifecycle. illustrates the key outputs produced by each stage, which are used as inputs by the subsequent stages.
Service Portfolio acts as the backbone of the service lifecycle.

Slide 58

SD - Key Principles & Models

5 Major aspects of Service Design
1. Service Portfolio Design 2. Identification of Business Requirements, definition of Service requirements and design of Services 3. Technology architectural design

4. Process design
5. Measurement design

The key aspect is the design of new or changed service solutions to meet changing business needs. Every time a new service solution is produced it must be checked against each of the other aspects to ensure that it will integrate and interface with all of the other services already in existence. Service Design is concerned with the following 5 major issues: Service Portfolio Management Managing and controlling services through their lifecycle with service management systems and tools. Identification of Business Requirements, definition of Service requirements and design of Services Services are designed with all the functional requirements, resources and capabilities needed.

Technology architectural design Designing the technology architectures and management systems required to provide the services Process design Designing the processes needed for transition, to operate and improve the services, the architectures and the processes themselves Measurement design Designing the measurement methods and metrics of the services, the architectures and their constituent components and the processes

Slide 59

Technology and Architectural Design

Service Design tools will help to ensure that standards and conventions are followed

Slide 60

SD - Key Principles & Models

3. Technology Architectural Design:
Provide overall strategic development & deployment blueprints for technology architectures & management systems Definition Architecture System Architectural Design Enterprise Architecture Affect of Service Design
Work within framework Re-use existing assets

Designing Technology Architectures

The design of the technology architectures and management systems required to provide the services are concerned with the

overall strategic blueprints for the development and deployment of an IT infrastructure (applications and data), which satisfy the current and future needs of the business. Although technology underpin the delivery of quality IT services, they cannot deliver do so alone; it is essential that the people, process and partner / supplier aspects surrounding these technological components (products) are also considered.
Definition Architecture

The fundamental organization of a system embodied in its components, their relationships to each other and to the environment, and the principles guiding its design and evolution. A collection of components organized to accomplish a specific function or set of functions. The system could be, e.g. a whole organization, a business function, a product line or an information system. Each of these systems will have an "architecture" as defined earlier, made up of: The components of the system The relationships between them (such as control interfaces and data exchanges) The relationships between the system and its environment (political, organizational, technological, etc.) The design principles which inform, guide and constrain its structure and operation, as well as its future development.

Definition System

Definition - Architectural Design can be defined as: The development and maintenance of IT policies, strategies, architectures, designs, documents, plan and processes for the deployment and subsequent operation and improvement of appropriate IT services and solutions throughout an organization. Architectural design needs to assess and reconcile many types of needs, which might be in conflict with one another, to ensure that: IT infrastructures, environments, data, applications and external services serve the needs of the business, its products and services. This includes the technology components and their management. The right balance is achieved between innovation, risk and cost whilst seeking a competitive edge, where desired by the business

 Enterprise Architecture

Compliance with relevant architectural frameworks, strategies, policies, regulations and standards (fiduciary requirements) Coordinated interface is provided between IT designers and planners, strategists, business designers and planners.

An Enterprise Architecture show how all the components (and others) are integrated in order to achieve the business objectives both now and in the future and can be large and complex. We are focusing on those architectures concerned with the business and the information systems which support it; each of these architectures calls upon distinct architectural disciplines and areas of expertise

With the necessary architectures in place, the role of Service Design is affected as follows: Must work within the agreed architectural framework and standards Will be able to re-use many of the assets created as part of the architecture

If architecture design is to be accomplished effectively and economically, the documents, processes and activities of the business and architectural design should be closely coordinated and synchronized. Key message: The real benefit and RoI of the Enterprise Architecture comes not from the architecture itself, but from the ability of an organization to design and implement projects and solutions in a rapid and consistent manner.

Slide 61

Measurement Design
'If you can't measure it you can't manage it'.
Four types of metrics

Progress : milestones and deliverables in the capability of the process Compliance : compliance of the process to governance requirements, regulatory requirements and compliance of people to the use of the process Effectiveness : the accuracy and correctness of the process and its ability to deliver the 'right result' Efficiency : the productivity of the process, its speed, throughput and resource utilization

Slide 62

SD - Key Principles & Models

Sourcing approaches & options
Service Provider types
Type I Internal Service Provide Type II Shared Service Unit Type III External Service Provider In-sourcing Outsourcing Co-sourcing Partnership or multi-sourcing Business process outsourcing (BPO) Application Service Provision (ASP) - Applications on demand Knowledge process outsourcing (KPO) - domain based processes and business expertise requires advanced and specialized skills

Delivery Model Options

Sourcing situations
On-shore Off-shore

Although the readiness assessment determines the gap between the current and desired capabilities, an IT organization should not necessarily try to bridge that gap by itself. There are many different delivery strategies that can be used. Each one has its own set of advantages and disadvantages, but all require some level of adaptation and customization for the situation at hand. Delivery Strategy: In-sourcing:

utilize internal organizational resources in the design, develop, transition, maintain, operate, and/or support of a new, changed or
revised services or data centre operations Outsourcing:

utilizes the resources of an external organization or organizations in a formal arrangement to provide a well-defined portion of a
services design, development, maintenance, operations, and/or support. Co-sourcing: elements within the lifecycle.

combination of in-sourcing and outsourcing, using a number of outsourcing organizations working together to co-source key This generally will involve using a number of external organizations working together to design, develop, transition, maintain,
operate, and/or support a portion of a services Partnership or multi-sourcing: and/or support IT service(s). Business Process Outsourcing (BPO):

Formal arrangements between two or more organizations to work together to design, develop, transition, maintain, operate, The increasing trend of relocating entire business functions using formal arrangements between organizations where one

organization provides and manages the other organizations entire business process(es) or functions(s) in a low cost location. Application Service Provision:

Involves formal arrangements with an Application Service Provider (ASP) organization that will provide shared computer based
services to customer organizations over a network. Knowledge Process Outsourcing (KPO):

KPO organizations provide domain based processes and business expertise rather than just process expertise and requires
advanced analytical and specialized skills from the outsourcing organization. SOURCING SITUATIONS on-shore

based within the same country /continent,

off-shore

organizations are in different countries / continents.

Very complex sourcing arrangements exist within the IT industry and it is impossible to cover all combinations and their implications here.

Slide 63

Complementary and Web based Guidance

Complementary Guidance : Industry Specific Guidance or guidance related to specific industry

Web Based Guidance : Day to day guidance about ITIL on need basis

Slide 64

SD Processes
Service Level Management (SLM) Service Catalogue Management (SCM) Capacity Management Availability Management

Service Continuity Management

Information Security Management Supplier Management

Slide 65

SLM - Goals
The goal of Service Level Management is to ensure that : An agreed level of IT service is provided for all current IT services Future services are delivered to agreed achievable targets Proactive measures are taken to seek and implement improvements to the level of service delivered

Slide 66

Service Level Management

Basic concepts
Service Level Management (SLM)
A communication channel & relationship with appropriate customers & business representatives

Service Level Agreement (SLA)

Written agreement between an IT service provider & the IT customer(s), defining the key service targets and responsibilities of both parties.

Operational Level Agreement (OLA)

Agreement between an IT service provider & another part of the same organization that assists with the provision of services

Underpinning Contract (UC)

Formal contract between an IT Service Provider & a Third Party.

Slide 67

SLM - Process

Slide 68

Service Level Management

Key Metrics (KPIs)
Percentage reduction in:
SLA targets missed SLA targets threatened SLA breaches (UC) SLA breaches (OLA)

Percentage increase in:

Customer perception & satisfaction of SLA achievements
Service reviews

Customer Satisfaction Survey responses

Deliver service as previously agreed at affordable costs:

Total number and percentage increase in fully documented SLAs in place Percentage increase in SLAs agreed against operational services being run Percentage reduction in the costs associated with service provision

Slide 69

Service Level Management

Challenges
To become a service provider to the business Engaging with business Identifying internal service portfolios Defining Service Catalogue Defining of IT department relationships

Identifying contractual relationships

Service Improvement Plan

Engaging with business to determine service level requirements Identifying internal service portfolios Planned, developed services Defining a customer-facing Service Catalogue With details of every service and service package offered by IT with options, parameters and pricing Defining of IT department relationships: negotiating the terms and responsibilities of the internal relationships, and codifying them with Operational Level
Agreements (OLAs)

Identifying contractual relationships UCs meet business requirements Create a Service Improvement Plan (SIP) to monitor and improve levels of service.

Slide 70

Service Catalogue Management

Goal is to ensure :
That a service catalogue is produced and maintained, It contains accurate information on all operational & planned services

Objective
To manage the information contained within the Service Catalogue Ensure accuracy in
Current details, status, interfaces and dependencies

Scope :
All Services that are being transitioned or have been transitioned to the live environment

Business Service Catalogue

Interfacing with the business units and business processes and their supporting IT Services. Interfacing with support teams, suppliers and configuration management

Technical Service Catalogue

Slide 71

Basic Concepts : SCM

Service Catalogue
Business Service Catalogue Technical Service Catalogue

Slide 72

Capacity Management
Goal To ensure that
Cost-justifiable IT capacity is matched to the current and future agreed needs of the business In a timely manner

Scope :
IT Services IT Components Resources

Basic concepts
Balancing Act Business Capacity Management Service Capacity Management Component Capacity Management

Objectives

Produce and maintain an appropriate and up to date Capacity Plan, reflecting the current and future needs of the business Provide advice and guidance to all other areas of the business and IT on all capacity and performance related issues Ensure that service performance achievements meet or exceed all of the agreed targets, by managing the performance and capacity of both services and resources Assist with the diagnosis and resolution of performance and capacity related incidents and problems Asses the impact of all changes on the Capacity Plan and the performance and capacity of all services and resources Ensure that proactive measures are implemented to improve the performance of services, wherever it is cost justifiable to do so

Basic Concepts Balancing Act The capacity and performance of the IT services and systems should matches the evolving agreed demands of the business in the most cost-effective and timely manner. Balancing costs against resources needed: to ensure processing Capacity is not only cost justifiable in terms of business need, but also the need to make the most efficient use of those resources Balancing supply against demand: to ensure that available supply of IT processing power matches the demands made on it by the business, both now and in the future; it may also be necessary to manage or influence the demand for a particular resource Business Capacity Management Business Capacity Management is focused on the current and future business requirements; it translates business needs and plans into requirements for service and IT infrastructure, ensuring that its quantified, designed, planned and implemented in a timely fashion. Future requirements come from the service strategy and service portfolio detailing new processes and service requirements, changes, improvements and also the growth in the already existing services. Service Capacity Management Service Capacity Management is focused on the delivery of the existing services that support the business; the management, control and prediction of the end-to-end performance and capacity of the live, operational IT services usage and workloads: Monitor and measure Analyze and report

Instigate action (proactive and reactive)

Component Capacity Management Component Capacity Management is focused on the IT infrastructure that underpins service provision; the management, control and prediction of the performance, utilization and capacity of individual IT technology components. Monitor and measure Analyze and report Instigate cost effective actions to reduce or avoid potential impact

Slide 73

Basic Concept : Capacity Management

Capacity Management involves :
Balancing costs against resources needed

Balancing supply against demand

Modelling (handling predictive what-if scenarios etc..) Demand Management Application Sizing

Slide 74

Capacity Management
Basic concepts (continued)

Balancing Act

Balancing costs against resources needed: to ensure processing Capacity is not only cost justifiable in terms of business need, but also the need to make the
most efficient use of those resources

Balancing supply against demand: to ensure that available supply of IT processing power matches the demands made on it by the business, both now
and in the future; it may also be necessary to manage or influence the demand for a particular resource

Slide 75

Capacity Management
Role: Capacity Manager
Ensure adequate IT Capacity
Understand capacity requirements, usage and capacity Sizing new services & systems (future requirements) Production, review & revision of the Capacity Plan

Aligning capacity & demand correctly Optimize existing capacity

Set appropriate monitoring levels through

Performance analysis & reporting Incident & problem resolution Performance & resource optimization Performance & cost assessment Assessment of future demand Impact assessment changes

Slide 76

Capacity Management
Role: Capacity Manager (continued)
Sizing of new services and systems
Assessment of new techniques, hardware and software Performance testing SLA Reporting (effects of demand on performance service levels) Determine cost justified, maintainable performance service levels Optimization recommendations

Focal point for capacity & performance issues

Management reports: current usage, trends and forecasts

Slide 77

Availability Management Goals & Scope

Goal : to ensure that
Level of service availability delivered in all services is Matched to or exceeds

The current and future agreed needs of the business

In a cost-effective manner.

Scope :
Design, implementation, measurement, management and improvement of
IT Service and component availability

Definition :
Ability of Configuration Item or IT Service to perform its agreed Function when required

Slide 78

Availability Management
Objectives
Produce & maintain an Availability Plan Provide advice & guide Ensure service availability targets are met/exceeded Diagnosis & resolution of availability related incidents & problems Asses impact of changes on Availability Plan Ensure proactive measures to improve availability of services

Availability Management should:

Ensure the agreed level of availability is provided. Measure and monitor to ensure availability levels are being met consistently. Continually optimize and proactively improve the availability of the IT Infrastructure, the services and the supporting organization.
Objectives The objectives of Availability Management are:

Produce and maintain an appropriate and up to date Availability Plan that reflects the current and future needs of the business Provide advice and guidance to all other areas on availability related issues Ensure that service availability achievements meet or exceed the agreed targets, by managing services and resources related
availability performance

Assist with diagnosis and resolution of availability related incidents and problems Asses the impact of all changes on the Availability Plan and the performance and capacity of services and resources Ensure that proactive measures are implemented to improve the availability of services wherever it is cost justifiable

Slide 79

Availability Management
Basic concepts
Key elements:
Reactive activities Proactive activities

Inter-connected levels:
Service availability Component availability

Four aspects: (FARMS)

Fault Tolerance Availability Reliability Maintainability / Recoverability Serviceability

Vital Business Function (VBF)

Basic Concepts ELEMENTS

Reactive activities: involves monitoring, measuring, analysis and management of all events, incidents and problems involving
unavailability.

Proactive activities: involve the proactive planning, design and improvement of availability.
INTER-CONNECTED LEVELS Service availability: involves all aspects of service availability and unavailability and the impact of component availability, or the potential impact of component unavailability on service availability Component availability:

involves all aspects of component availability and unavailability

4 ASPECTS Availability: the ability of a service, component or CI to perform its agreed function when required. Reliability: a measure of how long a service, component or CI can perform its agreed function without interruption. Maintainability: a measure of how quickly and effectively a service, component or CI can be restored to normal working after a failure. Serviceability: the ability of a third party supplier to meet the terms of their contract. Often this contract will include agreed levels of availability, reliability and / or maintainability for a supporting service or component. These aspects and their interrelationships are illustrated in the diagram:

Slide 80

Availability Measurement Metrics

MTTR : Mean time to repair.it does not include the time to restore the serviceit is only the time to repair ..

Slide 81

Availability Management
Role: Availability Manager
Participate in IT infrastructure design
Design of new services Event management systems Reliability, maintainability & serviceability Availability & recovery design criteria

Monitor actual IT availability achieved

Ensure availability levels against SLAs Investigation & diagnosis of incidents & problems Improve service availability to optimize availability

Availability Manager An Availability Manager has responsibility for ensuring that the aims of Availability Management are met. This includes responsibilities such as: Participate in the IT infrastructure design, which includes the specification of availability requirements for hardware and software All new services should deliver the required availability levels - validate the final design to meet the minimum levels as agreed Enhanced event management systems - automatic monitoring of IT component availability Specification of the reliability, maintainability and serviceability requirements for components - internal and external suppliers Creation of availability and recovery design criteria for each design Monitor actual IT availability achieved - on an ongoing basis and provide the required reports Ensure delivery against agreed SLA levels Assist with the investigation and diagnosis of all incidents and problems that is availability related Proactively improve/optimize service availability and deliver cost effective improvements/benefits to the business

Slide 82

Availability Management
Role: Availability Manager (continued)
Responsible for Availability Management process
Create, maintain & review AMIT and Availability Plan Availability testing schedule Testing after major business change

Assess impact of changes on Availability Plan

Attending CAB meetings

Ensure cost justified levels of IT availability Assessment and management of risk

Availability Manager (continued) Responsible to ensure that the process, including its techniques and methods, are regularly reviewed, audited, and subjected to continual improvement to remain fit for purpose Create, maintain and review an AMIT and a forward looking Availability Plan - ensure that existing and future business availability requirements can be met Complete and maintain an availability testing schedule for all mechanisms Test availability tests and plans after every major business change Assess change impact on all aspects of availability including overall service availability and the Availability Plan Attend CAB meetings when appropriate Ensure that the levels of IT availability required are cost justified - with Financial Management Assessment and management of risk by assisting Security and IT Service Continuity Management

Slide 83

IT Service Continuity Management

Objectives
To ensure that required IT technical and service facilities can be resumed within required, and agreed, business timescales following a major disruption Complete Business Impact Analysis (BIA) Conduct risk assessment & management Provide advice & guidance Establish mechanisms Asses change impact

Implement improvement measures

Contract management

Objectives Maintain a set of IT Service Continuity Plans and IT recovery plans that support the overall Business Continuity Plans (BCPs) Complete regular Business Impact Analysis (BIA) exercises to support continuity plans in respect of business changes Conduct regular risk assessment and management exercises with business, Availability Management and Security Management Provide advice and guidance to all other areas on continuity and recovery related issues Establish appropriate continuity and recovery mechanisms to meet or exceed the agreed business continuity targets Asses the impact of all changes on the IT Service Continuity Plans and IT recovery plans Implement cost justifiable measures to improve the availability of services Negotiate and agree required contracts for the provision of necessary recovery capability with the Supplier Management process

Slide 84

IT Service Continuity Management Basic Concepts

Disaster : an event that affects a service or system such that significant effort is required to restore the original performance level

Business Impact Analysis (BIA) : The purpose of a Business Impact Analysis is to quantify the impact to the business that loss of service would have

Slide 85

Service Continuity Management

Role: ITSCM Manager
Implement & maintain ITSCM process in accordance with BCM process
Plans, risks & activities Business Impact Analyses Risk assessment & management Communication & awareness Assess potential service continuity issues (invoke plan if required) Manage Service Continuity Plan while in operation Develop & manage ITSCM plans Ensure all IT service areas preparedness Third party recovery services contracts

Develop & maintain continuity strategy

IT testing schedule
Quality, conformance & post mortem reviews

Assess change impact

Service Continuity Manager Service Continuity Manager must ensure that the aims of Service Continuity Management are met, which includes: Implement and maintain the ITSCM process in accordance with the overall requirements of the organizations Business Continuity Management process Ensure that all ITSCM plans, risks and activities underpin and align with all BCM plans, risks and activities and are capable of meeting the agreed targets Perform Business Impact Analyses for all existing and new services Perform risk assessment and management to prevent disasters where cost justifiable and practical Communicate and maintain awareness of ITSCM objectives within supported business areas Develop and maintain the organizations continuity strategy Assess potential service continuity issues and invoking the Service Continuity Plan if necessary Manage the Service Continuity Plan while in operation - including fail-over to a secondary location and restoration to the primary location Develop and manage the ITSCM plans to ensure that the recovery objectives of the business can be achieved at all times Ensure that all IT service areas are prepared and able to respond when continuity plans are invoked Negotiate and manage contracts with third party recovery service providers Maintain a comprehensive IT testing schedule of all continuity plans in line with business requirements AND after every major business change. Undertake quality reviews of all procedures and ensure their incorporation into the testing schedule Undertake regular reviews (at least annual) of the Continuity plans with business to ensure that it reflect the business needs accurately Performing post mortem reviews of service continuity tests and invocations - instigating corrective actions where required Assess changes for their impact on service continuity and Continuity Plans - attend CAB meetings when appropriate

Slide 86

ITSCM Recovery Options

Recovery options for rapid recovery of IT Systems and Network Services : - Do Nothing - Return to manual (paper based) system - Reciprocal arrangements - Gradual recovery (cold site) : time to recovery >72 hours - Intermediate recovery (warm site) : time to recovery 24 hours to 72 hours - Immediate recovery (Hot Site) : time to recovery within 8 hours - Combination of options - Fortress Approach
( ex: Insurance)

Cold standby 1. Time to recovery > 72 hrs 2. Empty computer space 3. Remote 4. Portable 5. Nothing in the rooms. Communication equipment avl. 6. Requires contracts, procedures in place to set up Warm Standby 1. Time to recovery : 24 hrs to 72 hrs 2. Filled computer space 3. Remote 4. Portable 5. Network computer exists but NO DATA Hot standby 1. Time to recovery within the working day : 0 hrs to 8 hrs 2. Filled computer space 3. Remote 4. Portable 5. Networked computers with Data (but not necessarily up to date)

Slide 87

Information Security Management Goals &

Scope Goal : To align IT security with Business security and ensure that information security is effectively managed in all service and Service Management activities
ISM must ensure that an information security policy is produced, maintained and enforced

Scope : The ISM processes should cover use and misuse of all IT systems and services for all IT security issues

Slide 88

Information Security Management

Objectives
Confidentiality Integrity Availability Authenticity & non-repudiation

Basic concepts
Security Framework Information Security Policy Information Security Management System (ISMS)

Objective For most organizations, the security objective is met through: Confidentiality information can only be accessed by those authorized Integrity information is complete, accurate and protected against unauthorized modification Availability information is available and can be used when required Authenticity & non-repudiation information exchanges between parties can be trusted Basic Concepts Security Framework The Information Security Management process and framework will generally consist of: Information Security Policy (ITP) and specific security policies that address each aspect of strategy, controls and regulation Information Security Management System (ISMS), containing the standards, management procedures and guidelines supporting the information security policies Comprehensive security strategy closely linked to the business objectives, strategies and plans Effective security organizational structure Set of security controls to support the ITP Management of security risks Monitoring processes to ensure compliance and provide feedback on effectiveness Communications strategy and plan for security Training and awareness strategy and plan Information Security Policy Information Security Management activities should focus on the an overall Information Security Policy (ITP) and a set of underpinning specific security policies. Policies should be widely available to all customers and users and their compliance should be referred to in all SLRs, SLAs, contracts and agreements. Policies should be authorized by top executive management (business and IT) and compliance should be endorsed regularly reviewed/revised annually. The ITP should be appropriate, meet the needs of the business and cover all areas of security: use and misuse of IT assets policy an access control policy a password control policy an email policy an Internet policy an anti-virus policy an information classification policy

a document classification policy a remote access policy a policy with regard to supplier access of IT service, information and components an asset disposal policy

Information Security Management System (ISMS) The ISMS provide a basis of the development of a cost effective information security program to support the business objectives. It will involve the four Ps (People, Process, Products/technology & Partners/suppliers) to ensure high levels of security.

Slide 89

Information Security Mngmnt

Role: Security Manager
Information Security Policy & supporting policies
Communicate & publish Enforcement (adherence) Promote (awareness)

Security controls & plans

Procedures security controls Maintain, review & audit

Business Impact Analyses

IT & information assets (Configuration Items) Security risk analysis & management Security tests

Security Manager Develop and maintain the Information Security Policy and a supporting policies, ensure appropriate authorization, commitment and endorsement from IT and business management

Communicate and publish the Information Security Policy to all appropriate parties Ensuring that the Information Security Policy is enforced and adhered to Promote education and awareness of security

Design security controls and develop security plans Develop and document procedures for operating and maintaining security controls Maintain, review and audit all security controls and procedures regularly

Assist with Business Impact Analyses Identify and classify IT and information assets (Configuration Items) and the level of control and protection required Perform security risk analysis and management - with Availability and IT Service Continuity Management Perform security tests

Slide 90

Information Security Mngmnt

Role: Security Manager (continued)
Security breaches & incidents
Impact & volumes Security reviews

SLAs & statutory requirements

Assess changes - CAB Access: external partners & suppliers Focal point for security issues

Security Manager (continued) Monitor and manage all security breaches - take remedial action to prevent recurrence wherever possible (see Figure).

Reporting, analysis and reduction of the impact and volumes of all security incidents - with Problem Management Participate in security reviews arising from security breaches

Ensure confidentiality, integrity and availability of the services at the levels agreed in the SLAs and conform to all relevant statutory requirements Assess impact of all changes on security aspects, Information Security Policy and security controls - attend CAB meetings when appropriate Ensure that access to services by external partners and suppliers is subject to contractual agreements and responsibilities Act as a focal point for all security issues

Slide 91

Supplier Management
Goal To manage suppliers and the services they supply, to provide seamless quality of IT service to the business, ensuring value for money is obtained
Objective
Obtain value for money

Alignment of underpinning contracts & agreements

Manage supplier relationships & performance Negotiate, agree & manage contracts through their lifecycle Maintain supplier policy and Supplier & Contract Database (SCD)

Objective

Obtain value for money from supplier and contracts Ensure that underpinning contracts/agreements with suppliers are aligned to business needs and targets in SLRs and SLAs - with
SLM

Manage relationships with suppliers and their 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) Note: contracts are made at the service level management level. Closely look at the above points

Slide 92

Supplier Management
Basic concepts (Suppliers & Contract Database - SCD)
Categorization & maintenance Evaluation Establish new Management & performance Renewal & termination

Basic concepts Supplier Management process activity should be driven by a supplier strategy and policy from Service Strategy. Diagram: a Supplier and Contracts Database (SCD) should be established to achieve consistency and effectiveness in the implementation of the policy, roles and responsibilities:

SD: Supplier categorization and maintenance of the Supplier and Contracts Database (SCD) SD: Evaluation and set up of new suppliers and contracts ST: Establish new suppliers SO: Supplier and contract, management and performance SO: Contract renewal and termination
(The first two are covered in the Service Design stage, the third is part of Service Transition and the last two are part of the Service Operation stage.)

Slide 93

Service Design Supplier Management

Role: Supplier Manager
Provide Assistance in development and review of SLAs, contracts, agreements, etc.
Ensure Value for money is obtained from all IT Suppliers & contracts

Maintain & Update Supplier & Contracts Database (SCD)

Updates (Change Management process) Impact assessment of changes - CAB

Review & risk assessment

Sub-contracted suppliers Contract / SLA reviews Ensuring value ROI Processes & interfaces

Disputes

Termination / transfer Reporting & improvement

Note: contracts are made at the service level management level. Closely look at the above points

Supplier Manager Providing assistance in the development and review of SLAs, contracts, agreements or any other documents for third party suppliers Ensure that underpinning contracts, agreements or SLAs are aligned with the business Ensure that supporting services are scoped and documented and that interfaces/dependencies between suppliers, supporting services and supplier processes are agreed and documented Ensure that roles and relationships between lead and sub-contracted suppliers are documented, maintained and contractually agreed Co-ordinate and support of all individual IT supplier and contract managers - ensure that each has a nominated owner Maintain and review a Supplier and Contracts Database (SCD) Update contracts/SLAs when required, according to the Change Management process Ensure changes are assessed for their impact on suppliers, supporting services and contracts - attend CAB meetings when appropriate Regular review and risk assessment of all suppliers and contracts Review lead suppliers processes to ensure that sub-contracted suppliers meet their contractual obligations Perform contract/SLA reviews to ensure consistency with requirements, standard terms and conditions Ensure that value for money is obtained from all IT suppliers and contracts Ensure that all IT supplier processes are consistent and interface to all corporate supplier strategies, processes and standard terms and conditions Maintain a process for dealing with contractual disputes - ensure that any disputes are dealt with efficiently and effectively Maintain a process for dealing with the expected end, early end or transfer of a service Monitor, report and review supplier performance against targets - identify appropriate improvement actions and ensure their implementation

Slide 94

Service Transition
(transition services into operation without disturbing existing services)

Slide 95

Service Transition
Syllabus
Main goals & objectives Business Value Generic concepts & definitions:
Configuration Item Configuration Management System Definitive Media Library Service Change Change Types (Normal, Standard & Emergency) Release Unit Seven Rs of Change Management

Key Principles & Models:

Service V model

Slide 96

Service Transition
Syllabus (continued)
Processes:
Change Management
High level objectives Scope Basic concepts Process activities Key metrics Roles

Challenges

Objectives, basic concepts & roles:

Service Asset & Configuration Management Release & Deployment Management

Slide 97

Service Transition
Definition:
'The management & co-ordination of processes, systems & functions to package, build, test and deploy a release into production & establish the service specified in the requirements

Goals
Set customer expectations Enable release integration Reduce performance variations (predicted vs. actual) Reduce errors & risks during transition Ensure service usability

Goals The goals of service transition:

Set customer expectations on how the performance and use of a new or changed service can enable business change Enable release integration of business processes and services Reduce variations in the predicted and actual performance of transitioned services Reduce known errors and minimize risks from transitioning new or changed services into production Ensure that the service can be used in according to the requirements and constraints specified

Slide 98

Service Transition ITIL Library

Objectives
Resource management Minimize impact on production environment Increase satisfaction of transition experience Emphasize proper use Align change projects with service transition plans

Objectives:

Plan and manage the resources to successfully establish a new or changed service into production within the predicted cost,
quality and time estimates

Ensure minimal unpredicted impact on the production services, operations and support organization Increase the customer, user and service management staff satisfaction with the service transition practices of the new or changed
service (deployment, communications, release documentation, training, knowledge transfer)

Increase proper use of the services and underlying applications and technology solutions Provide clear and comprehensive plans that enable the customer and business change projects to align their activities with the
service transition plans.

Slide 99

Service Transition ITIL Library

Business value
The ability to adapt quickly to change and market development (Adaptability = competitive edge) Facilitates mergers, de-mergers, acquisitions & transfer of services Success rate of changes & releases Prediction of service levels & warranties Less variation between actual, estimated & approved resources Increased productivity Timely transition of contracts Improved risk management

Business value:

Ability to adapt quickly to new requirements and market developments (competitive edge) Transition management facilitates management of mergers, de-mergers, acquisitions and transfer of services Increase success rate of changes and releases for the business Improve the predictions of service levels and warranties for new and changed services Confidence in the degree of compliance with business and governance requirements during change Decrease in variation of actual against estimated and approved resource plans / budgets Increase the productivity of business and Customer staff - better planning and use of new and changed services Timely cancellation or changes to maintenance contracts when components are disposed or de-commissioned - both hardware and
software

Better understanding of the level of risk during and after change e.g. service outage, disruption, re-work.

Slide 100

Service Transition Processes

Service Asset & Configuration Management (SACM)
Change Management (cross referenced to SLM) Release & Deployment Management

Slide 101

Service Asset & Configuration Management

Objective
To define & control components of services & infrastructure and maintain accurate configuration records.
Compliance with corporate governance requirements Control asset base Optimize costs Enable effective change & release Expedite incidents & problem resolution

Objective To define and control the components of services and infrastructure and maintain accurate configuration records. This enables an organization to:

Comply with corporate governance requirements Control its asset base Optimize its costs Manage change and releases effectively Resolve incidents and problems faster

Slide 102

Service Transition Generic concepts and definitions

Configuration Item (CI)
An asset, service component or other item that needs to be managed in order to deliver an IT service

All CI's are under control of SACM and need formal RFC to be changed
Information about each CI is recorded in a Configuration Record within the Configuration Management System and is maintained throughout its Life cycle by Configuration Management

Configuration Item (CI) A configuration item is an asset, service component or other item which is, or will be, under the control of configuration management. Configuration Management System The Configuration Management System holds all the information for CIs within the designated scope. Some of these items will have related specifications or files that contain the contents of the item e.g. software, document, photograph. For example, a Service CI will include the details such as:

Supplier Cost purchase date renewal date for licenses maintenance contracts related documentation (SLAs and underpinning contracts)
The Figure is not required for the syllabus, but provide opportunity to explain some of the layers, sources & benefits.

Slide 103

Major CI Types
Hardware: Computers, Computer components, Network Components & cables (LAN
& WAN), Telephones, Switches etc.... systems, packages etc...

Software: Network management systems, In-house applications, O/S, office

Data Files: What, Where, Most Important Services: Desktop Support, E-mail, Service Desk, Payroll, Finance etc.. Environment: Accomodation, Light, Heat, Power, gas, Office equipments,
Furniture etc...

Documentation: Reports, Designs, Agreements Records, etc.. People: Users, Customers, Who, Roles etc...

Slide 104

Service Asset & Configuration Management

Configuration Management System (CMS)
A set of tools and databases that are used to manage an IT Service Providers Configuration data The CMS also includes information about incidents, problems, known errors, changes & releases The CMS includes tools for collecting, storing, managing, updating and presenting data about all CIs & their relationships

Configuration Management System The Configuration Management System holds all the information for CIs within the designated scope (As discussed previously See Figures as reminder) (Some of these items will have related specifications or files that contain the contents of the item e.g. software, document, photograph. For example, a Service CI will include the details such as supplier, cost, purchase date and renewal date for licences and maintenance contracts and the related documentation such as SLAs and underpinning contracts.)

Slide 105

Service Asset & Configuration Management

Basic concepts (continued)
Secure Libraries Secure Stores Definitive Media Library (S/W CI) Definitive Spares (H/W CI) Configuration Baseline Snapshot

Basic Concepts (continued)

Secure Libraries

A collection of software, electronic or document CIs of known type and status Used for controlling and releasing components throughout the Service Life Cycle (design, build, test, deploy and operate) Access to a secure library is restricted. Libraries are A location that warehouses IT assets Play an important role in the provision of security and continuity (maintain reliable access to equipment of known quality) Secure library in which the definitive authorized versions of all media CIs are stored and protected Secure storage of hardware spares (components and assemblies, maintained at the same level as the comparative systems in the live environment) The configuration of a service, product or infrastructure that has been formally reviewed and agreed upon, that serves as the basis for further activities, that can only be changed through formal change procedures. The current state of a configuration item or an environment (e.g. from a discovery tool), recorded in the CMS as a fixed historical record - also referred to as a footprint

Secure Stores

Definitive Media Library Definitive Spares

Configuration Baseline

Snapshot

Slide 106

SACM - Roles
Service Asset Manager Configuration manager Configuration Analyst Configuration administrator/librarian CMS/tools administrator

Slide 107

Service Knowledge Mgmt System (SKMS)

A set of tools and database that are used to manage knowledge and information The SKMS includes the Configuration Management System, as well as other tools and databases The SKMS stores, manages, updates, and presents all information that an IT Service Provider needs to manage the full life cycle of IT Services

Slide 108

Service Knowledge Mgmt System (SKMS)

Slide 109

DIKW Explanations
Knowledge management is typically displayed within the DataInformation-Knowledge-Wisdom Data is a set of discrete facts about events Information comes from providing context to data or by asking questions on the data Knowledge is composed of the concepts, tacit, experiences, ideas, insights, values and judgments of individuals Wisdom gives the ultimate discernment of the material and guides a person in the application of knowledge
Note : Wisdom can not be managed by Tools

Slide 110

Change Management
Objective
To ensure that changes are recorded, evaluated, authorized, prioritized, planned, tested, implemented, documented & reviewed in a controlled manner.

Scope
Changes to baseline service assets (Service Portfolio) and configuration items (CMDB) across the whole Service Life Cycle.
Changes outside the scope of the service change process should be defined

Objectives To ensure that changes are recorded and then evaluated, authorized, prioritized, planned, tested, implemented, documented and reviewed in a controlled manner. Scope The scope of Change Management covers changes to baseline service assets (Service Portfolio) and configuration items across the whole Service Life Cycle. The organization should define the changes that lie outside the scope of their service change process, such as: Changes with wider impacts than service changes (departmental organization, policies, business operations) would produce RFCs to generate consequential service changes Changes at an operational level such as repair to printers or other routine service components. Figure - typical scope for the service change management process for an IT department and interfaces with business and suppliers at strategic, tactical and operational levels.

Slide 111

Change Management Basic Concepts

Service Change
The addition, modification or removal of an authorized, planned or supported service or component & associated documentation.

Change types
Normal A service change that is not pre-approved. And follow normal change process Standard (Pre-Authorized) A service change pre-authorized by change management with an accepted, established procedure to provide a specific change requirement. For routine tasks Emergency Changes which need to be installed faster than normal process and requires ECAB's approval

Slide 112

Change Management
Process activities - SUMMARY
Planning & controlling Change & release scheduling

Communications
Change decisions & authorization Remediation plans

Measurement & control

Reporting Impact understanding

Continual improvement
See the following diagram.

Process Activities (Overall) Overall change management activities include: 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

Slide 113

Change Management
Process activities (Managing individual changes)
Create & record Changes Review RFC & proposal Assess & evaluate Authorize Plan updates Implementation Review & Close

Process Activities (Individual changes) Typical activities in managing individual changes are:
Create and recording Changes Review RFC and change proposal -Filtering changes (e.g. incomplete, wrongly routed) Assess and evaluate the change

- Establish appropriate level of change authority - Establish relevant areas of interest (who should be involved in CAB) - Assess and evaluate the business justification, impact, cost, benefits and risk of Changes - Request independent evaluation of a change (if required) - Obtaining authorization/rejection - Communicate the decision with all stakeholders, including the initiator of the RFC

Authorize the change

Plan updates Co-ordinate Change implementation Review and Close change

- Collating the change documentation (e.g. baselines and evaluation reports) - Review the change and change documentation - Close the Change when all actions are completed

Slide 114

7 R's For Impact Assessment of RFC

Change Management 7 Rs
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 to build, test & implement the change? What is the RELATIONSHIP between this change & other changes?

Slide 115

Change Authorization Model

Slide 116

Change Management
Key metrics (KPIs)
Reduction in the percentage of unauthorized changes Reduction in the percentage of Unplanned changes Number of Standardized changes Output Measures
# disruptions, incidents, problems/errors Inaccurate specifications & incomplete impact assessment Unauthorized changes % reduction (unauthorized changes or change time, effort & cost) % improvement (time, effort & cost prediction) Rework required

Workloads
Frequency Volume

Process measures
Satisfaction # and % against formal change process Ratio - planned vs. unplanned (urgent, emergency) Ratio - accepted vs. rejected (RFCs) # RFCs (with automated tools) Time to execute a change (initiation - completion) Staff utilization Cost against budget

Key metrics Most of these measures can be broken down by category, organizational division, geography, supplier etc. Output Measures Number of disruptions, incidents, problems/errors caused by unsuccessful changes and releases Inaccurate change specifications (technical, customer, business) and incomplete impact assessment Unauthorized business/customer change by business/IT/customer/user asset or configuration item type e.g. application data Percentage reduction in unauthorized changes or time, effort and cost to make changes and releases (by service, change type, asset type) Percentage improvement in predictions for time, quality, cost, risk, resource and commercial impact Service or application rework caused by inadequate change specification Workloads Frequency of change (by service, business area, etc.) Volume of change. Process measures Peoples satisfaction with the speed, clarity, ease of use Number and percent of changes that follow formal change management procedures Ratio of planned v. unplanned changes (urgent, emergency) Ration of accepted to rejects change requests Number of changes recorded and tracked using automated tools Time to execute a change (from initiation through each stage in the Life Cycle of a change, ending in completion) - By life cycle stage - By service - By infrastructure platform Staff utilization Cost against budget

Slide 117

Change Management
Challenges
Scope of IT & size of organization Number & variety of interfaces

Lack of process integration

Inherent differences & dependencies of all elements Production stability vs. business responsiveness

Standardization, simplification & knowledge sharing

Enabling business change programs Finding champions

Challenges

Almost every business process and service is IT enabled, resulting in a large Customer and stakeholder group that is
involved/impacted by Service Transition Suppliers and Partners) management)

There are many contact interfaces/relationships to manage through Service Transition (Customers, Users, Programs, Projects, There is little integration of processes and disciplines that impact service transition (finance, engineering, human resource The inherent differences and unknown dependencies among legacy systems, new technology and human elements can increase
the risk to change

Achieving a balance between maintaining a stable production environment and being responsive to the business needs for
changing the services

Achieving a balance between pragmatism and bureaucracy Creating an environment that fosters standardization, simplification and knowledge sharing Being an enabler of business change and is, therefore, an integral component of the business change programs. Establishing leaders to champion the changes and improvements
Continued

Slide 118

Change Management
Challenges (continued)
Responsibilities (activities) Collaborative culture

Standard performance measures & measurement methods

Matching delivery & support quality with use Managing impact to time and budget

Stakeholder interest vs. risk management

Managing risk vs. taking risks Effective reporting (risk & governance)

Challenges (continued)

Establishing who is doing what, when and where and who should be doing what, when and where Developing a Culture that encourages people to collaborate and work effectively together (an atmosphere that fosters the cultural
shifts required to get buy-in from people)

Developing standard performance measures and measurement methods across projects and suppliers Ensuring that the quality of delivery and support matches the business use of new technology Ensuring that the service transition time and budget is not impacted by events earlier in the service life cycle (e.g. budget cuts) Understanding the different stakeholder perspectives that underpin effective risk management within an organization Understanding and assess the balance between managing risk and taking risks in affecting the overall strategy of the organization
(potential mismatch between project and business risk)

Evaluating the effectiveness of reporting in relation to risk management and corporate governance

Slide 119

Change Management
Role: Change Manager
RFCs - Receive, log & allocate priority (Reject incomplete & impractical) RFCs - CAB meeting administration CAB - Attendees Convene urgent CAB or ECAB Chair CAB and ECAB meetings After CAB or ECAB: authorize or reject Issue Change Schedules Coordinate building, testing & implementation Update the Change log Review implemented Changes Review outstanding RFCs Analyze Change records (trends / problems) Close RFCs Management reports

Change Manager The main duties of the Change Manager, some of which may be delegated, are listed below: Receive, log and allocate a priority, in collaboration with the initiator, to all RFCs and reject any that are totally impractical Table all RFCs for a CAB meeting, issue an agenda and circulate all RFCs to CAB members in advance of meetings to allow prior consideration Decide which people will come to which meetings, who gets specific RFCs depending on the nature of the RFC, what is to be changed, and peoples areas of expertise Convene urgent CAB or ECAB meetings for all urgent RFCs Chair all CAB and ECAB meetings After consideration of the advice given by the CAB or ECAB, authorize acceptable Changes Issue Change Schedules, via the Service Desk Liaise with all necessary parties to coordinate Change building, testing and implementation, in accordance with schedules Update the Change log with all progress that occurs, including any actions to correct problems and/or to take opportunities to improve service quality Review all implemented Changes to ensure that they have met their objectives. Refer back any that have been backed out or have failed Review all outstanding RFCs awaiting consideration or awaiting action Analyze Change records to determine any trends or apparent problems that occur. Seek rectification with relevant parties Close RFCs Produce regular and accurate management reports

Slide 120

Change Management
Role: Change Authority
Level
Delegated Authority
Anticipated business risk Financial implication Scope of change

Role: Change Advisory Board

Composed according to change
May vary considerably

Suppliers User & Customer views Include:

Problem Manager Service Level Manager Customer Relations staff

Change Authority Formal authorization is obtained for each change from a change authority (a role, person or a group) Figure - An example of authorization hierarchy (Change Authorization Model)
Levels of authorization should be judged by the type, size or risk of the change Delegated authority may exist within an authorization level, e.g. delegating authority to a Change Manager according to pre-set

parameters relating to: - Anticipated business risk - Financial implications - Scope of the change

Change Advisory Board A CAB is an advisory body and requires appropriate terms of reference (meeting regularity, scope of influence, and links to program management) It is important to emphasize that the CAB: Will be composed according to the Changes being considered - May vary considerably in make-up even across the range of a single meeting Should involve suppliers when that would be useful Should reflect both user and Customer views Is likely to include the - Problem Manager - Service Level Manager - Customer Relations staff

Slide 121

Release & Deployment Management

Goal aims to build, test and deliver the capability to provide the
services specified by Service Design Deploy releases into production and establish effective use of the service in order to deliver value to the customer and be able to handover to service operations

Objectives
Establish release & deployment plans Enable building, installation, testing & deployment of release package

Conforming to agreed service requirements

Knowledge transfer - customers & users Skills & knowledge transfer - operations & support staff Minimize unpredicted impact Stakeholder satisfaction

Objectives Establish clear and comprehensive release and deployment plans that enable the customer and business change projects to align their activities with these plans

Enable a release package to be built, installed, tested and deployed efficiently to a deployment group or target environment
successfully and on schedule

That a new or changed service and its enabling systems, technology and organization are capable of delivering the agreed service
requirements (utilities, warranties & service levels) business activities

Ensure that there is knowledge transfer to enable the customers and users to optimize their use of the service to support their Ensure that skills and knowledge are transferred to operations and support staff to enable them to effectively and efficiently
deliver, support and maintain the service according to required warranties and service levels.

Minimize unpredicted impact on the production services, operations and support organization That customers, users and service management staff are satisfied with the service transition practices and outputs e.g. user
documentation and training

Slide 122

Release & Deployment Management

Basic concepts
Big Bang vs. Phased Push vs. Pull Automation vs. Manual

Effective release and deployment management enables the service provider to add value to the business by delivering change, faster and at optimum cost and minimized risk

Basic Concepts Big Bang v. Phased

Big-bang option the new or changed service is deployed to all user areas in one operation, when consistency of service
across the organization is considered important

Phased approach the service is deployed to a part of the user base initially, and then this operation is repeated for
subsequent parts of the user base via a scheduled roll out plan see Figure Push and Pull In order to deploy via push approach, the data on all user locations must be available. Pull approaches do not rest so heavily on accurate configuration data and they can trigger an update to user records. As some users will never Pull a Release it may be appropriate to allow a Pull within a specified time limit and if this is exceeded a Push will be forced e.g. for an anti-virus update.

A Push approach is used where the service component is deployed from the centre and pushed out to the target

locations. In terms of service deployment, delivering updated service components to all users either in big-bang or phased form constitutes push, since the new or changed service is delivered into the users environment at a time not of their choosing.

A pull approach is used for software releases where the software is made available in a central location but users are

free to pull the software down to their own location at a time of their choosing or when a user workstation restarts. The use of pull updating a release over the internet has made this concept significantly more pervasive. A good example is virus signature updates, which are typically pulled down to update PCs and Servers when it best suits the customer, however at times of extreme virus risk this may be overridden by a release that is pushed to all known users. Automation v. Manual Whether by automation or other means, the mechanisms to release and deploy the service components are correctly configured should be established in the release design phase and tested in the build and test stages of the new or changed service.

Automation will help to ensure repeatability and consistency. The time required to provide a well designed and efficient
automated mechanism may not always be available or viable.

If a manual mechanism is used it is important to monitor and measure the impact of many repeated manual activities as
they are likely to be inefficient and error prone. Too many manual activities will slow down the release team and create resource/capacity issues that affect the service levels.

Slide 123

Release Unit
Components of an IT Service that are normally Released together
Example, one Release unit could be a Desktop PC, including Hardware, Software, Licenses etc.. Group of Release Unit = Release package

Slide 124

Release & Deployment Management

Basic concepts (continued)
Testing: Release & Release Packages

ITIL is a Registered Trade Mark of the OGC.

Basic Concepts (continued) Figure left simply shows that you start the build and release from the Infrastructure architecture, through Application architecture, then Service Architecture to Business architecture levels (This is logic dependencies) Figure right Where the LAB/Test phase fits into the high-level flow

Slide 125

SD - Key Principles & Models

Service V model

Service Level Package (SLP) (Service Strategy) 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 (PBA) Service Design Package (Service Design) Document(s) defining all aspects of an IT Service and its Requirements through each stage of its Lifecycle. A Service Design Package is produced for each new IT Service, major Change, or IT Service Retirement. Service Provider Interface (SPI) (Service Strategy) An interface between the IT Service Provider and a User, Customer, Business Process, or a Supplier. Analysis of Service Provider Interfaces helps to coordinate end-to end management of IT Services. Service Level Requirement (SLR) (Service Design) (Continual Service Improvement) 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.
Left-hand side: The specification of the service requirements down to the detailed service design. Right-hand side: Focuses on the validation activities that are performed against the specifications defined on the left-hand side. At each stage on the left, there is direct involvement by the equivalent party on the right.

(It shows that service validation and acceptance test planning should start with the definition of the service requirements customers that sign off the agreed service requirements will also sign off the service acceptance criteria and test plan.) The V-model approach is traditionally associated with the waterfall lifecycle, but is, in fact, just as applicable to other lifecycles, including iterative lifecycles, such as prototyping, RAD approaches. (Within each cycle of the iterative development, the V-model concepts 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 trial and assessment.)

Slide 126

ELS - Early Life Support

When there is a transitioning to operationan overlap is required from the transition team to provide support of the servicesis called Early Life Support

Slide 127

Release & Deployment Management

Role: Release and Deployment Manager
Responsible for planning, design, build, configuration & testing of software & hardware to create a Release package for the delivery of, or changes to, the designated Service.
Manage end-to-end release process Update SKMS and SACM/CMDB Co-ordinate build, test & release teams Progress reports Policy & planning
Package design, build & configuration Release acceptance Rollout planning Release testing Sign-off Communication & training Pre-release audit Hardware installation Software storage & traceability / auditability Release, distribution & installation

Release and Deployment Manager Responsible for managing all aspects of the end-to-end release process. The Release and Deployment Manager will report to the Service Transition Manager as will the Service Test Manager; however these roles should always be undertaken by separate people, i.e. never combined, to ensure that there is always independent testing and test verification. The Release and Deployment manager is responsible for the planning, design, build, configuration and testing of all software and hardware to create the Release package for the delivery of, or changes to, the designated Service. The overall responsibilities are: Managing all aspects of the end-to-end release process Updating the S-KMS and SACM Ensuring co-ordination of build and test environment team and release teams Provides management reports on release progress Service Release and Deployment policy and planning Release package design, build and configuration Release package acceptance including business sign-off Service rollout planning including method of deployment Release package testing to predefined acceptance criteria Sign-off of the release package for implementation Communication, preparation and training Audits of hardware and software prior to and following the implementation of release package changes Installation of new or upgraded hardware Storage and traceability / auditability of controlled software in both centralized and distributed systems Release, distribution and the installation of packaged software.

Slide 128

Release & Deployment Management

Role: Release Packaging & Build Management
Manage the flow of work (establish requirements, design, build, test, deploy, operate and optimize) to deliver applications and infrastructure that meet the Service Design requirements.
Establish final release configuration Build final release delivery Test final delivery Establish & report outstanding known errors & workarounds Provide input to final implementation sign-off

Role: Deployment
Final physical delivery Co-ordinates documentation & communications Plans deployment Technical & application guidance & support Feedback Records SLA metrics

Release Packaging and Build Management Release Packaging and Build management is the flow of work (establish requirements, design, build, test, deploy, operate and optimize) to deliver applications and infrastructure that meet the Service Design requirements. The main duties of the Release Packaging and Build Manager are: Responsibility for establishing the final release configuration (e.g. knowledge, information, hardware, software and infrastructure) Builds the final release delivery Tests the final delivery prior to independent testing Establishes and reports outstanding known errors and workarounds Provides input to the final implementation sign-off process. Deployment Deployment is responsible for the following activities: Responsible for the final physical delivery of the service implementation Co-ordinates release documentation and communications, including training and customer, service management and technical release notes Plans the deployment in conjunction with Change and SKMS and SACM Provides technical and application guidance and support throughout the release process, including known errors and workarounds Provides feedback on the effectiveness of the release Records metrics for deployment to ensure within agreed SLAs.

Slide 129

Service Operation
(Realizing Value)

Slide 130

Service Operation
Objectives
Coordinate and carry out the IT operational activities Work on processes required to deliver and manage services at agreed levels

Manage technology
Conduct, manage & control day-to-day operation of processes Enable Continual Service Improvement

Business Value
Balance between Cost Vs quality Clearer and improved communication

IT operational health management

Manage services at agreed levels through coordination and perform activities to deliver processes Manage the technology that is used to deliver and support service Conducts, manages and controls day-to-day operation of processes (using Service Design and Service Transition)
Enable Continual Service Improvement through monitoring performance, assess metrics and gather data

Slide 131

Service Operation
Business value
The only value that matters, is that perceived by the customer Service Operation is where the value is delivered & judged.
Service Strategy
Where service value is modeled

Service Design & Service Transition

Where design and integration are validated

Continual Service Improvement

Where measures for optimization are identified

Service Operation is where actual value is seen.

Slide 132

SO - Generic Concepts and Definitions

Impact, Urgency & Priority
Impact:
Measure the effect of an Incident, Problem or Change on Business Processes

Urgency:
How quick a solution is required

Priority
Time required for actions to be taken Priority is a function of Impact & Urgency

Impact:

Impact is based on how Service Levels will be affected. A high Impact Incident may have low Urgency, if the Impact will not affect the Business until the end of the financial
year.

Urgency:

Priority:

SLA may state that Priority2 Incidents must be resolved within 12 hours.
FIGURE: Each of the Impact, Urgency and Priority Level should be clearly defined.

Slide 133

SO - Generic Concepts and Definitions

Service Request:
User requesting information for a change or access to an IT Service

Event
Notification created by a service, CI or monitoring tool

Alert
Warning or notice about threshold, change or failure that has occurred

Incident
Unexpected interruption or reduction in quality of an IT service

Problem:
A cause of one or more Incidents.

Service Request: Reset a password provide standard IT Services for a new User. Handled by a Service Desk, nor RFC necessary Event: Caused by deviation to the performance of the infrastructure or the delivery of the service and will regularly require Incidents to be logged. Alert: Created and controlled by System Management tools and the Event Management Process. Incident:

Failure of a CI that has not yet impacted service is also an Incident.

Problem:

usually known at the time a Problem Record is created, and the Problem Management Process is responsible for further
investigation.

Slide 134

SO - Generic Concepts and Definitions

Workaround:
Temporary means to resolve issues or difficulties

Known Error
A Problem that has a documented Root Cause & a Workaround

Known Error Database

Storage for previous knowledge on requests and known errors

Workaround: For example by restarting a failed Configuration Item. Workarounds for Problems are documented in Known Error Records. Workarounds for Incidents that do not have associated Problem Records are documented in the Incident Record. Known Error: Known Errors are created and managed throughout their Lifecycle by Problem Management. Known Error Database: A database containing all Known Error Records.

Slide 135

SO - Generic Concepts and Definitions

Role of Communication
Issues can be prevented or mitigated Must have intended purpose or resultant action Clear audience, actively involved in determining need for communication Simple, formal communication policy

Note that there is no definitive medium for communication, nor is there a fixed location or frequency. There should therefore be a policy around communication within each team or department and for each process. Although this should be formal, the policy should not be cumbersome or complex. Types of communication

Meetings Email SMS Pagers VOIP Document sharing utilities

Slide 136

SO - Key Principles & Models

IT Services vs. Technology Components
IT Services
How customers/users experience services

Technology Components
How IT components and systems are managed to deliver the services.

Both views are necessary when delivering services.

Differences:
Stem from Management culture Leads to Low maturity

IT Services:

Customers/Users dont worry about the details of what technology is used to manage services. Only concern is that the services delivered as required and agreed.
Technology Components:

Different teams or departments manage technology thus each should focus on achieving good performance and
availability of its systems. Organizations should focus on both business requirements and how they will deliver it as well as what services they support on internal systems to deliver value.

Slide 137

Balances in Service Operation

Internal versus external factor Stability versus Responsiveness Quality of Service versus Cost of Service Reactive versus Proactive

Slide 138

SO - Key Principles & Models

Stability vs. Responsiveness
Stability:
Develop & refine standard IT management techniques & processes Service components needs to be available & perform consistently

Responsiveness:
Ability to respond to changes without impact to other services Take care when agreeing to required changes
Consider ALL requirements and impact of delivering change

For example: a Business Unit requires additional IT Services, more capacity and faster response times.

To respond to this type of change without impacting other services is a significant challenge. Many IT organizations are unable to achieve this balance and tend to focus on either the stability of the IT Infrastructure or the
ability to respond to changes quickly.

Slide 139

SO - Key Principles & Models

Quality of Service vs. Cost of Service
Achieving a balance will ensure delivery of the level of service necessary to meet Business requirements at an optimal cost

Graph: An increase in the level of quality usually results in an increase in the cost of that service, and vice versa.

Slide 140

SO - Key Principles & Models

Reactive vs. Proactive
Reactive does not act unless prompted by external driver Proactive always looking for ways to improve current situation
Continually scan, looking for potentially impacting changes Seen as positive behavior Can be expensive

Better to manage proactively Achieve balance between reactive and proactive, requires:
Formal, Integrated Problem and Incident Management processes Ability to prioritize technical faults and demands Data from Configuration and Asset Management Ongoing involvement from Service Level Management in Service Operations

Proactive achievement depends on: Maturity Culture Role of IT, influence on strategy and tactics Level of Integration of processes and tools Maturity and scope of Knowledge Management Achieve Balance Ability to prioritize technical faults and demands needs to be done during Service Operation, but the mechanisms need to be put in place during Service Strategy and Design. Data from Configuration and Asset Management provides data where required, saving projects time and making decisions more precise

Slide 141

SO Processes
Incident Management
Event Management Request Fulfillment Problem Management Access Management

Slide 142

Incident
Def: 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

Incident Management should be Reactive (responding to Incidents) Concerned with restoration of Customer service (not cause) Scope of Incidents Incidents include not only hardware and software errors, but also Service Requests. Service Requests Every Incident not being a failure in the IT Infrastructure Request from a user for support, delivery, standard change, information, advice or documentation, not being a failure in the IT infrastructure.

Slide 143

Incident Management
Objectives
To Restore normal service operation as quickly as possible and Minimize the adverse impact on business operations Maintain optimal levels of service quality & availability

Scope
Any event which disrupts, or could disrupt a service Logged / reported requests by technical staff Not all events are incidents

Scope:

Includes Events communicated directly by users or tools or technical staff Not all Events are Incidents. Many classes of Events are not related to disruptions at all, but are indicators of normal operation or are simply informational

Slide 144

Incident Management
Basic Concepts
Incident Models
Agreed method of predicting steps to handle an incident Ensures standard incidents handled in pre-defined path
Evidence preservation activities

Timescales & thresholds Escalation Procedures Responsibilities

Timescales
Must be agreed for all handling stages
Based on response and resolution targets SLA, captured as targets OLA Tools should be used to automate timescales and escalate Support groups must be informed

Major Incidents
Shorter timescales and greater urgency Incident with higher impact or priority potential business impact

Incident Models: Includes:

Actual steps, and the order they are to done in (with dependencies) Responsibilities Timescales and thresholds Escalation Procedures Evidence preservation activities

Slide 145

Incident Management
Process Activities (Basic Incident Flow)

PROCESS ACTIVITIES Incident Identification Work cannot begin until incident is known Logging All incidents fully logged, date/time stamped Relevant information recorded

Categorization Record correct type of call Establish trends for Problem Management, Supplier Management Organizations are Unique difficult to give generic guidance Prioritization Agree and allocate appropriate prioritization codes Determined by impact and urgency Clear guidance for all support staff to determine correct urgency and impact levels Initial Diagnosis Carried out by the Service Desk Attempt to discover full symptoms and exactly what went wrong Diagnostics scripts and known error information can be used Escalation Unable to resolve incident within agreed service hours High priority notification to managers

Functional Escalation Escalate to the second level support Hierarchic Escalation investigation, recovery & resolution steps take too long Escalates to IT Managers, normally
Priority 1 Incidents

Exact levels to be agreed, based on SLA targets, embedded in tools

Investigation & Diagnosis Determine the nature of request Support groups to determine what's gone wrong, all activities documented in record to maintain historical information

Actions include:

Establish what has gone wrong Understand order of events Confirm impact, and number of users Identify triggering events Knowledge searches of previous occurrences
Resolution & Recovery

Identify resolution apply and test Specific actions involved:

- Ask user to do directed activities - Service Desk implement centrally or remotely - Support groups implement specific recovery actions - Third-party supplier / maintainer resolve fault

Sufficient testing must be performed ensure recovery action is complete Incident record must be updated with relevant information and details
Closure

Service Desk check incident fully resolved, users satisfied, agreed to close Service Desk also to:
- Closure Categorization - User Satisfaction Survey - Incident Documentation - Ongoing or recurring Problem? - Formal Closure

Rules for re-opening

Slide 146

Incident Management
Metrics
Monitor and report to determine effectiveness & efficiency
total numbers of Incidents breakdown of incidents at each stage size of current incident backlog number & percentage of major incidents average cost per Incident etc

Challenges
Ability to detect incidents early Ensuring all incidents are logged Availability of information: Problems & Known Errors Integration into:
relationships between CIs & history SLM: to correctly assess impact and priority SLM: use defined escalation procedures

Metrics How?

total numbers of Incidents breakdown of incidents at each stage size of current incident backlog number and percentage of major incidents average cost per Incident etc
Challenges: Ability to detect incidents early

Ensuring all incidents are logged - Convincing all staff Availability of information about Problems and Known Errors - enable Incident Management staff to learn from previous Incidents Integration - assist Incident Management to correctly assess the impact and priority of Incidents

Slide 147

Incident Management
Role: Incident Manager
Drive efficiency & effectiveness Produce management information Manage work of Incident support staff (1st & 2nd line) Monitor effectiveness of process & recommend improvement Develop & maintain Incident Management systems Manage Major Incidents Develop & maintain the process & procedures

Slide 148

Event Management
Objectives
Detect & analyze events Determine appropriate control actions Automate Operations Management activities Provide entry point for execution of processes & activities Provide a basis for Service Assurance and Reporting; and Service Improvement Compare actual performance & behavior vs. design standards & SLAs

Basic Concepts
Different types of events:
Indicate regular operation Indicate an exception Indicate unusual, but not exceptional, operation

Objectives

To detect and analyze events make sense of events To determine appropriate control action basis for Operational Monitoring and Control To automate Operations Management activities communicate operational information Warnings Exceptions To provide entry point for execution of processes and activities To compare actual performance and behavior against design standards and SLAs
Basic Concepts Different types of events:

Indicate regular operation Notify when scheduled workload has completed User logged into application Email reached intended recipient Indicate an exception User attempts login with incorrect password Device CPU above utilization threshold PC scan indicated unauthorized software Indicate unusual, but not exceptional, operation Situation may require close monitoring

Slide 149

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

Slide 150

Service Request
A request from a User for information, or advice, or for a standard change or for Access to an IT Service Service Requests are usually handled by Service Desk, and do not require an RFC to be submitted

Slide 151

Request Fulfillment
Objectives
Provide channel to request & receive standard services Provide information about availability & obtaining services Source & deliver components of requested services Assist with general information Responsible for frequently occurring changes where risk and cost are low

Basic Concepts
Request Models
Predefined process flow - similar to incident models Standard Change

Role
Service Desk & Incident Management staff handles Service requests
Eventual fulfilment of requests will be undertaken by appropriate Service Operation team(s) or departments and/or by external suppliers, as appropriate

Basic Concepts

Service Requests will frequently recur, so a predefined process flow (a model) can be devised to include the stages needed to fulfil
the request,

Service Requests will usually be satisfied by implementing a Standard Change

Role

The ownership of Service Requests resides with the Service Desk, which monitors, escalates, dispatches and often fulfils the user
request.

Slide 152

Problem
Unknown Root cause of one or more Incidents
The cause is not usually known when a Problem is being logged , and the Problem Management Process is responsible for further investigation

Problem Unknown underlying cause of one or more Incidents A problem is a condition often identified as a result of multiple incidents that exhibit common symptoms Problems can also be identified from a single significant Incident, indicative of a single error, for which the cause is unknown, but for which the impact is significant. Known Error is a condition identified by successful diagnosis of the root cause of the problem, and a subsequent development of a work-around or a solution

Slide 153

Problem Management
Goal To prevent problems and resulting incidents from happening, to eliminate recurring incidents and to minimize the impact of incidents that cannot be prevented Scope Four Ps of Service Management Objectives
Manage the lifecycle of all problems Prevent problems & resulting incidents Eliminate recurring incidents Minimize impact of incidents that cannot be prevented

Slide 154

Problem Management
Basic Concepts
Problem Models
Incidents may re-occur because of dormant or underlying problems Creating Known Error record in the KEDB ensure quicker diagnosis Similar to Incident Models

Known Error

(Previous discussion)

Understanding the root cause of an issue/failure, not necessarily having the solution, and recording it for future reference to aid in restoring services more efficiently

Known Error Database (Previous discussion)

Storage for previous knowledge on requests and known errors, and how they were resolved to allow quicker diagnosis if they occur

Slide 155

Workaround
Reducing or eliminating the Impact of an Incident or Problem for which a full Resolution is not yet available Workarounds for problems are documented in Known Error Database (KEDB)
Workarounds for Incidents that do not have associated problem records are documented in the Incident Database

Slide 156

Problem Management
Role: Problem Manager
Liaison with all problem resolution groups Ownership & protection of the Known Error Database Gatekeeper for the inclusion of all Known Errors Formal closure of all Problem records Liaison with suppliers, contractors etc Arrange, conduct, document & follow-up all review activities

liaison with all problem resolution groups to ensure swift resolution of problems within SLA targets

liaison with suppliers, contractors etc to ensure that third parties fulfil their contractual obligations, especially with regards to resolving problems and providing problem-related information and data

Slide 157

Access Management
Objectives
Provide user rights to enable use of a service or group of services Enable the execution of policies and actions

Basic Concepts
Access
Level & extent of functionality or data that a user can use

Identity Rights

Unique distinguishing information of an individual, verifies status

Actual settings to allow access (privileges) Access to set of services or group of users, not individual access to separate services Tool to manage access & rights

Services of Service Groups

Directory Services

Slide 158

Access Management
Role
Service Desk
Request access to a service Acts as initial filter Checks validity Performs simple access activities, escalates others

Technical & Applications Management

Service Design Service Transition Service Operations

IT Operations Management
Standard Operations Procedures (SOPs) Reports

In its simplest term access management is an overlap of Security Management and Availability Management. So role definition for these two areas is left to these areas. It is unlikely that an Access Manager person needs to be appointed, but the policies, practices and procedures must be defined and communicated to other groups and individuals. The Service Desk acts as an initial barrier for access management. It will check validity against authority tables and if passed the Service Desk can then actually grant accesses for simple, lower levels; but will escalate to specific functional groups any access to critical systems or sensitive areas within the company infrastructure. Technical and Applications Management play different parts for Access Management throughout the Service Lifecycle.

Service Design ensure simplified controls are built in and define abuse counter-measures Service Transition test the designed controls Service Operation- carry out access management for systems within their control area and deal with access related Incidents and
Problems The IT Operations manager must ensure that SOPs cater for access management issues. They will also collate access data for reporting purposes (including actual access & rejected requests)

Slide 159

Functions

Slide 160

Functions
Syllabus
Service Desk
Role Objectives Organizational Structures Staffing Metrics

Role, objectives & organizational overlap:

Technical Management function Application Management function IT Operations Management function
IT Operations Control Facilities Management

Slide 161

What are Functions ?

A function is a logical concept That refers to the people and automated measures
That execute A defined process An activity Or a combination of processes or activities

In larger organizations a function may be broken up and performed by several departments, teams and groups, or it may be embodied within a single organizational unit

Slide 162

Functions in Service Operation

TMF Technical Management Function Custodian of technical knowledge and expertise related to managing the IT AMF Application Management Function

Custodian of technical knowledge and expertise related to managing applications

Overlaps with Application Development

ITOMF IT Operations Management Function

Responsible for the daily operational activities needed to manage the IT infrastructure Has IT Operation control & Facilities Management Overlaps with TMF & AMF

SDF - Service Desk Function SPOC

Focuses on service restoration

Slide 163

Service Desk
Role
SPOC for dealing with services Increase:
accessibility -> single point of contact for users quality and turnaround times of requests

Improve:
customer service, perception and satisfaction teamwork and communications

Reduce negative business impact Provide more meaningful management information

SPOC for IT users on a day-by-day basis A functional unit:

Made up of staff dealing with service events, via telephone calls, web interface, or automatically reported infrastructure events.
SPOC = Single Point of Contact

Slide 164

Service Desk
Objectives
Prime aim restore the 'normal service' to the users as quickly as possible To log all relevant requests

To providing first-line support

To resolving incidents To escalate

To keep users informed

To close all resolved requests

Restoration of service

SD will do anything to allow the user to return to work satisfactorily Logging calls categorization and prioritization codes will be allocated to the call First-line support
Escalation

Proper investigation and diagnosis requests unable to resolve

Slide 165

Service Desk
Organizational Structure
Local Service Desk for local business needs and onsite support

Local Service Desk Co-located in/around user community Aids communication, clearly visible Inefficient and expensive Staff waiting to deal with incidents
Disadvantages:

Language and cultural / political differences Time Zones Specialized groups Specialized services exist needing specialists Status of users (VIP)

Slide 166

Service Desk
Organizational Structure (continued)
Centralized Service Desk

Centralized Service Desk Reduce number of service desk by merging into one location More efficient and cost effective fewer overall staff for higher volumes Lead to higher skills levels frequency on occurrence of events Need to maintain some local presence physical support

Slide 167

Service Desk
Organizational Structure (continued)
Virtual Service Desk

Virtual Service Desk Personnel spread or located in a number of geographical or structural locations

Technologies and corporate support tools Meet user demand through: Home working Secondary support groups Off-shoring Outsourcing Safeguards required to ensure consistency and uniformity in service quality

Slide 168

Service Desk
Organizational Structure (continued)
Follow the Sun
Combination of geographically dispersed service desks
24hr service at relatively lower cost

Also handles own incidents during normal work times Safeguards must be addressed, namely:
Common processes Tools Shared databases Culture

For example, a Service Desk in India handles calls during office hours and at the end of this period they hand over responsibility for any open incidents to a European based desk. That desk will handle these calls alongside its own incidents during its standard day and then hand over to a USA based desk which finally hands back responsibility to the Asia-Pacific desk to complete the cycle.

Slide 169

Staffing
Technically Unskilled Technically Skilled Technically Experts Super User

Slide 170

Service Desk
Metrics
Evaluate performance of SD on regular intervals Assess health, maturity, efficiency and effectiveness Analysis and detailed metrics such as:
First-line resolution rate Average time to resolve an incident Average time to escalate an incident Average time to review and close a resolved call The number of calls broken down by time of day and day of week, Percentage of customer or user updates conducted within target times

Customer Satisfaction Survey

Slide 171

Technical Management Function (TMF)

Role
Custodian of technical knowledge and expertise
Provides actual resources to support Service Management Life Cycle

Ensure balance between skill level, utilization and cost

Provide guidance to Operations on how to best carry out ongoing operations of technology

Integration of Application Management Life Cycle into Service Management Life Cycle

Objectives
Assist planning, implementing,maintaining and supporting of a stable infrastructure through:
Well designed technical topology Use of adequate technical skills Swift use of technical skill

Role Technical Management plays a dual role: Custodian of technical knowledge and expertise:

Ensures knowledge required to design, test, manage and improve services is identified, developed and refines Provides actual resources to support Service Management LifeCycle Ensures resources are effectively trained and developed to design, build, transition, operate and improve technology to
deliver services Objectives

Assist planning, implementing and maintaining of a stable infrastructure through: Well designed and highly resilient, cost-effective technical topology Use of adequate technical skills to maintain the technical infrastructure Swift use of technical skills to speedily diagnose and resolve any technical failures

Slide 172

Application Management Function (AMF)

Role
Custodian of technical knowledge and expertise
Provides actual resources to support Service Management LifeCycle

Ensure balance between skill level, utilization and cost

Provide guidance to Operations on how to best carry out ongoing operations of applications

Objectives
Help identify functional and manageability requirements and assist in design and deployment and ongoing support and improvement of applications through
Good design, cost effectiveness and resilience Availability of required functionality Adequate technical skills Swift use of technical skills

Role Application Management plays a dual role:

Custodian of technical knowledge and expertise Ensures knowledge required to design, test, manage and improve services is identified, developed and refined
Provides actual resources to support Service Management LifeCycle deliver services

Ensures resources are effectively trained and developed to design, build, transition, operate and improve technology to
Objectives Assist planning, implementing and maintaining of a stable infrastructure through:

Well designed and highly resilient, cost-effective technical topology Use of adequate technical skills to maintain the technical infrastructure Swift use of technical skills to speedily diagnose and resolve any technical failures

Slide 173

IT Operations Management (ITOMF)

IT Operations Control overseas execution and monitoring
Ensures that routine operational tasks are carried out Provide centralized monitoring and control activities Uses an Operations Bridge or Network Operations Centre

Facilities Management
Management of the physical IT environment (Data Centers, Computer rooms etc..)

Role
Executes activities and performance standards Add value to the business Perform ongoing activities

Perform ongoing activities and procedures required: to manage and maintain the IT infrastructure to deliver and support Services at the agreed levels. Operations Control overseas execution and monitoring Console Management - defines central observation and monitoring to exercise monitoring and control activities Job Scheduling - management of routine batch jobs or scripts Backup and Restore for Technical and Application Management teams or users Print and Output management - collation and distribution of all centralized printing or electronic output Performance of maintenance activities for Technical or Application Management teams or departments Facilities Management managing physical IT environment, coordinates large scale consolidation projects Executes activities and performance standards defined during Service Design and tested during Service Transition. Stability of infrastructure and consistency is primary concern Part of the process of adding value to the different lines of business and to support the value network

Slide 174

Functions
Objectives

- IT Operations Management

To maintain Status Quo to achieve stability To regularly scrutinize and improve services The swift application of operational skills
to diagnose and resolve failures

Slide 175

Functions - Organizational Overlap

The functions given in the diagram are necessary to manage the steady state operational IT environment. Service Desk primary point of contact for users separate from the other Service Operation functions Why? SD will utilise the functions of say technical management or application management depending on the type of call Technical Management provides detailed technical skills and resources to support the ongoing operation of the IT Infrastructure Even if activities are part of Technical Management, the staff who performs these activities are logically part of IT Operations IT Operations Management Overlaps with Technical and application management IT Operations Control ensures that routine operational tasks are carried out. Facilities Management Manage the physical IT environment Application Management managing applications throughout their lifecycle. Even if activities are part of Application Management, the staff who performs these activities are logically part of IT Operations

Slide 176

Continual Service Improvement

Slide 177

Continual Service Improvement

Goals
To continually align & re-align IT services to changing business needs by identifying & implementing improvements to IT Services that support Business Processes. CSI is about looking for ways to improve:
process effectiveness, efficiency cost effectiveness

Consider the following saying about measurements and management:

You cannot manage what you cannot control. You cannot control what you cannot measure. You cannot measure what you cannot define.
THUS: Define Measure Control Manage!!! If ITSM processes are not implemented, managed and supported using clearly defined goals, objectives, and relevant measurements that lead to actionable improvements, the business will suffer. Depending upon the criticality of a specific IT Service to the business, the organization could lose productive hours, experience higher costs, loss of reputation or, perhaps, even a business failure. That is why it is critically important to understand what to measure, why it is being measured and carefully define the successful outcome.

Slide 178

Continual Service Improvement

Objectives
Review, analyze & make recommendations on improvement opportunities in each lifecycle phase:
Service Strategy Service Design Service Transition Service Operations

Review & analyze Service Level Achievement results Identify & implement individual activities to improve IT Service quality Improve cost effectiveness Ensure applicable quality management methods are used to support continual improvement activities

Slide 179

Continual Service Improvement

Business Value
Increased organizational competency Integration between people & processes

Reduction of redundancy increases business throughput

Minimize lost opportunities Assure regulatory compliance which minimize costs & reduce risk Ability to react to change rapidly

CSI is the mechanism to ensure that the work of Strategy, Design, Transition and Operations is not wasted. There are too many projects to list (and perhaps weve been involved in some) where excellent lead up work is slowly eroded and after 6 months, we are back doing what we used to do. Why does this happen? Most likely because the initial design didnt include continual and ongoing review and improvement. CSI is like the maintenance required after you buy a car, a boat, a house, a motorbike or even a push bike. Without ongoing maintenance the initial investment made in these assets eventually leads to broken assets, missed opportunity. Timing is also crucial. Maintenance left too late costs more than acting at the pre-specified times. With our cars we are told to get a car service at particular points. Failure to adhere to those rules leads to higher cost and loss of warranty. So CSIs value to the business lies in the payback (ROI, VOI) on investment made to optimize service delivery. This in turn has a flow on effect in the ability to take advantage of opportunities, present a competent image to the market and importantly react to change in corporate direction due to internal or external influences.

Slide 180

CSI - Key Principles & Models

Quality: PDCA Model
The four key stages of the Deming cycle are 'Plan, Do, Check, Act' after which a phase of consolidation prevents the 'Circle' from rolling backwards.

The four key stages of the cycle are 'Plan, Do, Check, Act' after which a phase of consolidation prevents the 'Circle' from 'rolling back down the hill'. Our goal in using the Deming Cycle is steady, ongoing improvement. The Deming Cycle is critical at two points in CSI:

Implementation of CSIs and for the application of CSI to services and service management processes. At implementation, all four stages of the Deming Cycle (Plan, Do, Check, Act) are used. With ongoing improvement, CSI draws on the Check and Act stages to monitor, measure, review and implement
initiatives. The cycle is underpinned by a process-led approach to management where defined processes are in place, the activities are measured for compliance to expected values and outputs are audited to validate and improve the process.

Slide 181

CSI - Key Principles & Models

Quality: PDCA Model
Planning for Improvement Initiatives (Plan)
Establishes goals for improvement (Gap analysis)

Implementation of Improvement Initiative (Do)

Development & implementation of a project

Management Processes (Check)

Compare implemented improvements to the measures of success

Improvement (Act)
Implementing the actual Service and Service Management process improvements

Planning for Improvement Initiatives (Plan) gap analysis -> definition of action steps to close any gaps-> establish and implement measures to assure that the gaps have been closed-> and benefits achieved Implementation of Improvement Initiative (Do) close the identified gaps-> implementation of the improvement to Service Management processes->Monitor, Measure and Review Services Management Processes (Check) Monitor, measure and review that the CSI objectives and plans are being achieved Improvement (Act) - This stage requires implementing the actual Service and Service Management process improvements. A decision to keep the status quo, close the gap or adding necessary resources needs to be made to determine if further work is required to close remaining gaps, allocation of resources necessary to support another round of improvement. Project decisions at this stage are the input for the next round of the PDCA cycle, closing the loop as input in the next Plan stage. Too many people and too many organizations are looking for the big-bang approach to improvements. It is important to understand that a succession or series of small planned increments of improvements will not stress the infrastructure as much and will eventually amount to a large amount of improvement over time.

Slide 182

CSI - Key Principles & Models

CSI Model 6 Step Summary
Embrace vision
IT & Business strategy alignment

Assess current situation (snapshot of where organization is right now)

Business, organization, people, process & technology

Understand & agree on improvement priorities

Specific goals & manageable timeframe

Detail CSI plan to achieve higher quality

Develop & implement ITSM processes

Verify that measurements & metrics are in place

Ensure achievement & compliance

Ensure that the momentum for quality improvement is maintained

Embedding changes (&culture)

The improvement process can be summarized in six steps: The vision should align the business and IT strategies. This baseline assessment is an analysis of the current position in terms of the business, organization, people, process and technology. The full vision may be years away but this step provides specific goals and a manageable timeframe. Detailing the CSI plan to achieve higher quality Service provision by implementing ITSM processes and developing Verify that measurements and metrics are in place to ensure that milestones were achieved, processes compliance is high, and business objectives and priorities were met by the level of service. Assuring that changes become embedded in the organization.

Slide 183

CSI - Key Principles & Models

CSI Model

Slide 184

CSI - Key Principles & Models

CSI Elements Business Value
Role of measurement for Continual Service Improvement
Service Measurement is a key process of CSI, responsible for measurement, analysis and reporting on IT Services and ITSM results.

Why Measure?
To To To To validate direct justify intervene

3 Questions:
Why are we monitoring & measuring? When do we stop? Is anyone using the data?

WHY To validate - monitoring and measuring to validate previous decisions To direct - monitoring and measuring to set direction for activities in order to meet set targets. It is the most prevalent reason for monitoring and measuring To justify - monitoring and measuring to justify, with factual evidence or proof, that a course of action is required To intervene - monitoring and measuring to identify a point of intervention including subsequent changes and corrective actions 3 QUESTIONS The four basic reasons to monitor and measure lead to three key questions: Why are we monitoring and measuring?, When do we stop? and Is anyone using the data? To answer these questions, it is important to identify which of the above reasons is driving the measurement effort. Too often, we continue to measure long after the need has passed. Every time you produce a report you should ask, Do we still need this?

Slide 185

CSI - Key Principles & Models

CSI Elements Baselines
An important beginning point for highlighting improvement is to establish baselines as markers or starting points for later comparison
Baselines are also used to:
establish an initial data point to determine if a Service or process needs to be improved.

It must be established at each level:

strategic goals and objectives, tactical process maturity operational metrics and KPIs

If it is not initially established:

The first measurement efforts will become the baseline.

Slide 186

CSI - Key Principles & Models

Metrics
There are three types of CSI metrics:
Technology metrics
Component & application based (performance, availability, etc.)

Process metrics
KPIs & activity metrics (process health)

Service Metrics
End-to-end

KPIs answers quality, performance, value and compliance of following the process CSI would use these metrics as input in identifying improvement opportunities for each process.

Technology metrics these metrics are often associated with component and application based metrics such as performance, availability etc. Process metrics these metrics are captured in the form of CSFs, KPIs and activity metrics for the Service Management processes. These metrics can help determine the overall health of a process. Service Metrics these metrics are the results of the end-to-end service. Component metrics are used to compute the Service Metrics.

Slide 187

CSI Processes
7 Step Improvement Process

Steps 1 and 2 strategic, tactical and operational goals to support measuring and CSI activities:

Defines service management processes Defines existing technology and capability iterative during the rest of the activities

Steps 3, 4 and 5: Relates to gathering data, processing the data into the required format and analyzing the results to look for answers to questions Steps 6 Takes the knowledge and present it, turn it into wisdom by utilizing:

Steps 7

reports monitors action plans reviews evaluations and opportunities.

Use the knowledge gained to optimize, improve and correct services.

Slide 188

Q&A

Slide 189

Mock Test

Slide 190

Thank You