A Process is a structured set of activities designed to accomplish a specifc objective.

It takes
one or more inputs and turns them into defned outputs. A process includes all of the roles,
responsibilities, tools, and management controls required to reliably deliver the outputs.
Processes are closed-loop systems because they have the following characteristics:
Provide change and transformation towards a goal
Use feedback for self-reinforcing and self-corrective action
It is important to consider the entire process and how one process fts into another.
Characteristics of Processes
You will fnd the following characteristics in processes:
Measurable
Specifc results
Respond to a specifc event or are triggered at specifc times
Processes are measurable and driven by performance. Managers want to measure cost, quality,
and other factors, while practitioners are concerned with duration and productivity.
The reason a process exists is to deliver a specifc result. This result must be individually
identifable and countable. For example, changes can be counted, but it is impossible to count
how many Service Desks were completed.
Every process delivers a primary result to a customer or stakeholder.
A process can be ongoing or iterative, and it should be able to trace to a specifc trigger.
Functions are often mistaken for processes.
Description of Generic Process Elements
The Process Control and Inputs feed into the Central Process area. These combined with
Process Enablers feed into Process Outputs.
Process section
Process Activities: Process information is gathered, reported, and recorded.
Process Metrics: Help determine the overall health of a process. Key Performance
Indicators (KPIs) can help answer questions about quality, performance, value, and
compliance in following the process.
Process Roles: Include all of the diferent groups or individuals that are necessary to
complete a process, such as technical management, applications management, change
managers, change approvers, change review boards, and so on, depending on each
process.
Process Procedures: High-level, overall framework for following the business process.
Process Work Instruction: Specifc details on how to accomplish or produce something by
following the process.
Process Improvement: Identifying and delivering improvements to the process in critical
business areas across manufacturing and relevant divisions.
Process Inputs and Outputs
Inputs are the events or information that either triggers or is necessary to complete a
process. Inputs might include the error information for problem, event, or incident or the
necessary information to complete and approve a change, or other functions.
Outputs include reports and the actual change that needs to occur or the resolution of an
incident or the completion of a Root Cause Analysis for problem management.
Process Enablers:
Process Resources: People, fnances, information, hardware, and software used to
enable the business process.
Process Capabilities: Roles played by each of the various process resources.
Process Control:
Process Owner: Focuses on the fow and structure of an assigned process, and carefully
monitors and manages the process to ensure that it can be continually improved.
Process Objectives: What the process needs to accomplish. For instance, the Incident
Management process is intended to restore normal service operation. That is its
objective.
Process Documentation: A reference document for a specifc process or a collection of
processes that provides guidance for process participants in how to handle the process.
Process Feedback: Managing the changes that stem from information generated from
feedback of the process outputs.
Generic Process Elements: Description
Data enters the process, is processed, and produces output. The outcome is measured and
reviewed.
A process is always organized around a set of objectives. The main outputs from the process
should be driven by the objectives and should always include process measurements (metrics),
reports, and process improvement.
Each process should have an owner who is responsible for
Maintaining the process
Improving the process
Ensuring that the process meets the objectives set for it
The objectives of any IT process should be defned in measurable terms and should be
expressed in terms of business benefts and underpinning business strategy and goals.
Service Design should assist each process owner to ensure the following objectives:
All processes use standard terms and templates.
All processes are consistent.
All processes integrate with each other to provide end-to-end integration across all areas.
If the activities of the process occur with a minimum use of resources, the process is considered
efcient. Process analysis, results, and metrics should be incorporated in regular management
reports and process improvements, and process improvement feedback.
Version 3 ITIL books focus on the following items:
Sets of processes
The lifecycle of a service
Working with defned processes is the foundation of ITIL. By defning the activities of an
organization, the necessary inputs, and which outputs will result from the process, it is possible to
work more efciently and efectively.
Measuring and steering the activities increases this efectiveness.
Finally, by adding norms to the process, it is possible to add quality measures to the output
The Process Model
A process model enables understanding and helps to articulate the distinctive features of a
process.
Process control can be defned as the activity of planning and regulating a process, with the
objective of performing a process in an efective, efcient, and consistent manner. Processes
should be defned, documented, and controlled. After they are under control, they can be
repeated, and they become manageable.
Degrees of control over processes can be defned. Then process measurement and metrics can
be built in to the process to control and improve the process
ITIL Functions are:
Units of organizations specialized to perform certain types of work
Responsible for specifc outcomes
Self-contained, including, for example:
o Capabilities
o Resources necessary for performance and outcomes
Capabilities include work methods that are internal to the functions. Sample functions include
Technical Management and the Service Desk. These functional units facilitate multiple processes.
Functions have their own body of knowledge, which is accumulated from experience of the
functional organization.Functions provide structure and stability to organizations
A role refers to a set of connected behaviors or actions that are performed by a person, team, or
group in a specifc context. The scope of their role and what triggers them to play that role are
defned by the relevant process and agreed upon by their line manager.
Note: A technical management department can perform the role of Problem
Management when diagnosing the root cause of incidents. This same department
could also function in other roles at diferent times. For example, the department
might assess the impact of changes (Change Management role) or manage the
performance of devices under their control (Capacity Management role).
The ITIL Library has the following components:
The ITIL Core: Best practice guidance applicable to all types of organizations who
provide services to a business.
The ITIL Complementary Guidance: A complementary set of publications with guidance
to specifc to industry sectors, organization types, operating models, and technology
architectures
Service Design: starts with a set of new or changed business requirements and ends with the
development of a business solution designed to meet the documented needs of the business
Service Transition: sets customer expectation on how the performance and use of the new or
changed services can be used to enable business change, and reduces the known errors and
minimizes the risks from transitioning the new or changed services into production. This is where
change and release management occur and where the actual services are implemented
Service operations: Coordinates the activities and processes required to deliver, support and
manage services at agreed upon levels to business users and customers
CSI aligns and re-aligns IT Services to changing business needs by identifying and
implementing improvements to IT services, while striving to make processes more efective and
cost efcient
Service Strategy is a strategic plan designed to achieve defned objectives.
A healthy business model will describe the defned objectives of the business. Without a clear
strategy to accomplishing the objectives that can be clearly stated to a customer, however, there
is little increase in value to the customer. The Service Strategy defnes a clear path to delivering
value to the customer.
Customers are looking for ways to strategically improve their business models. They want
solutions that will break through existing performance barriers. They want to increase
performance without an increase in cost. This kind of improvement allows an opportunity for
providers to ofer a solution through improved products and services
Purpose of Service Strategy
Service providers must be able to think and act in a strategic manner.
The achievement of strategic goals or objectives requires the use of strategic assets.
Service Strategy shows how to transform service management into a strategic asset.
Technical knowledge of IT is necessary but not sufcient.
Strategy requires knowledge from the disciplines such as operations management,
marketing, fnance, information systems, organizational development, systems dynamics,
and industrial engineering
Service Strategy Objectives
Service Strategy seeks to answer the questions:
What services should we ofer and to whom?
How do we diferentiate ourselves from competing alternatives?
How do we truly create value for our customers?
How do we capture value for our stakeholders?
How can we make a case for strategic investments?
How can fnancial management provide visibility and control over value creation?
How should we defne service quality?
How do we choose among diferent paths for improving service quality?
How do we efciently allocate resources throughout a portfolio of services?
How do we resolve conficting demands for shared resources?
Service Model
A Service Model will perform the following items:
Codifes the service strategy for a market space.
Blueprints process and functions needed to create value.
Describes how service assets create value for a given portfolio of contracts.
Is useful for efectiveness in continual service improvement.
Service Agreements specify the terms and conditions under which such interaction occurs with commitments
and expectations on each side.
Note: Interaction means demand connects with the capacity to serve.
Service Transition evaluates the options or paths for improvements and recommends solutions that are cost-
efective and low risk.
Service Models continually evolve, based on external feedback received from customers and internal feedback
from Service Management processes.
Continual Service Improvement (CSI) processes ensure the feedback to the strategy, design, transition, and
operation processes. Improvements can be made to the structure, the dynamics of a model, or to both.
Business Case
A Business Case is a decision support and planning tool that projects the likely consequences of
a business action.
The consequences can take on qualitative and quantitative dimensions. A fnancial analysis, for
example, is frequently central to a good business case.
Business Case Structure
Introduction Presents the business objectives addressed by the
service management initiative
Methods and
Assumptions
Defnes the boundaries of the business case, such as
time period
Business Impacts
The fnancial and non-fnancial business case results
Risks and
Contingencies The probability that alternative results will engage
Recommendations
Specifc actions recommended
Lesson 1: Service Strategy and the Service Portfolio
The Main Activities of the Service Strategy include defning the market, developing the service
oferings, developing strategic assets, and preparing for implementation. The rollover image
describes these sections in the following list:
Defne the market
Defne the Market and Understand the Customer
Develop the Oferings and Strategic Assets
Develop the service oferings
Service Portfolio (Concepts)
Service Portfolio Management (SPM)
Develop strategic assets
Increasing Service and Performance Potential
Strategic Assessment
Setting Objectives
Defning Critical Success Factors
Expansion, Growth, and Diferentiation
Prepare for implementation
Concepts of the Service Catalog
Service Catalog Management
Service Catalog Management Outputs
RISK
Risk is defned as uncertainty of outcome, whether positive opportunity or negative threat.
Managing risks requires
1.Identifcation of the risk.
2.Control of the exposure to risk. This may have an impact on the achievement of the
business objectives of an organization.
The aim is to support better decision-making through a good understanding of risks and their
likely impact.
The two phases of risk include:
1.Risk Analysis, which is concerned with gathering information about exposure to risk so
that the organization can make appropriate decisions and manage risk appropriately.
2.Risk Management, which involves making the following plans:
o Having processes in place to monitor risks
o Having access to reliable and up-to-date information about risks
o Having the right balance of control in place to deal with those risks
o Having decision-making processes supported by a framework of risk analysis
and evaluation
Elements of Value: Utility and Warranty
Customers cannot beneft from something that is ft for purpose but not ft for use,
or vice versa.
You will fnd it useful to separate the logic of utility from the logic of warranty for the purpose of
design, development, and improvement. Considering all the separate controllable inputs, Service
Strategy allows for a wider range of solutions to the problem of creating, maintaining, and
increasing value.
Utility - Attributes of the service that have a positive efect on the performance of
activities, objects, and tasks associated with desired outcomes.
Warranty - The positive efect being available when needed, in sufcient capacity or
magnitude, and dependably in terms of continuity and security.
Note: Utility is what the customer gets, and warranty is how it is delivered.
The center ring of the ITIL Service Lifecycle deals with the implementation of services, and is
made up of three parts:
Service Design
Service Transition
Service Operation
The main purpose of the Service Design stage of the Service Lifecycle is the design of new or
changed services being introduced into the live environment.
Service Design emphasizes a holistic approach to all aspects of design. When changing or
amending any of the individual elements of design, all other aspects are considered.
Design and development of a new application should not be done in isolation, but should consider
the impact on the overall service, the management systems and tools, the architectures, the
technology, the Service Management processes and the necessary measurements and metrics.
This will ensure not only that the functional elements are addressed by the design, but also that
all of the management and operational requirements are addressed as a fundamental part of the
design and are not added as an afterthought.
Description of the Aspects of Service Design
Components of the Five Aspects of Service Design are illustrated in the rollover image on this
page. Each of these components is described in the following points.
The Business: Separate businesses or business clients with their individual structures
and processes.
SLA: A Service Level Agreement (SLA) is a formal negotiated agreement between
customers and their service provider, or between service providers. It records the
common understanding about services, priorities, responsibilities, and guarantee, with
the main purpose to agree on the level of service.
IT Services: Services rendered for computer-based information systems.
Support Teams: Provide support for hardware, software, and employees. This could
include supporting local machines and servers.
Service Improvement: Aligns and re-aligns IT services to changing business needs by
identifying and implementing improvements to IT Services, while striving to make
processes more efective and cost efcient.
Service Strategy: Design and develop service management as a strategic asset. It
allows for a wider range of solutions to the problem of creating, maintaining, and
increasing value.
Service Transition: Sets customer expectations on how the performance and use of the
new or changed services can be used to enable business change, and reduces the
known errors and minimizes the risks from transitioning the new or changed services into
production.
Service Operation: Coordinates the activities and processes required to deliver, support,
and manage services at agreed upon levels to business users and customers.
Service Portfolio: Identifes the agreed upon scope of service
SLM: Service Level Management (SLM) ensures an agreed-upon level of IT service is
provided for all current IT services, and that future services are delivered to agreed-upon
targets.
SCM: Service Continuity Management (SCM) is the assessment of business impact and
risk and the provision of resilience, failover, and recovery mechanisms.
Suppliers: Usually third parties that provide services to the Service Provider
Five individual aspects of Service Design are considered within this book:
1.The design of new or changed services
2.The design of the Service Portfolio, including the Service Catalog
3.The design of the technology architecture and management systems
4.The design of the processes required
5.The design of measurement methods and metrics
The Service Design stage of the lifecycle starts with a set of new or changed business
requirements and ends with the development of a service solution designed to meet the
documented needs of the business.
This developed solution, together with its Service Design Pack (SDP), is then passed to Service
Transition to evaluate, build, test, and deploy the new or changed service. When these transition
activities are complete, control of the new or changed service is transferred to the Service
Operation stage of the Service Lifecycle.
Service Transition is a change in state, corresponding to a movement of an IT Service or other
Confguration Item from one Lifecycle status to the next.
Service Transition uses all the processes described in the other ITIL parts of the Service Lifecycle
as it is responsible for testing these processes, either as part of a new or changed service or as
part of testing changes to the Service Management processes.
Service level management is important to ensure that customer expectations are managed during
Service Transition. Incident and problem management are important for handling incidents and
problems during testing, pilot and deployment activities
Service Transition is a change in state, corresponding to a movement of an IT Service or other
Confguration Item from one Lifecycle status to the next.
Service Transition uses all the processes described in the other ITIL parts of the Service Lifecycle
as it is responsible for testing these processes, either as part of a new or changed service or as
part of testing changes to the Service Management processes.
Service level management is important to ensure that customer expectations are managed during
Service Transition. Incident and problem management are important for handling incidents and
problems during testing, pilot and deployment activities
The Value of Service Transition:
Improves the ability to adapt quickly to new requirements and market developments.
Aids in transition management of mergers, de-mergers, and acquisitions.
Increases the success rate of changes and releases for the business.
Improves predictions of service levels and warranties for new and changed services.
Expedites timely cancellation or changes to maintenance contracts for both hardware and
software when components are disposed of or decommissioned.
Aids understanding the level of risk during and after change, for example, service outage,
disruption, re-work.
The purpose of Service Transition is to perform the following tasks:
Plan and manage the capacity and resources required to package, build, test, and deploy
a release into production.
Provide a consistent framework for evaluating the service capability and risk profle before
a new or changed service is deployed.
Establish and maintain the integrity of all identifed service assets and confgurations as
they evolve through the Service Transition stage.
Provide good-quality knowledge and information so that change, Release and
Deployment Management can expedite efective decisions about promoting a release
through the test environments and into production.
Provide efcient repeatable build and installation mechanisms to deploy releases to the
test and production environments.
Ensure that the service can be managed, operated, and supported within the Service
Design requirements and constraints.
The purpose of Service Operation is to coordinate and to carry out the activities and processes
required to deliver and to manage services at agreed upon levels to business users and
customers.
Service Operation is also responsible for the ongoing management of the technology that
is used to deliver and support services.
Well designed and implemented processes will be of little value if the day-to-day
operation of those processes is not properly conducted, controlled, and managed.
Service improvements will not be possible if day-to-day activities to monitor performance,
assess metrics, and gather data are not systematically conducted during Service
Operation.
Service Operation includes the implementation and carrying out of all ongoing activities
required to deliver and support services.
SERVICE OPERATION
Any activity that forms part of a service is included in Service Operation, whether it is performed
by the Service Provider, an external supplier, or the user or customer of that service.
Note: Many Service Management processes are performed in Service Operation,
even though a number of ITIL processes (such as Change and Capacity
Management) originate at the Service Design or Service Transition stage.
The scope of Service Operation includes:
The services themselves. Any activity that forms part of a service is included in Service
Operation, whether it is performed by the Service Provider, an external supplier or the
user or customer of that service.
Service Management Processes. The ongoing management and execution of many
Service Management processes are performed in Service Operation, even though a
number of ITIL processes (such as Change and Capacity Management) originate at the
Service Design or Service Transition stage of the Service Lifecycle, they are in use
continually in Service Operation. Some processes are not included specifcally in Service
Operation, such as Strategy Defnition, the actual design process itself. These processes
focus more on longer-term planning and improvement activities, which are outside the
direct scope of Service Operation; however, Service Operation provides input and
infuences these regularly as part of the lifecycle of Service Management.
All services require some form of technology to deliver them. Managing this technology is not a
separate issue, but an integral part of the management of the services themselves. Regardless of
what services, processes, and technology are managed, people drive the demand for the
services and products of organizations. Ultimately, people manage the technology, processes,
and services and are a key part of Service Operation
Value of Service Operation
The Service Operation is where plans, designs, and optimizations are implemented and
measured. Service Operation is where the customer can actually see the value.
However, a challenge to Service Operation exists. A service is expected to run within the budget
established earlier in the lifecycle. In reality, however, very few organizations plan efectively for
the costs of ongoing management of services. Difculty occurs obtaining funding during the
operational phase to fx design faws or unforeseen requirements.
Design issues are often left to Incident and Problem Management to resolve, as though they were
purely operational issues. It can be difcult to obtain funding for tools or actions, including
training, that are aimed at improving the efciency of Service Operation.
Attempts to optimize the service or manage it more efectively are only seen as successful if the
service has had problems in the past. Some services are taken for granted. Improvements are
perceived as unnecessary and "fxing services that are not broken."
Continual Service Improvement (CSI) provides feedback and control between the functions and
processes within and across the elements of the Service Lifecycle.
The dominant pattern in the lifecycle is the sequential progress starting from Service Strategy
through Service Design, Service Transition, Service Operation and back to Service Strategy
through CSI. That however is not the only pattern of action. Every element of the lifecycle
provides points for feedback and control, which are channeled through CSI.
Continual Service Improvement (CSI) aligns and re-aligns IT services to changing business
needs by identifying and implementing improvements to IT Services. Improvement activities
support the Service Lifecycle through Service Strategy, Service Design, Service Transition, and
Service Operation. CSI strives to make processes more efective and efcient, as well as cost-
efective.
The objectives of CSI are as follows:
To review, analyze, and make recommendations on improvement opportunities in each
lifecycle phase: Service Strategy, Service Design, Service Transition, and Service
Operation.
To review and analyze Service Level Achievement results.
To identify and implement individual activities to improve IT Service Quality and improve
the efciency and efectiveness of enabling the IT Service Management (ITSM)
processes.
To improve cost efectiveness of delivering IT services without sacrifcing customer
satisfaction.
To ensure applicable quality management methods are used to support continual
improvement activities.
Benefts of Continual Service Improvement
Business and customer benefts include the following items:
Overall improved quality of business operations
More reliable business support provided by Incident Management, Problem Management,
and Change Management processes
Increased staf productivity because of increased reliability and availability of IT services
Better working relationships between customers and the IT service provider
Financial Benefts include the following items:
Cost efective provision of IT services
Cost-justifed IT infrastructure and services
Reduced costs for implementing changes
Reduced business impact due to IT changes
Improved service reliability, stability, and thus availability
Improved resource allocation and utilization
IT Organization Internal Benefts include the following items:
Improved metrics and management reporting
Alignment of cost structure with business needs
Defned roles and responsibilities
Key Principles and Models
Introduction
This unit teaches the key principles and models used in the ITIL Service Lifecycle.
Objectives
Upon completion of this unit, you will be able to:
Describe the three types of service providers
Explain how to choose between service provider types
Explain the fve major aspects of Service Design
Discuss various sourcing approaches and options
Describe the Service V model
Describe the Service Knowledge Management System
Explain the use of Defnitive Media Library
Describe the Deming Cycle
There are three types of Service Providers.
Type I - Internal Service Provider
Type II - Shared Services Unit
Type III - External Service Provider
Internal Service Provider (Type I)
Type I providers are typically business functions embedded within the business units they serve
which may be part of a larger enterprise or a parent organization. Internal Service Providers
provide services required by the various parts of the business. Type I providers avoid certain
costs and risks associated with conducting business with external parties.
Duplication and waste occur when Type I providers are replicated within the enterprise. To take
advantage of both economy of scale and economy, Type I providers of similar characteristics are
consolidated into a corporate business function
Internal Service Providers may include functions such as:
Finance
Administration
Logistics
Human resources
IT
Shared Services Unit (Type II)
Functions such as fnance, IT, human resources, and logistics are not always at the core of
competitive advantage of an organization.
Instead, the services of such shared functions are consolidated into an autonomous
special unit called a Shared Services Unit (SSU).
Shared Services Unit providers are subject to comparisons with External Service
Providers whose performance they should approximate if not exceed.
Type II providers can ofer lower prices compared to External Service Providers by
standardizing their service oferings across business units and using market-based
pricing to infuence demand patterns.
Shared Service Units (SSU's) can create, grow, and sustain an internal market for their services
and model themselves along the lines of service providers in the open market. Like corporate
business functions, they can use opportunities across the enterprise and spread their costs and
risks across a wider base. However, SSU's have fewer protections in the areas of strategic value
and core competence.
Type II providers beneft from a relatively captive internal market for their services. However, their
customers may still evaluate them in comparison with external service providers. Poorly
performing Type II providers face the threat of substitution putting pressure on the leadership to
adopt industry best practices and strive for operational efectiveness. Industry-leading shared
services units have been successfully spun of from their parent companies as independent
businesses competing in the external marketplace.
External Service Provider (Type III)
Type III providers can ofer competitive prices and drive down unit costs by consolidating demand.
Customers may be motivated to choose a Type III provider because of access to knowledge,
experience, scale, scope, capabilities, and resources that are either beyond the reach of the
organization or outside the scope of a carefully considered investment portfolio.
Business strategies often require reductions in the asset base, fxed costs, operational
risks, or the redeployment of fnancial assets.
Customers may need to have fexible and lean structures and in such cases it is better to
buy services rather than own and operate the assets necessary to execute certain
business functions and processes.
The experience of Type III providers is not limited to any one enterprise or market. The breadth
and depth of such experience is often the single-most distinctive source of value for customers.
The breadth comes from serving multiple types of customers or markets.
The depth comes from serving multiples of the same type. Security is always an issue in shared
services environments. When the Type III provider also provides services to competitors, security
becomes a larger concern.
As a counterbalance, Type III providers may reduce systemic risks by transferring them to
External Service Providers, who spread those risks across a larger value network
Choosing Service Provider Types
Services may be sourced from each type of service provider with decisions based on:
Transaction costs
Strategic industry factors
Core competence
Risk management capabilities of the customer
Example transaction costs are over and above the purchasing costs of the services sold. They
might include, but are not limited to, the costs of the following activities:
Finding and selecting qualifed providers
Defning requirements
Negotiating agreements
Measuring performance
Managing the relationship with suppliers
Resolving disputes
Making changes or amends to agreements
Some questions an organization might ask when choosing Service Provider Types:
Does the activity require highly specialized assets?
Will they be idle or obsolete if that activity is no longer performed?
How frequently is the activity performed within a period or business cycle? Is it infrequent
or sporadic?
How complex is the activity? Is it simple and routine? Is it stable over time with few
changes?
Is it hard to defne good performance? Is it hard to measure good performance?
Is it tightly coupled with other activities or assets in the business? Would separating it
increase complexity and cause problems of coordination?
Lesson 2: Key Principles of Service Strategy
The Four P's of Service Strategy
After a service provider has a proper understanding of its service objectives and understands what makes it
distinctive, it is ready to begin the service lifecycle. The entry points to service strategy are referred to as the Four
Ps. These points identify the diferent forms a service strategy may take.
1. Perspective: Describes a vision and direction
2. Position: Describes the decision to adopt a well-defned stance
3. Plan: Describes the means of transitioning from as-is to to-be
4. Pattern: Describes a series of consistent decisions and actions over time
A strategic perspective articulates the business philosophy and manner in which services are provided. CIOs
may determine that their businesses most value a certain type of service provider.
An internal service provider (Type I) restricted to serving one business unit may adopt a position based on
product know-how, customer responsiveness, value, cost, specialized services, or broad sets of services.
Planning the transition requires answering questions such as:
How do we ofer high-value or low-cost services?
How do we achieve and ofer our specialized services?
Patterns might be:
A service provider who continually ofers specifc services with deep expertise is adopting a high-value or
high-end service strategy.
A service provider who continually ofers dependable and reliable services is adopting a high-warranty
strategy.
The Four P's of Service Management
The implementation of ITIL Service Management as a practice is about preparing and planning the efective and
efcient use of the four Ps:
1. People
2. Processes
3. Products (services, technology, and
tools)
4. Partners (suppliers,
manufacturers,and vendors)
Many designs, plans, and projects fail due to
a lack of preparation and management.
The Five Major Aspects of Service Design
Five individual aspects of Service Design are considered within this book:
1.Design of new or changed services
2.Design of the Service Portfolio, including the Service Catalog
3.Design of the technology architecture and management systems
4.Design of the processes required
5.Design of measurement methods and metrics
The Service Design stage of the lifecycle starts with a set of new or changed business requirements and ends
with the development of a service solution designed to meet the documented needs of the business.
This developed solution, together with its Service Design Pack (SDP), is then passed to Service Transition to
evaluate, build, test, and deploy the new or changed service. When these transition activities are completed,
control of the new or changed service is transferred to the Service Operation stage of the service lifecycle.
Sourcing Approaches and Options
This table lists and describes sourcing options.
Sourcing Approach Description
Insourcing
Insourcing relies on using internal organizational resources in
the design, development, transition, maintenance, operation,
and support. The resources can be used in any combination
with new, changed, or revised service or data center
operations.
Outsourcing
Outsourcing uses the resources of an external organization
or organizations in a formal arrangement to provide a well-
defned portion of the design, development, maintenance,
operation, and support of the service. Outsourcing includes
services from Application Service Providers (ASPs).
Co-sourcing
Co-sourcing combines insourcing and outsourcing to use a
number of outsourcing organizations working together to co-
source key elements within the lifecycle. This process usually
involves a number of external organizations working together
to design, develop, change, maintain, operate, and support a
portion of a service.
Partnership
Partnership or multisourcing is an arrangement between two
or more organizations to work together to design, develop,
transition, maintain, operate, and support IT services. The
focus here tends to be on strategic partnerships that use
critical expertise or market opportunities.
Business Process Outsourcing Business Process Outsourcing (BPO) relocates entire
(BPO)
business functions using formal arrangements between
organizations where one organization provides and manages
the entire business processes or functions of the other
organization in a low cost location. Common examples are
accounting, payroll, and call center operations.
Application Service Provision
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. Applications ofered in this way
are also sometimes referred to as on-demand software and
applications. Through ASPs, the complexities and costs of
such shared software can be reduced and provided to
organizations that could otherwise not justify the investment.
Knowledge Process Outsourcing
(KPO)
The newest form of outsourcing, KPO is a step ahead of
BPO in one respect. KPO organizations provide domain-
based processes and business expertise rather than just
process expertise, and require advanced analytical and
specialized skills from the outsourcing organization.
The Service V Model
In Service Transition, the Service V model can be used to represent the diferent
confguration levels that need to be built and tested in order to deliver a service capability.
The left side of the diagram represents the specifcation of the service requirements down
through the detailed service design.
The right side focuses on the validation activities that are performed using the
specifcations defned on the left side.
At each stage on the left side, the equivalent group on the right side is directly involved
Lesson 3: Key Principles of Service esign! Service Transition! and Service "peration
Conficting Motives in Service Operation
Service Operation is designed to deliver specifed and agreed upon levels of service
Service Operation must deal with conficting
sets of priorities to deliver services
All functions, processes, and activities of a
Service Operation are designed to deliver a
specifed and agreed-upon level of services.
It is possible that a confict might develop
between maintaining the status quo and
adapting to changes in the business and
technological environments.
One of key roles of the Service Operation is
to deal with this confict and to achieve a
balance between conficting sets of priorities.
Resolving the confict and moving towards a
best practice approach represents an
opportunity for growth and improvement.
IT organizations may sufer from an
imbalance by tending more toward one
extreme or the other.
External and Internal View of IT
This table compares the External and Internal views of IT.
View Description Potential Weaknesses
External
View
The External View is based on
services that are delivered. It is the
way in which services are experienced
by users and customers who might not
always understand, nor care about,
the details of the technology used to
manage those services. All that
concerns them is that the services are
delivered as required and agreed
upon.
Focusing only on business requirements results in
making promises that can not be kept.
Internal
View
The internal view of IT is the way in
which IT components and systems are
managed to deliver the services.
Focusing only on internal systems results in
expensive services that deliver little value.
Service Operation: Stability versus Responsiveness
Service Operation must ensure that the IT Infrastructure is stable and available as designed. Service Operation
must meet response requirements. A balance between Stability and Responsiveness will require that
technologies and processes are adaptive rather than rigid.
The function, performance, and architecture of a platform might change over a number of years and with each
change comes an opportunity to provide better levels of service to the business.
Other changes happen quickly and sometimes under extreme pressure. For example, a business unit acquires a
large contract that requires additional IT services, more capacity, and faster response times
Service Operation: Quality of Service versus Cost of Service

Service Operation is required to consistently deliver the agreed upon level of service. Service
Operation must keep costs and resource utilization at an optimal level. An increase in the level of
quality usually results in an increase in the cost of service. The relationship between quality and
cost of service is not always directly proportional.
For example, improving service availability from 55% to 75% could be straightforward and might
not require a huge investment. However, improving availability of the same service from 96% to
99.9% might require large investments in high-availability technology and support staf and tools
Service Operation: Reactive versus Proactive
This table compares reactive versus proactive approaches to Service Operation.
Approach Description Risks
Reactive
A reactive organization does not act unless it is
prompted to do so by an external driver.
Responding to business needs and
incidents only after they are reported
can cause delivery of new services to
take a long time because each project
is dealt with as if it is the frst
occurrence. Staf turnover tends to be
high and morale is generally low, as IT
staf keep moving from project to
project without achieving a lasting,
stable set of IT services.
Proactive
A proactive organization is always looking for
ways to improve the current situation.
Proactive behavior is usually seen as
positive. However,being too proactive
can be expensive and can result in
staf being distracted. Discouraging
efort investment in proactive service
management can ultimately increase
the efort and cost of reactive activities
and further risk stability and
consistency in services.
Communication in Service Operation
Good communication is needed:
With other IT teams and departments
With users and internal customers
Between the Service Operation teams and departments themselves
In some organizations, communication takes place in meetings. Other organizations prefer to use e-mail or the
communication inherent in their Service Management tools.
One organization might require that all communications regarding changes must be sent by e-mail. Others might
believe that the Service Management tools themselves contain sufcient information and that e-mails would be
redundant. Issues can often be prevented or mitigated with appropriate communication. All communication must
have an intended purpose or a resultant action. Information should not be communicated unless there is a clear
audience.
Service Knowledge Management System
Under Service Transition, knowledge
management is focused within the Service
Knowledge Management System (SKMS).
Underpinning this knowledge is a
considerable quantity of data, which will be
held in a central logical repository or
Confguration Management System (CMS)
and Confguration Management Database
(CMDB).
Data:
Gathered within CMDB
Fed through the CMS
Goes into the SKMS
Supports the informed decision
making process
The Service Knowledge Management system is a broader concept that covers a much wider base
of knowledge, for example:
The experience of staf
Records of peripheral matters, for example, weather, user numbers, user behavior, and
performance fgures of an organization
Supplier and partner requirements, abilities, and expectations
Typical and anticipated user skill levels
Defnitive Media Library (DML)
This Defnitive Media Library (DML) can consist of one or more software libraries or fle-storage
areas, separate from development, test, or live fle-store areas.
The DML:
Is a Secure library into which only authorized media should be accepted
Stores and protects the defnitive authorized versions of all media CI's
Acts something like a freproof safe
Contains master copies of all controlled software in an organization
Includes a physical store to hold master copies
The DML should include defnitive copies of purchased software (along with license documents or
information), as well as software developed on site. Master copies of controlled documentation for
a system are also stored in the DML in electronic form. The media is strictly controlled by Service
Asset and Confguration Management
Lesson 4: Key #o$ponents of #ontin%al Service &$prove$ent
Plan, Do, Check, and Act (PDCA) Model
W. Edwards Deming is best known for his management philosophy leading to:
Higher quality
Increased productivity
More competitive position
The four key stages of the Deming Cycle or Circle are:
1.Plan
2.Do
3.Check
4.Act
As you will see illustrated on the next page, the goal of CSI in using the Deming Cycle is steady,
ongoing improvement
The Deming Cycle Illustrated
The Deming Cycle consists of cycles of Planning, Acting, Checking the results, and Doing actions
that improve the process. Over time, the goal of the Deming Cycle is steady improvement of
processes.
Service Measurement
Service Measurement is the ability to predict and report service performance against the established target of
achievements of an end-to-end service.
Service Measurement requires someone to:
Take the individual measurements
Combine individual measurements to provide a view of the true customer experience
The measuring process must regularly confrm that:
The data being collected and collated is still required
Measurements are adjusted where necessary
One of key set of activities of the Continual Service Improvement is to measure, analyze, and report on IT
services and ITSM results. Measurements will, of course, produce data. This data should be analyzed over time
to produce a trend. The trend will tell a story that could be positive or negative.
Measurements of this kind must have ongoing relevance. Information that was important to know last year might
not be pertinent this year.
Continual Service Improvement Model
The movement and cycle of the Continual Service Improvement model is detailed in the following
illustration
The primary purpose of CSI is to continually align and realign IT services to the changing
business needs by identifying and implementing improvements to IT services that support
business processes. These improvement activities support the lifecycle approach through Service
Strategy, Service Design, Service Transition and Service Operation. In efect, CSI is about
looking for ways to improve process efectiveness, efciency as well as cost efectiveness.
Measurements for Continual Service Improvement
Why are measurements performed?
To validate
To direct
To justify
To intervene
The four basic reasons to monitor and
measure lead to three key questions:
1.Why monitor and measure?
2.When can monitoring and
measuring of this item be stopped?
3.Is anyone using this data?
Every time you produce a report, ask yourself, "Is this report still needed and used by anyone?" Reasons to
continue producing a report could include:
To validate : Monitoring and measuring to validate previous decisions and make sure your progress is on
track with the strategy vision.
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.
Baselines
An important beginning point for highlighting improvement is to establish baselines as markers or starting
points for later comparison.
Baselines are used to establish an initial data point to determine if a service or process needs to
be improved.
It is important that baselines are documented, recognized,and accepted throughout the
organization.
Baselines must be established at each level: strategic goals and objectives, tactical process maturity, and
operational metrics and Key Performance Indicators (KPI's
Types of Metrics
Information for measuring is gathered from IT Service Management tools, monitoring tools, reporting tools,
investigation tools, existing reports, and other sources.
Type of Metric Description
Technology
Technology metrics are often associated with component-based and application
based metrics such as performance, availability and so on.
Process
Process measurements can help determine the overall health of a process. Key
Performance Indicators (KPI's) can help answer questions about quality,
performance, value, and compliance in following the process.
Service
Service Metrics are the results of the end-to-end service. Component or
technology metrics are used to compute the Service Metrics.
Continual Service Improvement - Governance
Enterprise Governance describes a framework that covers:
Corporate governance
Business management
Corporate governance is about promoting:
Corporate fairness
Transparency
Accountability
IT governance consists of:
Leadership
Organizational structures
Processes
Enterprise governance describes a framework that covers both the corporate governance and the
business management aspects of the organization. Enterprise governance also considers the
whole picture to ensure that strategic goals are aligned and good management is achieved.
The most recent and highly visible example of a renewed emphasis on corporate governance is
the Sarbanes-Oxley Act (SOX) of 2002 in the United States. Created in the aftermath of
fraudulent behavior by corporate giants, SOX includes the following provisions:
Requires corporations to engage in corporate fairness
Mandates complete transparency of transactions
Holds executives accountable for any material defciencies
IT governance ensures that the IT of an organization sustains and extends the strategies and
objectives of that organization.
IT departments and organizations must now comply with new rules and legislation and continually
demonstrate their compliance through successful independent audits by external organizations.
UNIT 4
Lesson 1: Service Strategy and the Service Portfolio
Defning the Market: Understand the Customer
To develop your service strategies:
Diferentiate your services from the competition.
Use existing opportunities: Customers who are not well supported represent opportunities
for services to be ofered as solutions.
Use new opportunities: New opportunities emerge when changes in the business
environment cause a previously well- supported customer to be poorly supported.
Defning the market and understanding the customer include the following activities:
Service strategies are developed for services ofered.
Providers diferentiate their services from competing alternatives available to customers.
Service management ofers services as part of a business strategy.
An example of market defnition:
A software vendor decides to ofer software as a service. The vendor combines the capabilities in
software development with new capabilities in service management. The vendor also use of the
capabilities in maintaining software applications to bundle technical support as part of the core
service. By adopting a service-oriented approach supported by service management capabilities,
the vendor has transformed into a service business.
This approach has also been adopted by internal software engineering groups who have changed
from being cost centers to being proft centers.
Defning the Market: Service Management
Service management as a strategic asset identifes the key relationships and interactions to have
better visibility and control over the systems and processes they operate.
Customers perceive benefts in a continued relationship and trust the provider to increase value
and add possibilities of new customers and market spaces. These benefts justify further
investments in Service Management in terms of capabilities and resources that have a tendency
to reinforce each other. Stakeholders may initially trust the provider with low-value contracts or
non-critical services.
Service Management responds by delivering the performance expected of a strategic asset. The
performance is rewarded with contract renewals, new services, and customers. Together these
rewards represent a larger value of business. To handle this increase in value, Service
Management must invest further in assets such as process, knowledge, people, applications, and
infrastructure. Successful learning and growth enables commitments of higher service levels as
Service Management is conditioned to handle bigger challenges. Over time, this cycle results in
higher capability levels and maturity in Service Management, leading to a higher return on assets
for the service provider.
Unless properly defned, the cost of service assets spent in support of customers assets may be
difcult to account for and recover. This difculty leads to situations where adequate value is
created for the customer, but inadequate value is captured for the provider.
To develop Service Management as a strategic asset, defne the value network by identifying the
key relationships and interactions. This defnition will provide better visibility and control over the
systems and processes they operate. Managers can manage the complexity of their business
environments as customers pursue their own business models and strategies. Service
Management also helps account for all the costs and risks involved in providing a service or
supporting a customer.
Strategic assets are dynamic. They are expected to continue to perform well under changing
business conditions and objectives of their organization. Therefore, strategic assets must have
learning capabilities. Performance in the immediate future should beneft from knowledge and
experience gained from the past. Service Management must operate as a closed-loop system
that systematically creates value for the customer and captures value for the service provider. An
important aspect of Service Management is controlling the interactions between customer assets
and service assets
The Service Portfolio represents all the resources presently engaged or being released in various
phases of the Service Lifecycle. Entry, progress, and exit are approved only with approved
funding and a fnancial plan for recovering costs or showing proft, as necessary.
The portfolio should have the right mix of services in the pipeline and catalog to secure the
fnancial viability of the service provider. The Service Catalog is the only part of the Service
Portfolio that recovers costs or earns profts.
Service Portfolio Management (SPM) is about maximizing value while managing risks and costs.
The value realization is derived from better service delivery and better customer experiences.
SPM begins by documenting the standardized services of the organization and therefore has
strong links to Service Level Management, particularly the Service Catalog.
Developing Service Offerings: the Service Portfolio Management (SPM)
The Service Portfolio represents the commitments and investments made by a service provider
across all customers and market spaces. It represents present contractual commitments, new
service development, and ongoing service improvement programs initiated by Continual Service
Improvement.
Portfolio management helps managers prioritize investments and improve the allocation of
resources. Portfolios instill a certain fnancial discipline necessary to avoid making investments
that will not yield value. Service portfolios represent the ability and readiness of a service provider
to serve customers and market spaces.
SPM is about maximizing value while managing risks and costs. Through SPM, managers are
better able to understand quality requirements and related delivery costs. They can then seek to
reduce costs through alternative means while maintaining service quality. The SPM journey
begins by documenting the standardized services of the organization and therefore has strong
links to Service Level Management, particularly the Service Catalog.
Develop Strategic Assets by Increasing Service and Performance Potential
The capabilities and resources (service assets) of a service provider represent the service
potential or the productive capacity available to customers through a set of services. Projects that
develop or improve capabilities and resources increase the service potential.
The following example shows the results of implementing a Confguration Management system:
Implementation of a Confguration Management system leads to improved visibility and control
over the productive capacity of service assets such as networks, storage, and servers. The
confguration management system also helps to quickly restore such capacity in the event of
failures or outages. Those assets are used more efciently, and service potential is increased
because of capability improvements in Confguration Management. Through Confguration
Management, all service assets should be identifed with the name of the services to which they
add service potential. This identifcation helps decision makers arrive at decisions related to
service improvement and asset management. Clear relationships make it easier to ascertain the
impact of changes, make business cases for investments in service assets, and identify
opportunities for scale of and scope of economies. The Confguration Management system
identifes critical service assets across the service portfolio for a customer or market space.
The services ofered by a service provider represent the potential to increase the performance of
customer assets. Without this potential, customers cannot justify procuring the services.
Performance potential of services needs to be defned so that management decisions are rooted
in creating value for customers. This practice avoids many problems of service businesses where
value for customers is created in intangible forms and is therefore harder to defne and control.
Working backwards from the performance potential of customers ensures that service providers
are always aligned with business needs, regardless of how often those needs change.
The performance potential of services is increased primarily by having the right mix of services to
ofer to customers and designing those services to have an impact on the businesses of the
customers.
The productive capacity of service assets is transformed into the productive capacity of customer
assets. An important aspect of delivering value for customers through services is reducing risks
for customers. By deciding to use a service, customers often are seeking to avoid certain risks
and costs. Therefore, the performance potential of services also arises from removing costs and
risks from the businesses of the customers.
Develop Strategic Assets by Preparing for Implementation: Strategic Assessment
Established service providers frequently do not understand their unique diferentiators. The
diferentiation can come in many forms:
Barriers to entry, such as the know-how of the organization regarding the business of the
customer or the broadness of service oferings
Raised switching costs, due to lower cost structures generated through specialization or
service sourcing
A particular attribute not readily found elsewhere, such as:
o Product knowledge
o Regulatory compliance
o Provisioning speeds
o Technical capabilities
o Global support structures
evelop Strategic 'ssets (y Preparing for &$ple$entation: Setting "()ectives
Objectives represent the results expected from pursuing strategies, and while strategies represent
the actions to be taken to accomplish objectives. Clear objectives provide for consistent decision
making, minimizing any future conficts. They set forth priorities and serve as standards.
To craft objectives, an organization must:
Understand what outcomes customers want
Determine how best to satisfy the important but underserved outcomes
From this understanding, the organization can create metrics to measure how well a service is
performing. These data sources are the primary means by which a service provider creates
value.
evelop Strategic 'ssets (y Preparing for &$ple$entation: efining #ritical S%ccess
*actors
Every market space has critical success factors that determine the success or failure of a service
strategy. These factors are infuenced by customer needs, business trends, competition,
regulatory environment, suppliers, standards, industry best practices, and technologies.
Identifying critical success factors for a market space is an essential aspect of strategic planning
and development. In each market space, service providers require a core set of assets in order to
support a Customer Portfolio through a Service Portfolio. For example, in the market space for
high-volume, real-time data processing, such as those required by the fnancial services industry,
service providers must have:
Large-scale computer systems
Highly reliable network infrastructure
Secure facilities
Knowledge of industry regulations
Without these assets, such service units cannot provide the utility and warranty demanded by
customers in that market space.
The dynamic nature of markets, business strategies, and organizations requires critical success
factors be reviewed periodically or at signifcant events such as changes to customer portfolios,
expansion into new market spaces, changes in the regulatory environment, and disruptive
technologies. For example, the healthcare industry has new legislation on the portability and
privacy of patient data. This change alters the critical success factors for all service providers
operating in healthcare market spaces.
Develop Strategic Assets by Expansion, Growth, and Diferentiation
The best opportunities for service providers lie in areas where an important customer need
remains poorly satisfed. Service portfolios should be extended to support such areas of
opportunity. This typically means that there is a need for services to provide certain levels of utility
and warranty. However, managers should not overlook the costs and risks in such areas. There
are usually strong reasons why certain needs of customers remain unfulflled. Breakthrough
performance and innovation are usually required to successfully deliver value in under served
areas of opportunity.
The long-term vitality of the service provider rests on supporting customer needs as they change
or grow as well as exploiting new opportunities that emerge. This analysis identifes opportunities
with current and prospective customers. It also prioritizes investments in service assets based on
their potential to serve market spaces of interest.
Because market spaces are defned in terms of the business needs of customers, service
provider strategies are therefore aligned to customers. For this reason, service providers must
think in terms of market spaces and not simply industry sectors, geographies, or technology
platforms. This way of thinking is intuitive to the senior leadership of Type I providers. They are
accustomed to being driven more by the outcomes expected by their business units than by the
traditional market segmentation. When service strategies are linked to market spaces, it is easier
to make decisions about service portfolios, designs, operations, and long-term improvements.
Investments in service assets such as skills sets, knowledge, processes, and infrastructure are
driven by the critical success factors for a given market space.
Strategic planning and review includes examining opportunities for growth within current
customers and services. Growth in a market space is dependent upon demonstrated ability to
deliver value and a strong record with existing customers.
Diferentiation in market spaces is normally created by the following techniques:
Better a better mix of services
Superior service designs
Operational efectiveness that allows for efciency and efectiveness in the delivery and
support of services
Diferentiation can be created in many ways with various combinations of factors. Service
Management leads to diferentiation in every supported market space by making decisions on the
following topics:
Service design *Transition
Operation
Improvement
Prepare for Implementation: the Service Catalog
The Service Catalog is an important tool for Service Strategy because it is the virtual projection of
the actual and present capabilities of the service provider. Many customers are only interested in
what the provider can commit now rather than in future. The value of future possibilities is
discounted in the present.
Prepare for Implementation: Service Catalog Details
The Service Catalog is the subset of the Service Portfolio that is visible to customers. The
Service Catalog:
Consists of services presently active in the Service Operation phase and those approved
to be readily ofered to current or prospective customers.
Is useful in developing suitable solutions for customers from one or more services.
Contains items that can be confgured and suitably priced to fulfll a particular need.
Serves as a service order and demand channeling mechanism.
Acts as the acquisition portal for customers, including pricing and service-level
commitments, and the terms and conditions for service provisioning.
Providers may have many customers or serve many businesses. Therefore, the Service Portfolio
might project multiple Service Catalogs. The Service Catalog expresses the operational capability
of the provider within the context of a customer or market space.
Prepare for Implementation: Service Catalog Management
Service Catalog Management (SCM) process ensures that a Service Catalog is produced and
maintained containing accurate information on all operational services and those being prepared
to be run operationally. SCM provides a single source of consistent information on all of the
agreed-upon services and ensures that the catalog is widely available to those approved to
access it. Service Catalog Management (SCM) performs the following tasks:
Manages the information contained within the Service Catalog
Ensures that the catalog is accurate
Ensures that the catalog refects the current details, status, interfaces, and dependencies
of all services that are being run or being prepared to run in the live environment
The Service Catalog provides a central source of information on the IT services delivered by the
service provider organization. The catalog ensures that all areas of the business can view an
accurate, consistent picture of the IT services, their details, and their status. The catalog should
contain:
View of the current IT services from the perspective of the customer
How the services are intended to be used
Business processes enabled by the services
Levels and quality of service the customer can expect for each service
Details of all operational services being provided
Those services being prepared for transition to the live environment
Summary of their characteristics
Details of the customers
The portfolio should contain all of the future requirements for services. The Service Portfolio is
produced as part of Service Strategy and should include participation by those involved in
Service Design, Transition, Operation, and Improvement. After a service is chartered, being
developed for use by customers, Service Design produces the specifcations for the service. At
this point the service should be added to the Service Catalog.
The SCM process produces and maintains the Service Catalog to ensure:
A central, accurate, and consistent source of data
A record of the status of all operational services or services being moved to the live
environment
A record of appropriate details of each service
Prepare for Implementation: Service Catalog Management Outputs
Many sources of information are relevant to the Service Catalog Management (SCM) process.
These should include:
Business information from the business and IT strategy, plans, and fnancial plans of the
organization
Information on organizational current and future requirements from the Service Portfolio
Business impact analysis providing information on the impact, priority, and risk associated
with each service or change to service requirements
Details of any agreed-upon, new, or changed business requirements from the Service
Portfolio
The Service Portfolio
The Confguration Management System (CMS)
Feedback from all other process
Triggers for the SCM process, which are changes in the business requirements and
services. One of the main triggers is a Request For Change (RFC). The Change
Management process includes new services, changes to existing services, and services
being retired.
The process outputs of SCM include the following items:
The documentation and agreement of a defnition of the service
Updates to the Service Portfolio, which should contain the current status of all services
and requirements for services
The Service Catalog should contain:
Details of every live service provided by the service provider or service being moved into
the live environment
Current status of each of these services
Interface
Dependencies
LESSON -2
ITIL Processes and Process Owners
The ITIL Processes and Process Owners along with their underlying topics are in the following
list. This image shows how each process or process owner relates to the ITIL Service Lifecycle.
Service Strategy and the Service Portfolio
Activities of Service Strategy
Develop the Oferings and Strategic Assets
Service Portfolio Management (SPM)
Increasing Service and Performance Potential
Prepare for Implementation
Expansion, Growth, and Diferentiation
Service Catalog Management
Service Measurements and Agreements
Service Level Agreements
Operational Level Agreements
Underpinning Contracts
Service Design Package
Availability, Reliability, Maintainability, and Serviceability
Service Level Management (SLM)
SLM Business Value
SLM Activities
SLM Input/Output
SLM Key Performance Indicators (KPI's)
SLM Challenges
Sample Swim Lane Diagram
Availability Management
Proactive versus Reactive Availability Management
Reliability, Availability, Maintainability
Other Availability Terms and Availability Management Interfaces
Information Security Management
Security Framework
Contents of the Information Security Policy
Information Security Management Interfaces
Process and Service Roles
Process Owners
Service Owners
Service Manager and Continual Service Improvement Manager
Service Measurement is the ability to predict and report service performance against the
established target of achievements of an end-to-end service. Service Measurement requires
someone to:
Take the individual measurements
Combine individual measurements to provide a view of the true customer experience
The measuring process must regularly confrm that:
The data being collected and collated is still required
Measurements are adjusted where necessary
One of key set of activities of the Continual Service Improvement is to measure, analyze, and
report on IT services and ITSM results. Measurements will, of course, produce data. This data
should be analyzed over time to produce a trend. The trend will tell a story that could be positive
or negative.Measurements of this kind must have ongoing relevance. Information that was
important to know last year might not be pertinent this year.
Service Level Agreements, Operational Level Agreements, and Underpinning Contracts
Service Level Agreement
A Service Level Agreement (SLA) is a written agreement between an IT service provider and the
IT customers. An SLA defnes the key service targets and responsibilities of both parties. The
emphasis must be on agreement. SLA's should not be used as a way of holding one side or the
other to ransom. A true partnership should be developed between the IT service provider and the
customer, so that a mutually benefcial agreement is reached. Otherwise the SLA could quickly
fall into disrepute, with each side blaming the other for perceived faults and transgressions. The
resulting environment would prevent any true service quality improvements from taking place.
Organizational Level Agreement
An Organizational Level Agreement (OLA) is an agreement between an IT service provider and
another part of the same organization that helps provide services. Examples of such divisions
include:
Facilities department that maintains the air conditioning
Network support team that supports the network service
An OLA should contain targets that underpin those within an SLA to ensure that targets will not
be breached by failure of the supporting activity.
n!erpinning Contracts
Formal contracts are appropriate for external supply arrangements that make a signifcant
contribution to the delivery and development of the business. Contracts provide binding legal
commitments between customer and supplier. Contracts cover the obligations each organization
has to the other from the frst day of the contract. Often contractual obligations extend beyond the
end of the contract. A contract is used as the basis for external supplier agreements where an
enforceable commitment is required. High-value relationships, strategic relationships, or both are
underpinned by formal contracts. The formality and binding nature of a contract are not at odds
with the culture of a partnership agreement, but rather form the basis on which trust in the
relationship may be founded
A Service Design Package (SDP) should be produced during the design stage for:
Each new service
A major change to a service
Removal of a service
Changes to the Service Design Package itself
This SDP is then passed from Service Design to Service Transition. The SDP details all aspects
of the service and the requirements of the service through all of the subsequent stages of the
lifecycle of the service.
The SDP should contain the following items:
Business Requirements
Service Functional Requirements
Service Level Requirements
Organizational Readiness Assessment
Service Lifecycle Plan
Availability is the ability of a service, component, or Confguration Item (CI) to perform the
agreed-upon function when required.
Reliability is a measure of how long a service, component, or Confguration Item can perform the
agreed-upon function without interruption.
Maintainability is a measure of how quickly and efectively a service, component, or
Confguration Item can be restored to normal working after a failure.
Serviceability is the ability of a supplier to meet the terms of the contract.
Note: The reliability of the service can be improved by increasing the reliability of
individual components or by increasing the resilience of the service to individual
component failure (such as increasing the component redundancy, for example by
using load-balancing techniques). The reliability of the service is often measured
and reported as Mean Time between Service Incidents (MTBSI) or Mean Time
between Failures (MTBF).
Lesson ": Service Level Management
ITIL Processes and Process Owners
The ITIL Processes and Process Owners along with their underlying topics are in the following
list. This image shows how each process or process owner relates to the ITIL Service Lifecycle.
Service Strategy and the Service Portfolio
Activities of Service Strategy
Develop the Oferings and Strategic Assets
Service Portfolio Management (SPM)
Increasing Service and Performance Potential
Prepare for Implementation
Expansion, Growth, and Diferentiation
Service Catalog Management
Service Measurements and Agreements
Service Level Agreements
Operational Level Agreements
Underpinning Contracts
Service Design Package
Availability, Reliability, Maintainability, and Serviceability
Service Level Management (SLM)
SLM Business Value
SLM Activities
SLM Input/Output
SLM Key Performance Indicators (KPI's)
SLM Challenges
Sample Swim Lane Diagram
Availability Management
Proactive versus Reactive Availability Management
Reliability, Availability, Maintainability
Other Availability Terms
Availability Management Interfaces
Information Security Management
Security Framework
Contents of the Information Security Policy
Information Security Management Interfaces
Process and Service Roles
Process Owners
Service Owners
Service Manager
Continual Service Improvement Manager
Service Level Management O#$ectives
The goal of the Service Level Management (SLM) process is to ensure that an agreed-upon level
of IT service is provided for all current IT services, and that future services are delivered to
agreed-upon targets. Proactive measures are also taken to seek and implement improvements to
the level of service delivered. The SLM process works to ensure that all operational services and
their performance are measured in a consistent, professional manner throughout the IT
organization, and that the services and the reports produced meet the needs of the business and
the customers.
The objectives of SLM are to:
Defne, document, agree to, monitor, measure, report, and review the level of IT services
provided
Provide and improve the relationship and communication with the business and
customers
Ensure that specifc and measurable targets are developed for all IT services
Monitor and improve customer satisfaction with the quality of service delivered
Ensure that IT and the customers have a clear and unambiguous expectation of the level
of service to be delivered
Ensure that proactive measures to improve the levels of service delivered are
implemented whenever the cost justifes it
Service Level Management (SLM) provides a consistent interface to the business for all service-
related issues. It provides the business with the agreed-upon service targets and the required
management information to ensure that those targets have been met.
Where targets are breached, SLM should provide feedback on the cause of the breach and
details of the actions taken to prevent the breach from recurring. Therefore SLM provides a
reliable communication channel and a trusted relationship with the appropriate customers and
business representatives
SLM is the name given to the processes of planning, coordinating, drafting, agreeing upon,
monitoring, and reporting of Service Level Agreements (SLAs), and the ongoing review of service
achievements to ensure that the required and cost-justifable service quality is maintained and
gradually improved. However, SLM is concerned with:
Ensuring that current services and SLAs are managed
Ensuring that new requirements are captured
Ensuring that new or changed services and SLA's are developed to match the business
needs and expectations
Service Level Agreements (SLAs) provide the basis for managing the relationship between the
service provider and the customer. SLM provides that central point of focus for a group of
customers, business units, or lines of business. SLM is also responsible for ensuring that all
targets and measures agreed upon in SLA's with the business have the following support:
Appropriate underpinning OLA's or contracts
Internal support units
External partners
External suppliers
A Service Level Agreement is a written agreement between an IT service provider and the IT
customers. An SLA defnes the key service targets and responsibilities of both parties. The
emphasis must be on agreement, and SLAs should not be used as a way of holding one side or
the other to ransom. A true partnership should be developed between the IT service provider and
the customer, so that a mutually benefcial agreement is reached. Otherwise the SLA could
quickly fall into disrepute, with each side blaming the other for perceived faults and
transgressions. The resulting environment would prevent any true service quality improvements
from taking place.
An Organizational Level Agreement (OLA) is an agreement between an IT service provider and
another part of the same organization that assists with the provision of services. Examples would
be a facilities department that maintains the air conditioning or a network support team that
supports the network service. An OLA should contain targets that underpin those within an SLA
to ensure that targets will not be breached by failure of the supporting activity.
The key activities within the SLM process should include:
Determine, negotiate, document, and agree upon requirements for new or changed
services in SLRs
Manage and review the requirements through the Service Lifecycle into SLAs for
operational services
Monitor and measure service performance achievements of all operational services
against targets within SLAs
Collate, measure and improve customer satisfaction
Produce service reports
Conduct service review and instigate improvements within an overall Service
Improvement Plan (SIP)
Review and revise SLAs, service scope OLAs, contracts, and any other underpinning
agreements
Develop and document contacts and relationships with the business, customers, and
stakeholders
Develop, maintain, and operate procedures for:
o Logging, assigning, and resolving all complaints
o Logging and distributing compliments
Provide the appropriate management information to aid performance management and
demonstrate service achievement
Provide and maintain up-to-date SLM document templates and standards
Service Level Management input is made up of:
Business information from the business strategy, plans, and fnancial plans and
information on their current and future requirements of the organization
The Service Portfolio and Service Catalog
Change information from the Change Management process with a forward schedule of
changes and a need to assess all changes for their impact on all services
Many sources of information are relevant to the Service Level Management process. These
should include:
Business information from the business strategy, plans, and fnancial plans of the
organization and information on their current and future requirements
Business Impact Analysis that providing information on the impact, priority, risk, and
number of users associated with each service
Business requirements: details of any agreed-upon, new, or changed business
requirements
The strategies, policies, and constraints from:
o Service Strategy
o Service Portfolio
o Service Catalog
Change information from the Change Management process with a forward schedule of
changes and a need to assess all changes for their impact on all services
CMS containing information on the relationships between the business services, the
supporting services. and the technology
Customer and user feedback, complaints, and compliments
Other inputs, including:
o Advice, information, and input from any of the other processes (such as Incident
Management, Capacity Management, and Availability Management)
o Existing SLAs, SLRs, and OLAs
o Past service reports on the quality of service delivered
The outputs of Service Level Management should include the items listed in the following table.
SLM Outputs Description
Service Reports
Service Reports provide details of the service levels
achieved in relation to the targets contained within SLAs
These reports should contain details of all aspects of the
service and its delivery, including, current and historical
performance, breaches and weaknesses, major events,
changes planned, current and predicted workloads,
customer feedback, improvement plans, and activities.
Service Improvement Plan (SIP)
The S! is an overall program or plan of prioriti"ed
improvement actions, encompassing all services and all
processes, together with associated impacts and risks.
The Service Quality Plan
This plan encompasses documenting and planning the
overall improvement of service #uality.
Document Templates
These include standard document templates, format and
content for SLAs, SLAs and $LAs, aligned with corporate
standards.
Service Level !reements (SLs)
This is a set of targets and responsibilities that should be
documented and agreed to within an SLA for each
operational service.
Service Level Re"uirements (SLRs)
This is a set of targets and responsibilities should be
documented and agreed within an SLR for each proposed
new or changed service.
Operational Level !reements (OLs)
$LAs are a set of targets. Responsibilities should be
documented and agreed to within an $LA for each internal
support team. Reports are generated on $LAs and
underpinning contracts.
Service revie# meetin! minutes and
actions
All meetings should be scheduled on a regular basis, with
planned agendas and their discussions and actions
recorded and their progress documented.
SL revie# and service scope revie#
meetin! minutes
These minutes include summaries of agreed%upon actions
and revisions to SLAs and service scope.
Revised $ontracts
This includes changes to SLAs or new SLRs may re#uire
e&isting underpinning contracts to be changed or new
contracts to be negotiated and agreed upon.
Service Level Manage$ent: Key Perfor$ance &ndicators
Key Performance Indicators (KPIs) and metrics can be used to judge the efciency and
efectiveness of the SLM activities and the progress of the SIP. These metrics should be
developed from the service, customer, and business perspective and should cover both subjective
and objective measurements.
Objective measurements include the following items:
Number or percentage of service targets being met
Number and severity of service breaches
Number of services with up-to-date SLAs
Number of services with timely reports and active service reviews
Subjective measurements include improvements in customer satisfaction.
The SLM process often generates a good starting point for a Service Improvement Plan (SIP).
The service review process might drive this process, but all processes and all areas of the service
provider organization should be involved in the SIP.
When an underlying difculty has been identifed that adversely afects service quality, SLM must
act with Problem Management and Availability Management to instigate a SIP. They must identify
and implement whatever actions are necessary to overcome the difculties and restore service
quality. SIP initiatives may also focus on such issues as user training, service and system testing,
and documentation. In these cases, the relevant people need to be involved and adequate
feedback given to make improvements for the future. At any time, a number of separate initiatives
that form part of the SIP could be running in parallel to address difculties with a number of
services.
If an organization is outsourcing its Service Delivery to an external party, the issue of service
improvement should be discussed at the outset, covered, and budgeted for in the contract.
Otherwise, the supplier has no incentive during the lifetime of the contract to improve service
targets
Service Level Management Challenges
Serviceability ensures that the Service Provider can actually meet the terms of the SLAs.
Utility ensures the requirements presented actually represent the customer needs.
One challenge faced by SLM is that of identifying suitable customer representatives with whom to
negotiate. Who owns the service? In some cases, this answer may be obvious. A single customer
manager might be willing to act as the signatory to the agreement. In other cases, it might require
negotiating or cajoling to fnd a representative volunteer (Be aware that volunteers often want to
express their personal views rather than represent a consensus.) Or it might be necessary for all
customers to sign.
If customer representatives can genuinely represent the views of the customer community
because they frequently meet with a wide selection of customers, this situation is ideal.
Unfortunately, often representatives are from the head ofce and seldom meet service customers.
In the worst case, SLM may have to perform their own program of discussions and meetings with
customers to ensure true requirements are identifed.
Note: Take care when opening discussions on service levels for the frst time. It is
likely that current issues (the failure that occurred yesterday) or long-standing
grievances (that old printer that the company has been trying to get replaced for
ages) are likely to be aired at the outset. Important though these may be, they must
not be allowed to get in the way of establishing the longer-term requirements. Be
aware, however, that you might have to address any issues raised at the outset
before you gain the credibility to progress further.
If there has been no previous experience with SLM, then start with a draft SLA. A decision should
be made regarding which service or customers are to be used for the draft. It is helpful if the
selected customers are enthusiastic and want to participate, perhaps because they are anxious to
see improvements in service quality. The results of an initial customer perception survey can give
pointers for a suitable initial draft SLA.
One difculty sometimes encountered is that staf at diferent levels within the customer
community may have diferent objectives and perceptions. For example, a senior manager might
rarely use a service and may be more interested in issues such as value for money and output,
whereas a junior member of staf may use the service throughout the day and may be more
interested in issues such as responsiveness, usability, and reliability. It is important that all of the
appropriate and relevant customer requirements, at all levels, are identifed and incorporated in
SLAs.
The method separates organizations with horizontal rows. Each activity is placed in the row (swim
lane) that represents the organization responsible for completing the task. Swim lanes rely on
rectangles for activities or tasks, decision diamonds, and arrows to represent fow.
Process swim lanes help companies improve their overall business processes, and thereby
become more competitive and proftable. Swim lanes has become the most ubiquitous term to
describe this method.
The responsibilities of the Availability Management process include:
Ensuring that the level of service availability delivered in all services matches or exceeds
the current and future agreed-upon needs of the business in a cost-efective manner
Providing a point of focus and management for all availability-related issues for both
services and resources
Ensuring that availability targets in all areas are measured and achieved
Availability Management should perform the following activities:
Produce and maintain an appropriate and up-to-date Availability Plan, which refects the
current and future needs of the business
Provide advice and guidance to all other areas of the business and IT on all availability-
related issues
Ensure that service availability objectives meet or exceed all of their agreed-upon targets
by managing services and resources related to availability performance
Assist with the diagnosis and resolution of availability-related incidents and problems
Assess the impact of all changes on the Availability Plan
Assess the performance and capacity of all services and resources
Ensure that proactive measures to improve the availability of services are implemented
whenever the cost justifes it
Like Capacity Management, the Availability Management process and planning must be involved
in all stages of the service lifecycle from strategy and design through transition and operation to
improvement. The appropriate availability and resilience should be designed into services and
components from the initial design stages. This early design will ensure that not only does the
availability of any new or changed service meet expected targets, but that all existing services
and components continue to meet all of their targets. This is the basis of stable service provision.
Proactive Availability Management consists of producing recommendations, plans, and
documents on design guidelines and criteria for new and changed services and the continual
improvement of service.
Proactive Activities are a key part of Service Design and Continual Service Improvement.
Reactive Availability Management consists of monitoring, measuring, analyzing, reporting, and
reviewing all aspects of component and service availability
Availa#ilit% Management Illustrate!
A market space represents a set of opportunities for service providers to deliver value to the
business of a customer through one or more services. Often it is unclear how services create
value for customers. Services are often defned in the terms of resources made available for
customers to use. Service defnitions lack clarity on two points:
Context in which such resources are useful
Business outcomes that justify the expense of a service from the perspective of the
customer.
'vaila(ility Manage$ent escription
The problems associated with lack of clarity lead to poor designs, inefective operation, and
lackluster performance in service contracts. Service improvements are difcult when it is not clear
where improvements are truly required. Customers can understand and appreciate improvements
only within the context of their own business assets, performances, and outcomes. A proper
defnition of services takes into account the context in which customers perceive value from the
services.
An outcome-based defnition of services ensures that managers plan and execute all aspects of
service management entirely from the perspective of what is valuable to the customer. Such an
approach ensures that services not only create value for customers but also capture value for the
service provider.
The Availability Management process continually works to ensure that all operational services
meet their agreed-upon availability targets and that new or changed services are designed
appropriately to meet their intended targets without compromising the performance of existing
services. In order to achieve this goal, Availability Management should perform the reactive and
proactive activities.
Solutions that enable or enhance the performance of the customer assets indirectly support the
achievement of the outcomes generated by those assets. Such solutions and propositions hold
utility for the business. When that utility is backed by a suitable warranty, customers are ready to
buy. Services are a means of delivering value to customers by facilitating outcomes customers
want without owning specifc costs and risks.
Availability is the ability of a service, component, or CI to perform its agreed-upon function when
required. It is often measured and reported as a percentage. In the following example, Availability
equals the Agreed Service Time (AST) minus the downtime and divided by the AST:
Note: Downtime should only be included in the previous calculation when it occurs
within the Agreed Service Time (AST), although total downtime should also be
recorded and reported.
z
&elia#ilit% &elia#ilit% is often measure! an! reporte! as Mean 'ime #et(een
Service Inci!ents (M')SI) or Mean 'ime #et(een *ailures (M')*)+
Reliability is a measure of how long a service, component, or ' can perform its agreed%upon
function without interruption. The reliability of the service can be improved by increasing the
reliability of individual components or by increasing the resilience of the service to individual
component failure (such as increasing the component redundancy, for e&ample by using load
balancing techni#ues).
Maintaina#ilit%
Maintainability is a measure of how quickly and efectively a service, component, or CI can be
restored to normal working after a failure. It is measured and reported as Mean Time to Restore
Service (MTRS) and should be calculated using the following formula shown.
Example: A situation where a 24 x 7 service has been running for a period of 5020 hours with
only two breaks, one of 6 hours and one of 14 hours, would give the following fgures:
Availability = (5020-(6+14)) / 5020 x 100 = 99.60%
Reliability (MTBSI) = 5020 / 2 = 2510 hours
Reliability (MTBF) = 5020 (6+14) / 2 = 2500 hours
Maintainability (MTRS) = (6+14) / 2 = 10 hours
Other Availa#ilit% 'erms
Availability Term Description
Serviceability
The ability of a supplier to meet the terms of the contract. Often this contract
will include agreed- upon levels of availability, reliability, and maintainability
for a supporting service or component.
High Availability
A characteristic of the IT Service that minimizes or masks the efects of IT
component failure to the users of a service.
Fault Tolerance
The ability of an IT service, component, or CI to continue to operate correctly
after failure of a component part.
Continuous Operation
An approach or design to eliminate planned downtime of an IT service. Note
that individual components or CIs might be down even though the IT service
remains available.
Continuous Availability
An approach or design to achieve 100% availability. A continuously Available
IT service has no planned or unplanned downtime.
The key interfaces that Availability Management has with other processes are described in the
following table.
Key Interface Description
Incident and Problem
Management
Interfaces in providing assistance with the resolution and
subsequent, justifcation, and correction of availability incidents
and problems.
Capacity Management Interfaces with the provision of resilience and spare capacity.
IT Service Continuity
Management
Interfaces with the assessment of business impact and risk
and the provision of resilience, fail-over, and recovery
mechanisms.
Service Level Management
Interfaces by assistance with the determining of availability
targets and the investigation and resolution of service and
component breaches.
Availability Management commences as soon as the availability requirements for an IT Service
are clear enough to be articulated. It is an ongoing process, fnishing only when the IT Service is
decommissioned or retired. The key activities of the Availability Management process are as
follows:
Determining the availability requirements from the business for a new or enhanced IT
Service and formulating the Availability and recovery design criteria for the supporting IT
components in conjunction with the business and IT Service Continuity Management
(ITSCM)
Determining the impact arising from IT service and component failure in conjunction with
ITSCM and where appropriate reviewing the Availability design criteria to provide
additional resilience to prevent or minimize impact to the business
Defning the targets for Availability, reliability, and maintainability for the IT Infrastructure
components that underpin the IT Service to enable these to be documented and agreed
upon within SLAs, OLAs, and contracts
Establishing measures and reporting of Availability, Reliability, and Maintainability that
refects the business, user, and IT support organization perspectives
Monitoring and trend analysis of the Availability, Reliability, and Maintainability of IT
components
Reviewing IT service and component availability and identifying unacceptable levels
Investigating the underlying reasons for unacceptable availability
Producing and maintaining an Availability Plan which prioritizes and plans IT availability
improvements
LESSON 5
ITIL Processes and Process Owners
The ITIL Processes and Process Owners along with their underlying topics are in the following
list. This image shows how each process or process owner relates to the ITIL Service Lifecycle.
Service Strategy and the Service Portfolio
Activities of Service Strategy
Develop the Oferings and Strategic Assets
Service Portfolio Management (SPM)
Increasing Service and Performance Potential
Prepare for Implementation
Expansion, Growth, and Diferentiation
Service Catalog Management
Service Measurements and Agreements
Service Level Agreements
Operational Level Agreements
Underpinning Contracts
Service Design Package
Availability, Reliability, Maintainability, and Serviceability
Service Level Management (SLM)
SLM Business Value ,SLM Activities
SLM Input/Output
SLM Key Performance Indicators (KPI's)
SLM Challenges ,Sample Swim Lane Diagram
Availability Management
Proactive versus Reactive Availability Management
Reliability, Availability, Maintainability
Other Availability Terms ,Availability Management Interfaces
Information Security Management
Security Framework
Contents of the Information Security Policy
Information Security Management Interfaces
Process and Service Roles
Process Owners
Service Owners ,Service Manager Continual Service Improvement Manager
&nfor$ation Sec%rity Manage$ent +&SM,
The ISM process aligns IT security with business security and ensures that information security is
efectively managed in all service and Service Management activities. ISM manages all aspects
of IT and information security within all areas of IT and Service Management activity. Security
must address entire business processes from end to end and cover the physical and technical
aspects.
The goal of the Information Security Management (ISM) process is to align IT security with
business security and ensure that information security is efectively managed in all service and
Service Management activities.
The term information is used in a general way and includes data stores, databases and metadata.
Information security protects the interests of those relying on information, and the systems and
communications that deliver the information. It protects the interests from harm resulting from
failures of availability, confdentiality, and integrity.
For most organizations, the security objective is met when the following criteria occur:
Information is available and usable when required, and the systems that provide it can
appropriately resist attacks and recover from or prevent failures (availability)
Information is only observed by, or disclosed to, those who have a right to know
(confdentiality)
Information is complete, accurate, and protected against unauthorized modifcation
(integrity)
Business transactions as well as information exchanges between enterprises, or with
partners, can be trusted (authenticity and non repudiation)
Sec%rity *ra$e-or.
The Information Security Management process and framework will usually consist of the following
items:
An Information Security Policy (ITP) and specifc security policies that address each
aspect of strategy, controls and regulation
An Information Security Management System (ISMS), containing the standards,
management procedures and guidelines supporting the information security policies
A comprehensive security strategy closely linked to the business objectives, strategies
and plans
An efective security organizational structure
A set of security controls to support the ITP
The management of security risks
Monitoring processes to ensure compliance and provide feedback on efectiveness
Communications strategy and plan for security
Training and awareness strategy and plan
#ontents of the &nfor$ation Sec%rity Policy
Information Security Management activities should be focused on and driven by an overall
Information Security Policy (ITP) and a set of underpinning specifc security policies. The ITP
should have the full support of top executive IT management and ideally the support and
commitment of top executive business management. The ITP should cover all areas of security,
be appropriate, meet the needs of the business and include the following items:
An overall ITP
The use and misuse of IT assets policy
An access control policy
A password control policy
An e-mail policy
An Internet policy
An anti-virus policy
An information classifcation policy
A document classifcation policy
A remote access policy
A policy with regard to supplier access of IT service, information, and components
An asset disposal policy
These policies should be widely available to all customers and users. All SLR's, SLA's, contracts,
and agreements should refer to compliance with these policies. The policies should be authorized
by top executive management within the business and IT. Compliance should be endorsed on a
regular basis. All security policies should be reviewed and, when necessary, revised on at least
an annual basis.
Information Securit% Process To (e effective! sec%rity $%st address entire (%siness
processes fro$ end/to/end and cover the physical and technical aspects. &SM raises the
a-areness of the need for sec%rity -ithin all &T services and assets thro%gho%t the
organi0ation! ens%ring that the &TP is appropriate for the needs of the organi0ation. &SM
$anages all aspects of &T and infor$ation sec%rity -ithin all areas of &T and Service
Manage$ent activity.
ISM provides assurance of business processes by enforcing appropriate security controls in all
areas of IT and by managing IT risk in line with business and corporate risk management
processes and guidelines.
Information Security Management (ISM) interfaces include the following items:
SLM Interface Description
Incident and Problem Management
This provides assistance with the resolution and
subsequent, justifcation, and correction of security
incidents and problems. The Incident Management process
must include the ability to identify and deal with security
incidents. Service Desk and Service Operation staf must
recognize a security incident.
IT Service Continuity Management
(ITSCM)
ITSCM deals with the assessment of business impact and
risk and the provision of resilience, failover, and recovery
mechanisms. Security is a major issue when continuity
plans are tested or invoked. A working ITSCM plan is a
mandatory requirement for ISO27001.
Service Level Management (SLM)
SLM provides assistance with the determining of security
requirements and responsibilities and their inclusion within
SLR's and SLA's together with the investigation and
resolution of service and component security breaches.
Change Management
ISM should help assess every change for impact on
security and security controls. Also ISM can provide
information on unauthorized changes.
Legal and HR Department
Legal and HR issues must be considered when
investigating security issues.
Confguration Management
Confguration Management will give the ability to provide
accurate asset information to assist with security
classifcations. Having an accurate CMS is therefore an
extremely useful ISM input.
Capacity Management
Capacity Management must consider security implications
when selecting and introducing new technology. Security is
an important consideration when procuring any new
technology or software.
FinanZZcial Management
Financial Management provides adequate funds required to
fnance security requirements.
Supplier Management
Supplier Management assists with the joint management of
suppliers and their access to services and systems and the
terms and conditions to be included within contracts
concerning supplier responsibilities.
Note: Security is often seen as an element of Availability Management with
Confdentiality Integrity and Availability (CIA) being at the essence of Availability and
ISM. Also ISM should work with both Availability Management and IT Service
Continuity Management (ITSCM) to conduct integrated risk assessment and
management exercises.
Lesson 1: Process and Service "-ners
ITIL Processes and Process Owners
The ITIL Processes and Process Owners along with their underlying topics are listed in the
following image. This image shows how each process or process owner relates to the ITIL
Service Lifecycle.
Service Strategy and the Service Portfolio
Activities of Service Strategy
Develop the Oferings and Strategic Assets
Service Portfolio Management (SPM)
Increasing Service and Performance Potential
Prepare for Implementation
Expansion, Growth, and Diferentiation
Service Catalog Management
Service Measurements and Agreements
Service Level Agreements
Operational Level Agreements
Underpinning Contracts
Service Design Package
Availability, Reliability, Maintainability, and Serviceability
Service Level Management (SLM)
SLM Business Value
SLM Activities
SLM Input/Output
SLM Key Performance Indicators (KPI's)
SLM Challenges
Sample Swim Lane Diagram
Availability Management
Proactive versus Reactive Availability Management
Reliability, Availability, Maintainability
Other Availability Terms
Availability Management Interfaces
Information Security Management
Security Framework
Contents of the Information Security Policy
Information Security Management Interfaces
Process and Service Roles
Process Owners
Service Owners
Service Manager
Continual Service Improvement Manager
Process Owners are responsible for ensuring that their processes are performed according to
the agreed-upon and documented process and that the processes meet the aims of their
defnitions. Duties of Process Owners include the following tasks:
Documenting and publicizing the process.
Defning the Key Performance Indicators (KPI's) to evaluate the efectiveness and
efciency of the process.
Reviewing KPI's and taking action required following the analysis.
Improving the efectiveness and efciency of the process.
Ensuring all relevant staf have the required training in the process and are aware of their
role in the process.
Interacting with line management to ensure that the process receives the needed staf
resources. Line management and Process Owners have complementary tasks. They
need to work together to ensure efcient and efective processes. Often line management
ensures the required training of staf.
The Service Owner is responsible to the customer for the initiation, transition, and ongoing
maintenance and support of a particular service. The Service Owner has the following
responsibilities:
Act as primary customer contact for all service-related enquiries and issues.
Ensure that the ongoing Service delivery and support meet agreed-upon customer
requirements.
Identify opportunities for service improvements, discuss them with the customer, and
raise the RFC for assessment, if appropriate.
Interact with the appropriate Process Owners throughout the Service Management
lifecycle.
Solicit required data, statistics, and reports to analyze and to facilitate efective service
monitoring and performance.
Will be accountable to the IT Director for the delivery of the service.
The key responsibilities of a Service Manager are as follows:
Provide leadership on the development of business case and product line strategy and
architecture, new service deployment and lifecycle management schedules.
Perform Service Cost Management activities in close partnership with other organizations
such as Operations, Engineering, and Finance. Many of these organizations are held to
strict internal supplier agreements.
Manage various and sometimes conficting objectives in order to achieve the goals and
fnancial commitments of the organization.
Create an imaginative organization which encourages high performance and innovative
contributions from members within a rapidly changing environment.
The key responsibilities of the Continual Service Improvement Manager are as follows:
Communicates the vision of CSI across the IT organization
Works with the Service Owner to identify and prioritize improvement opportunities
Works with the Service Level Manager to ensure that monitoring requirements are
defned
Works with the Service Level Manager to identity Service Improvement Programs
Ensures that monitoring tools are in place to gather data
Ensures baseline data is captured for comparing with improvement data
Defnes and reports on CSI Critical Success Factors, Key Performance Indicators and
CSI activity metrics
Identifes other frameworks, models, and standards that will support CSI activities
Presents recommendations to Senior Management for improvement
Identifes and delivers process improvements in critical business areas across
Manufacturing and relevant divisions.
You should now be able to:
Discuss the main activities of Service Strategy, including Defning the Market, Preparing
for Implementation, Developing Service Oferings and Strategic Assets
Explain the use of Service Measurements and Agreements
Describe the concepts and activities related to Service Level Management, including
Input, Output, and Service Level Agreements
Diferentiate between Proactive and Reactive Availability Management
Describe the framework of Information Security Management
Explain the roles of Continuous Service Improvement
UNIT - 5 Service Design, Service 'ransition, an!
Service Operation
Introduction
Service Design, Service Transition, and Service Operation make up in the second ring of the ITIL
Service Lifecycle.
Objectives
After completing this unit, you should be able to:
Explain the Supplier Management processes and interfaces
Describe the Service Design Roles
Compare the Change Management Concepts and Processes including Standard and
Emergency change requests
Know the seven R's of Change Management
Describe the logical model of Service Asset Confguration Management
Explain Release Management
Identify the Service Transition Roles
Illustration of Service Implementation
Service Implementation is the second ring of the ITIL Service Lifecycle, including the sections on
Service Design, Service Transition, and Service Operation. The rollover image describes these
sections in the following list:
Supplier Management
Supplier Management Process
Supplier Management Interfaces
Service Design Roles
Service Catalog Manager
Service Level Manager
Availability Manager
Security Manager
Change Management Concepts
Service and Change Request
Standard Changes, Emergency Changes
Release Unit
Seven R's of Change Management
Change Management Policies
Policies Supporting Change Management
Standard Changes
Change Management Process
Change Management Interfaces
Change Management KPIs
Service Asset Confguration and Release Management (SACM)
Confguration Items
SACM Interfaces
Release and Deployment Management
Factors to Consider for Release Units
Release Management Process
Service Transition Roles
Service Asset Manager
Confguration Manager
Confguration Management System
Types of Confguration Items
Change Manager
Change Advisory Board
Release Package and Build Manager
Deployment Manager
Supplier Management Process
The job of the Supplier Management process is to ensure that suppliers meet the conditions,
terms, and targets of their agreements and contracts. At the same time, the process aims to
increase the return on investment obtained from suppliers and the services they provide.
Supplier Management process activity should be driven by a supplier strategy and Service
Strategy policy. In order to achieve consistency and efectiveness in the implementation of the
policy, a Supplier and Contracts Database (SCD) should be established, with clearly defned roles
and responsibilities.
The services provided by suppliers will also form a key part of the Service Portfolio and the
Service Catalog. The relationship between the supporting services and the IT and business
services they support are key to providing quality IT services.
Supplier Management Interfaces include the management systems in the following list:
IT Service Continuity Management
Service Level Management
Information Security Management
Financial Management
Service Portfolio Management
Problem and Incident Management
Events that could trigger Supplier Management activity include:
New or changed corporate governance guidelines
New or changed business and IT strategies, policies, or plans
New or changed business needs, or new or changed services
New or changed requirements within agreements, such as SLRs, SLAs, OLAs, or
contracts
Review and revision of designs and strategies
Periodic activities such as reviewing, revising, or reporting, including review and revision
Supplier Management policies, reports, and plans
Requests from other areas, particularly SLM and Security Management for assistance
with supplier issues
Requirements for new contracts, contract renewals, or contract terminations
Recategorization of suppliers and or contracts
The key interfaces that Supplier Management with other processes are:
IT Service continuity Management (ITSCM): helps manage the continuity service
supplier.
SLM: assists targets, requirements, and responsibilities and their inclusion within
underpinning agreements and contracts to ensure that they support all SLR and SLA
targets. Also the investigation of SLA and SLR breaches caused by poor supplier
performance.
ISM: the management of suppliers and their access to service and systems and their
responsibilities with regards to conformance to ISM policies and requirements.
Financial Management: provides adequate funds required to fnance Supplier
Management requirements and contracts and to provide advice and guidance on
purchase and procurement matters.
Service Portfolio Management: ensures that all supporting services and their details and
relationships are accurately refected within the Service Portfolio.
Service design includes the following roles:
Service Catalog Manager
Service Level Manager
Availability Manager
Security Manager
The Service Catalog Manager has responsibility for producing and maintaining the Service
Catalog, which includes the following responsibilities:
Ensuring that all operational service and all services being prepared for operational
running are recorded within the Service Catalog
Ensuring that all of the information within the Service Catalog is accurate and up to date
Ensuring that all of the information within the Service Catalog is consistent with the
information within the Service Portfolio
Ensuring that the information within the Service Catalog is adequately protected and
backed up
The Service Level Manager ensures that the aims of Service Level Management are met,
including the following responsibilities:
Keeping aware of changing business needs
Ensuring that the current and future service requirements of customers are identifed,
understood, and documented in SLA and SLR documents
Negotiating and agreeing upon levels of service to be delivered to the customer (either
internal or external). Formally documenting these levels of service in SLAs
Negotiating and agreeing upon OLAs and in some cases other SLAs and agreements
that underpin the SLAs with the customers of the service
The Availability Manager has responsibility for ensuring that the aims of Availability Management
are met, including the following responsibilities:
Ensures that all existing services deliver the levels of availability agreed with the business
in SLA's
Assists with the investigation and diagnosis of all incidents and problems that cause
availability issues or unavailability of services or components
Participates in the IT infrastructure design, including the specifcation of the availability
requirements for hardware and software
Proactively improves service availability wherever possible and optimizes the availability
of the IT infrastructure
Assists Security and IT Service Continuity Management with the assessment and
management of risk
The Security Manager has responsibility for ensuring that the aims of Information Security
Management are met, including the following tasks and responsibilities:
Developing, maintaining, and communicating the Information Security Policy
Identifying and classifying IT and information assets (Confguration Items) and the level of
control and protection required
Performing security risk analysis and risk management in conjunction with Availability and
IT Service Continuity Management
Monitoring and managing all security breaches and handling security incidents and taking
remedial action to prevent recurrence wherever possible
Reporting, analyzing, and reducing the impact and volumes of all security incidents in
conjunction with Problem Management
Ensuring that all changes are assessed for impact on all security aspects
Ensuring that the confdentiality, integrity, and availability of the services are maintained
at the levels agreed upon in the SLAs
Ensuring that all access to services by external partners and suppliers is subject to
contractual agreements and responsibilities
Acting as a focal point for all security issues
For Change Management in Service Implementation, you will need to know the ITIL concepts in
the following list:
Service Change
Service Request
Change Types: Standard Changes
Change Types: Emergency Changes
Release Unit
Seven Rs of Change Management
Service Change is the addition, modifcation, or removal of authorized, planned, or supported
service or service component and its associated documentation. Each organization should defne
the changes that lie outside the scope of their service change process. In this context, Service
Change will deal primarily with Service Operational Changes, but organizations can use the
service. Change process for strategic changes or portfolio changes if they choose.
The scope of Change Management covers changes to baseline service assets and confguration
items across the whole Service Lifecycle.
Changes that lie outside the scope of a service change process of an organization might include:
Changes with signifcantly wider impacts than service changes, for example,
departmental organization, policies, business operations. These changes would produce
Requests for Change (RFCs) to generate consequential service changes.
Changes at an operational level, such as repair to printers or other routine service
components
Service Request is a generic description for many varying types of demands that are placed upon
the IT department by the users. The scale and frequent, low-risk nature means that service
requests are better handled by a separate process, rather than being allowed to congest and
obstruct the normal incident and Change Management processes.
Many service requests are actually small changes. Service Requests have the following
characteristics:
Low risk
Frequently occurring
Low cost
Examples of service requests include:
A request to change a password
A request to install an additional software application onto a particular workstation
A request to relocate some items of desktop equipment
A question requesting information
Change Request is a formal communication seeking an alteration to one or more Confguration
Items. Change requests can take several forms. Diferent types of change may require diferent
types of change requests.
An organization needs to ensure that appropriate procedures and forms are available to cover the
anticipated requests. Avoiding a bureaucratic approach to documenting a minor change removes
some of the cultural barriers to adopting the change management process.
Some of the forms might be:
A request for change document
A service desk call
A project initiation document
#hange Types: Standard #hange
You will need to change to a service or infrastructure when the change:
Is preauthorized by Change Management
Has an accepted and established procedure to provide a specifc change requirement
Changes are Intended to introduce immediately required business improvements are handled
as normal changes, assessed as having the highest urgency.
Examples of a standard change type might include:
An upgrade of a computer in order to make use of specifc standard and prebudgeted
software
Desktop move for single user
Low-impact, routine application change to handle seasonal variation
Change Types: Emergency Changes
Emergency changes are sometimes required and should be
Designed carefully
Tested before use
May document some details retrospectively
Reserved for changes intended to repair an error in an IT service
Note: To initiate emergency changes, the IT service must be negatively afecting
the business to a high degree.
The number of emergency changes should be kept to an absolute minimum, because they are
generally more disruptive and prone to failure.
Occasions will occur when emergency changes are essential. Consequently, procedures should
be devised to deal with them quickly, without sacrifcing normal management controls.
If emergency changes are not designed carefully and tested before use, the impact of the
emergency change may be greater than the original.
A Release Unit is a portion of a service or IT infrastructure that is normally released together
according to the release policy of the organization. The unit may vary, depending on the type or
items of service asset or service component such as software and hardware.
An organization may, for example, decide that the Release Unit for business critical applications is
the complete application in order to ensure that testing is comprehensive. The same organization
may decide that a more appropriate Release Unit for a Web site is at the page level.
A Release Unit to upgrade to a small portion of a sales application may require the entire site
contents to be packaged and released together.
The questions for the Seven R's of Change Management must be answered for all changes.
1.Who raised the change?
2.What is the reason for the change?
3.What is the return required from the change?
4.What are the risks involved in the change?
5.What resources are required to deliver the change?
6.Who is responsible for the build, test, and implementation of the change?
7.What is the relationship between this change and other changes?
Without this information, the impact assessment cannot be completed, and the balance of risk
and beneft to the live service will not be understood. Without this understanding, the change
might not deliver all of the possible or expected business benefts. The change might even have
an unexpected detrimental efect on the live service.
Change Management responds to the changing business requirements of the customer while
reducing incidents,disruption, and rework. Change Management responds to the business and IT
requests for change. The change management process should ensure that changes are recorded
and then evaluated, authorized, prioritized, planned, tested, implemented, documented, and
reviewed in a controlled manner.
The goals of change management are to:
Respond to the changing business requirements of the customer while maximizing value
and reducing incidents, disruption, and rework
Respond to the business and IT requests for change that will align the services with the
business needs
Changes arise for a variety of reasons:
Proactive changes, such as reducing costs, improving services, or increasing the ease
and efectiveness of support.
Reactive changes are a means of resolving errors and of adapting to changing
circumstances, supporting new product lines, and so forth.
Changes should be managed for the following reasons:
To optimize risk exposure (supporting the risk profle required by the business)
To minimize the severity of any impact and disruption
To be successful on the frst attempt
To make an appropriate response to all Requests for Change, Change Management should
include an assessment of risk and business continuity, change impact, resource requirements,
change authorization, and especially the realizable business beneft.This is essential to maintain
the required balance between the need for change and the impact of the change.
Each organization should defne the changes that lie outside the scope of their service change
process, which typically might include the following changes:
Changes with signifcantly wider impacts than service changes, for example,
departmental organization, policies, and business operations. These changes would
produce RFCs to generate consequential service changes.
Changes at an operational level, such as repair to printers or other routine service
components.
The value of Change Management includes the following benefts:
Prioritizing and responding to change requests
Reducing failed changes and service disruption
Delivering change promptly
Tracking changes through the Service Life Cycle, contributing to better estimations of the
quality, time, and cost of change
Reducing disruptions due to high levels of unplanned or emergency changes
Reducing the Mean Time to Restore service (MTRS) through quicker and more
successful implementations of corrective changes
By managing changes, you manage much of the potential risk that changes can introduce.
Service and infrastructure changes can have a negative impact on the business through service
disruption and delay in identifying business requirements. However, Change Management
enables the service provider to perform the following tasks:
Prioritizing and responding to business and customer change proposals
Implementing changes that meet the agreed-upon service requirements of the customers
while optimizing costs
Reducing failed changes and therefore service disruption, defects, and rework
Delivering change promptly to meet business time scales
Tracking changes through the Service Life Cycle and to the assets of its customers
Contributing to better estimations of the quality, time, and cost of change
Assessing the risks associated with the transition of services (introduction or disposal)
Aiding productivity of staf through minimizing disruptions due to high levels of unplanned
changes or emergency changes, hence maximizing service availability
Reducing the Mean Time to Restore Service (MTRS) through quicker and more
successful implementations of corrective changes
Policies that support change management include:
Creating a culture of change management across the organization where there is zero
tolerance for unauthorized change
Aligning the service change management process with business, project, and
stakeholder change management processes
Prioritizing change such as innovation, prevention, detection, corrective change
Segregating of duty controls
Establishing a single focal point for changes in order to minimize the probability of
conficting changes and potential disruption to the production environment
Integrating with other service management processes to establish traceability of change,
detect unauthorized change, and identify change-related incidents
Establishing performance measures for the process, for example, efciency and
efectiveness
A Standard Change is a change to a service or infrastructure for which the approach is
preauthorized by change management. There is an accepted and established procedure to
provide a specifc change requirement. Examples might include an upgrade of a PC in order to
use specifc standard and prebudgeted software, new employees within an organization, a
desktop move for single user. Other examples include low-impact, routine application change to
handle seasonal variation.
Approval of each occurrence of a standard change will be granted by the delegated authority for
that standard change. Examples of delegated authority include: the budget holding customer for
installing software from an approved list on a PC registered to their organizational unit or the
external vendor engineer for replacing a faulty desktop printer.
The crucial elements of a Standard Change are as follows:
There is a defned trigger to initiate the RFC.
The tasks are well-known, documented, and proven.
Authority is efectively given in advance.
Budgetary approval will typically be preordained or within the control of the Change
requester.
The change usually has a low risk and always a well-understood risk.
Standard Changes should be identifed early when building the Change Management process to
promote efciency. Otherwise, a Change Management implementation can create unnecessarily
high levels of administration and resistance to the Change Management process. All changes,
including Standard Changes, will have details of the change recorded. For some Standard
Changes, this record will difer from normal change records.
Some Standard Changes to Confguration Items may be tracked on the asset or CI lifecycle,
particularly where a comprehensive CMS provides:
Reports of changes
Current status of changes
Related confguration items
Status of the related CI versions
In these cases the Change Management and Confguration Management reporting is integrated.
Change Management can have oversight over all changes to service CIs and release CIs.
Managing individual changes typically include the following activities:
Create and recording changes
Review RFC and change proposal
Filter changes (for example, incomplete changes, wrongly routed changes)
Assess and evaluate the change
Establish appropriate level of change authority
Establish relevant areas of interest (such as who should be involved in Change Advisory
Board)
Assess and evaluate the business justifcation, impact, cost, benefts, and risk of changes
Request independent evaluation of a change
Authorize the change
Obtain authorization and rejection
Communicate the decision with all stakeholders, in particular the initiator of the request
for change
Plan updates
Coordinate change implementation
Review and close change
Collate the change documentation, for example, baselines and evaluation reports
Review the changes and change documentation
Close the change document when all actions are completed
Throughout all the previous process activities and those described within this section, information
is gathered, recorded in the CMS, and then reported.
Change Management Interfaces
Service Management processes might require change and improvements. Many will also be
involved in the impact assessment and implementation of service changes. The following table
describes the Change Management Interfaces.
Change Management Interface Description
Release Management
Processes used for organizational programs or
projects, including supplier management, and
processes and procedures of the supplier.
Occasionally a proposed Change will potentially have a
wider impact upon other parts of the organization (for
example, facilities or business operations), or vice
versa. The service change process must interface
appropriately with other processes involved.
Asset and Confguration
Management
The Confguration Management System provides
reliable, quick, and easy access to accurate
confguration information to enable stakeholders and
staf to assess the impact of proposed changes and to
track the workfow of a change. This information
enables the correct asset and service component
versions to be released to the appropriate party or into
the correct environment. As changes are implemented,
the confguration management information is updated.
The CMS may also identify related CI and assets that
will be afected by the change, but not included in the
original request, and similar CI and assets that would
beneft from similar change.
Problem Management
Changes are often required to implement workarounds
and to fx known errors. Problem Management is one
of the major sources of Requests for Changes (RFC's)
and also often a major contributor to Change Advisory
Board (CAB) discussion.
IT Service Continuity
Procedures and plans should be updated through
change management to ensure that they are accurate,
up to date, and distributed to stakeholders.
Security Management
Changes required by security will go through the
change management process and security will be a
key contributor to CAB discussion on many services.
Every signifcant change will be assessed for its
potential impact on the security plan.
Capacity and Demand Management
Poorly managed demand is a source of costs and risk
for service providers because uncertainty is always
associated with the demand for services. Capacity
management has an important role in assessing
proposed changes, not only the individual changes but
the total impact of changes on service capacity.
Changes arising form capacity management, including
those set out in the capacity plan, will be initiated as
RFCs through the change process.
Change Management Key Performance Indicators
Change Management must ensure that measures that have specifc meaning. While it is relatively
easy to count the number of incidents that eventually generate changes, it is infnitely more
valuable to look at the underlying cause of such changes, and to identify trends. Better still is to
be able to:
Measure the impact of change
Demonstrate reduced disruption over time because of the introduction of Change
Management
Measure the speed and efectiveness with which the IT infrastructure responds to
identifed business needs
Measures taken should be linked to business goals, wherever practical, and to cost, service
availability, and reliability. Any predictions should be compared with actual measurements.
The Key Performance Indicators for Change Management include the following measurements:
The number of changes implemented to services which met the agreed-upon
requirements of the customer such as quality, cost, and time (expressed as a percentage
of all changes)
The benefts of change expressed as value of improvements made + negative impacts
prevented or terminated compared to the costs of the change process
Reduction in the number of disruptions to services, defects and rework caused by
inaccurate specifcation, and poor or incomplete impact assessment
Reduction in the number of unauthorized changes
Reduction in the backlog of change requests
Reduction in the number and percent of unplanned changes and emergency fxes
Change success rate (percentage of changes deemed successful at review and number
of RFC's approved)
Reduction in the number of changes when remediation is invoked
Reduction in the number of failed changes
Average time to implement based on urgency, priority, and change type
Incidents attributable to changes
Percentage accuracy in change estimate
Service Asset and Confguration Management (SACM) is used for the following reasons:
To protect the integrity of service assets and confguration items (and where appropriate,
those of its customers) through the Service Lifecycle
To place IT assets and designated confguration items within the Service Lifecycle under
confguration management
To ensure the integrity of the assets and confgurations required to control the services
and IT infrastructure by establishing and maintaining and accurate a complete
Confguration Management system
To support efcient and efective business and service management processes by
providing accurate information about assets and confguration items
The goal of Service Asset and Confguration Management is to provide a logical model of the IT
infrastructure correlating IT services and diferent IT components (physical, logical, and so on)
needed to deliver these services by defning and controlling the components of services and
infrastructure and maintaining accurate confguration records.
This goal enables an organization to comply with corporate governance requirements, control the
asset base, optimize the costs, manage change and releases efectively, and resolve incidents
and problems faster.
Service Asset and Confguration Management optimizes the performance of service assets and
confgurations, improves the overall service performance, and optimizes the costs and risks
caused by poorly managed assets such as service outages, fnes, correct licence fees, and failed
audits.
SACM provides visibility of accurate representations of a service, release, or environment that
enable the following events to occur:
Better forecasting and planning of changes
Changes and releases to be assessed, planned, and delivered successfully
Incidents and problems to be resolved within the service level targets
Warranties to be delivered
Better adherence to standards, legal, and regulatory obligations (fewer
nonconformances)
More business opportunities because of ability to demonstrate control of assets and
services
Changes to be traceable from requirements
New ability to identify the costs for a service
SACM Logical Model
Confguration Management delivers a required logical model of the services, assets, and the
infrastructure by recording the relationships between confguration items. The real power of the
logical model of the infrastructure of confguration management is that it is the main model. It is a
single common representation used by all parts of IT Service Management, and beyond, such as
Human Resources, Finance, supplier, and customers.
The Confguration Items and related confguration information can be at varying levels of detail,
such as an overview of all the services or a detailed level to view the specifcation for a service
component.
A more detailed level of Confguration Management should be used where the service provider
requires tight control, traceability, and tight coupling of confguration information through the
Service Lifecycle.
A Confguration Item (CI) is an asset, service component, or other item which is, or will be, under
the control of Confguration Management. Confguration Items may vary widely in complexity,
size, and type, ranging from an entire service or system including all hardware, software,
documentation, and support staf to a single software module or a minor hardware component.
Confguration Items may be grouped and managed together. An example would be a set of
components may be grouped into a release. Confguration Items should be selected using
established selection criteria, grouped, classifed, and identifed in such a way that they can be
managed and traced throughout the Service Life Cycle.
There will be a variety of CIs, and the following categories can help identify them:
Service Lifecycle CIs include the business case, Service Management plans, Service
Lifecycle plans, Service Design Package, Release and Change plans, and Test plans.
They provide a picture of the services of the service provider, how these services will be
delivered, what benefts are expected, at what cost, and when they will be realized.
Service CIs include:
o Service capability assets (management, organization, processes, knowledge,
people)
o Service resource assets (fnancial capital, systems, applications, information,
data, infrastructure and facilities, fnancial capital, people)
o Service Model
o Service Package
o Release Package
o Service Acceptance Criteria
Organization CIs: Some documentation will defne the characteristics of a CI whereas
other documentation will be a separate CI and need to be controlled, for example, the
business strategy of the organization or other policies that are internal to the organization
but independent of the service provider. Regulatory or statutory requirements also form
external products that need to be tracked, as do products shared between more than one
group.
Internal CIs: Comprising those delivered by individual projects, including tangible assets
such as a data center, and intangible assets, such as software, that are required to
deliver and maintain the service and infrastructure.
External CIs: Can be external customer requirements and agreements, releases from
suppliers or subcontractors, and external services.
SACM is the single virtual repository of data and information for IT service management.
Consequently, SACM supports and interfaces with every other process and activity to some
degree. Some of the more noteworthy interfaces are shown in the following table.
Service Asset and Confguration Management Interfaces
Asset or Interface Description
Change Management Identifying impact of proposed changes
Financial Management Capturing key fnancial information such
as cost, depreciation methods, owner,
and user (for budgeting and cost
allocation), maintenance costs and
repair costs
IT Service Continuity Management (ITSCM)
Awareness of assets the business
services depend on, control of key
spares, and control of software
Incident, Problem, or Error Management
Providing and maintaining key
diagnostic information, maintenance
and provision of data to Service Desk
Availability Management Only for detection of points of failure
Confguration Control (synonymous with change
control)
Understanding and capturing updates to
the infrastructure and services
The goals of release and deployment management are to deploy releases into production and
to enable efective use of the service in order to deliver value to the customer.
Well-planned and implemented release and deployment makes a signifcant diference to the
service costs of an organization. A poorly designed release or deployment will, at best, force IT
personnel to spend signifcant amounts of time troubleshooting problems and managing
complexity. At worst, it can cripple the environment and degrade the live services.
A Release unit describes the portion of a service or it infrastructure that is normally released
together according to the release policy of the organization. The unit may vary, depending on the
types or items of service asset or service component such as software and hardware.
The general aim is to decide upon the most appropriate Release unit level for each service asset
or component. An organization may, for example, decide that the Release unit for business critical
applications is the complete application in order to ensure that testing is comprehensive. The
same organization may decide that a more appropriate Release unit for a Web site is at the page
level.
Factors to consider for Release units include the following items:
The ease and amount of change necessary to release and deploy a Release unit
The amount of resources and time needed to build, test, distribute, and implement a
Release unit
The complexity of interfaces between the proposed unit and the rest of the services and
IT infrastructure
The storage available in the build, test, distribution, and live environments.
Releases should be uniquely identifed according to a scheme defned in the release policy. The
release identifcation should include a reference to the CIs that it represents and a version
number that will often have two or three parts, for example, emergency fx releases:
Payroll_System v.1.1.1, v.1.1.2, v.1.1.3.
The release process commences with receipt of an approved RFC to deploy a production-ready
Release Package. Deployment commences with receipt of an approved RFC to deploy a Release
Package to a target deployment group or environment. Examples include a business unit,
customer group, or service unit.
Deployment is completed with a transfer of the new or changed service to Operations. This
transfer occurs when Change Management successfully completes a Post Implementation
Review of the deployment
Lesson 6: Service Transition Roles and Management Items
The Service Asset Manager has the following responsibilities:
Evaluates existing Asset Management systems and the design
Develops Asset Management standards, Asset Management plans, and procedures
Arranges recruitment and training of staf
Ensures that staf comply with identifcation standards
Proposes interfaces, agrees to interfaces, or both with Change Management, Problem
Management, Network Management, Release Management, computer operations,
logistics, fnance, and administration functions
Plans and manages the Asset database, including central libraries and tools
Provides reports, including management reports (indicating suggested action to deal with
current or foreseen shortcomings), impact analysis reports, and asset status reports
The Confguration Manager has the following responsibilities:
Evaluates existing Confguration Management Systems (CMS) and their design
Ensures that CIs are uniquely identifed and conform with naming conventions
Ensures that staf comply with identifcation standards for object types, environments,
processes, lifecycles, documentation, versions, formats, baselines, releases, and
templates
Proposes interfaces, agrees to interfaces, or both, with Change Management, Problem
Management, Network Management, Release Management, computer operations,
logistics, fnance, and administrative functions
Plans, manages, and regularly maintains the CMS, including central libraries, tools,
common codes, and data
Provides reports, including management reports (indicating suggested action to deal with
current or foreseen shortcomings), impact analysis reports, and confguration status
reports
The Confguration Management System (CMS) holds all the information for CIs within the
designated scope, and is used for wide range of purposes.
CMS maintains the relationships between all service components and any related
incidents, problems, known errors, change and release documentation
CMS could contain corporate data about employees, suppliers, locations and business
units, customers, and users
Some of these items will have related specifcations or fles that contain the contents of the item
such as software, documents, or a photograph.
For example, a Service CI will include the details such as supplier, cost, purchase date, and
renewal date for licenses and maintenance contracts, and the related documentation, such as
SLAs and Underpinning Contracts.
Note: Asset data held in a CMS (CMDB data) may be made available to external
fnancial Asset Management systems to perform specifc asset management
process reporting outside of Confguration Management
A Confguration Item (CI) is an asset, service component, or other item which is, or will be,
under the control of Confguration Management. They vary widely in complexity, size, and type.
CIs may be grouped and managed together.
Confguration Items should be selected using established selection criteria, grouped, classifed,
and identifed in such a way that they are managed and traced throughout the Service Lifecycle.
Confguration Items can range from an entire service or a system including all hardware,
software, documentation, and support staf to a single software module or a minor hardware
component.
An example of grouping of components is a new release.
*%nctions of #onfig%ration &te$s
Service Lifecycle Confguration Items (CIs) provide a picture of the services of the service
provider, how these services will be delivered, what benefts are expected, at what cost, and when
they will be realized.Organization CIs include items such as the business strategy or other internal
organizational policies. Regulatory or statutory requirements also need to be tracked.
Internal CI's comprise CIs delivered by individual projects, including tangible (data center) and
intangible assets such as software that are required to deliver and maintain the service and
infrastructure.External CIs include external customer requirements and agreements, releases
from suppliers or subcontractors, and external services.
The main duties of the Change Manager, some of which may be delegated, are as follows:
Receive, log, and allocate a priority, in collaboration with the initiator, to all Requests for
Change (RFC's). Reject any totally impractical RFCs.
Chair all Change Advisory Board (CAB) and Emergency Change Advisory Board (ECAB)
meetings, table all RFCs for a CAB meeting, issue an agenda, and circulate all RFCs to
CAB members before meetings to allow prior consideration.
Determine meeting invitations and allocate specifc RFCs (depending on the nature of the
RFC, the changes, and areas of expertise of the personnel).
After consideration of the advice given by the CAB or ECAB, authorize acceptable
changes.
Issue Change Schedules through the Service Desk.
Review all implemented changes to ensure that they have met their objectives. Refer
back any that have been reversed or have failed
The Change Advisory Board (CAB) is a body that exists to support the authorization of changes
and to assist Change Management in the assessment and prioritization of changes. As and when
a CAB is convened, members should be chosen who are capable of ensuring that all changes
within the scope of the CAB are adequately assessed from both a business and a technical
viewpoint. When the need for emergency change arises, there may not be time to convene the full
CAB. It is necessary to identify a smaller organization with authority to make emergency
decisions. This body is the Emergency Change Advisory Board (ECAB).
The CAB may be asked to consider and recommend the adoption or rejection of changes
appropriate for higher level authorization. Then recommendations will be submitted to the
appropriate change authority. Important features of the CAB include the following items:
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 is useful
Should refect both user and customer views
Is likely to include the Problem Manager, Service Level Manager, and Customer Relations
staf for at least part of the time
Release Packaging and Build Management is the fow 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
as follows:
Establish the fnal release confguration (for example, knowledge, information, hardware,
software, and infrastructure)
Build the fnal release delivery
Test the fnal delivery prior to independent testing
Establish and report outstanding known errors and workarounds
Provide input to the fnal implementation sign-of process
The Release Packaging and Build Manager cannot perform this role in isolation. This role will
have signifcant interaction with the following functions, among others:
Change and Service Asset Confguration Management
Capacity Management
Availability Management
Incident Management
The Deployment Manager is responsible for the following activities:
Delivers the service implementation in its fnal physical form
Co-ordinates release documentation, other release communications, and technical
release notes. Provides documentation and communication for training, customers, and
service management
Plans the deployment in conjunction with Change and Service Knowledge Management
Systems (SKMS) and Service Asset Confguration Management (SACM)
Provides technical and application guidance and support throughout the release process,
including known errors and workarounds
Provides feedback on the efectiveness of the release
Records metrics for deployment to ensure within agreed SLAs
Lesson -6
Illustration of Service Operation Processes
This image illustrates the processes and management of Service Operation, including problem,
event, and incident management. The rollover image describes these sections in the following list:
Incident Management
Incident Management Process Flow
Incident Prioritization Graphic
Urgency, Impact, and Priority
Diagnosis and Investigation
Incident Escalation
Incident Resolution, Recovery, and Closure
Incident Management Interfaces
Incident Management Key Performance Indicators
Incident Management Challenges
Event Management
Event Management Process
Event Management Interfaces
Request Fulfllment

Problem Management
Problem Management Concepts
Reactive vs. Proactive
Problem Management Process
Problem Management Interfaces
Workaround
Known Error Data Base (KEDB)
Service Operation Roles
Service Desk Manager
Service Desk Analyst
Incident Manager
Event Manager
Problem Manager
Incident Management includes the following topics:
Incident Management Process Flow
Incident Prioritization Graphic
Urgency, Impact, and Priority
Diagnosis and Investigation
Incident Escalation
Incident Resolution, Recovery, and Closure
Incident Management Interfaces
Incident Management Key Performance Indicators
Incident Management Challenges
An incident is:
Unplanned interruption to an IT service
Reduction in the quality of an IT service
Failure of a confguration item that has not yet impacted service
An example of the failure of a Confguration Item that might not have afected service immediately
would be the failure of one disk from a mirror set.
Incident Management
Incident Management is the process for dealing with all incidents. This process can include:
Failures
Questions
Queries
Incidents can be reported by users (usually through a telephone call to the Service Desk), by
technical staf, or event monitoring tools that automatically detect and send reports. The primary
goal of the Incident Management process is to restore normal service operation as quickly as
possible and minimize the adverse impact on business operations. Restoring normal service
operations ensures that the best possible levels of service quality and availability are maintained.
Normal service operation is defned here as service operation within Service Level Agreement
(SLA) limits.
Incident Management includes any event which disrupts, or which could disrupt, a service. Such
events are communicated directly by users, either through the Service Desk or through an
interface from Event Management to Incident Management tools.
Incidents can also be reported, logged, or both, by technical staf. If, for example, technical staf
notice something unusual with a hardware or network component, they can report or log an
incident and refer it to the Service Desk). This does not mean, however, that 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.
Although both incidents and Service Requests are reported to the Service Desk, they are not the
same. Service Requests do not represent a disruption to agreed-upon service. They provide a
way to meet the needs of the customers and can address an agreed-upon target in a Service
Level Agreement. Service Requests are dealt with by the Request Fulfllment process.
The value of Incident Management includes:
The ability to detect and resolve Incidents results in lower downtime to the business,
which in turn means higher availability of the service. The business therefore can exploit
the functionality of the service as designed.
The ability to align IT activity to real-time business priorities. This is because Incident
Management includes the capability to identify business priorities and dynamically
allocate resources as necessary.
The ability to identify potential improvements to services. This happens as a result of
understanding what constitutes an Incident and also from being in contact with the
activities of Business operational staf.
The Service Desk can, during their handling of incidents, identify additional service or
training requirements found in IT or the business.
Incident Management is highly visible to the business. It is therefore easier to demonstrate value
than for most areas in Service Operation. For this reason, Incident Management is often one of
the frst processes to be implemented in Service Management projects. An added beneft is that
Incident Management can be used to highlight other areas that need attention, thereby providing
a justifcation for expenditure on implementing other processes.
Important Incident Management terms include:
Time Scales
Incident Modules
Major Incidents
The role of Problem Management in incidents
Time scales must be agreed upon for all incident-handling stages. These will difer, depending
upon the priority level of the incident. Time scales will be captured as resolution targets within
Operational Level Agreements and Underpinning Contracts. All support groups should be made
fully aware of these time scales. Service management tools should be used to automate time
scales and escalate the incident as required based on predefned rules.
Many incidents are not new. They involve deal with something that has happened before and may
happen again. For this reason, many organizations fnd it helpful to predefne standard incident
models and apply them to appropriate incidents when they occur. An incident model is a way of
predefning the steps that should be taken to handle a process (in this case, a process for dealing
with a particular type of incident) in an agreed-upon way. Support tools can then be used to
manage the required process. This process will ensure that standard incidents are handled in a
predefned path and within predefned time scales.
A separate procedure, with shorter time scales and greater urgency, must be used for major
incidents. A defnition of what constitutes a major incident must be agreed upon and ideally
mapped to the overall incident prioritization system so that they will be dealt with through the
major incident process.
Note: People sometimes use loose terminology or confuse a Major Incident with a
Problem. In reality an incident remains an incident forever. It may grow in impact or
priority to become a Major Incident, but an incident never "becomes a Problem." A
Problem is the underlying cause of one or more incidents and always remains a
separate entity.
When necessary, the major incident procedure should include the dynamic establishment of a
separate major incident team under the direct leadership of the Incident Manager, formulated to
concentrate on this incident alone to ensure that adequate resources and focus are provided to
fnding a swift resolution. Sometimes the Service Desk Manager also fulflls the role of Incident
Manager (for example, in a small organization). To avoid confict of time or priorities, a separate
person may need to be designated to lead the Major Incident investigation team in such as case.
That person should ultimately report back to the Incident Manager.
If the cause of the incident needs to be investigated at the same time, then the Problem Manager
would be involved as well. However, the Incident Manager must ensure that service restoration
and underlying cause are kept separate. Throughout the investigation, the Service Desk would
ensure that all activities are recorded and users are kept fully informed of progress.
All incidents must be fully logged and stamped with date and time, regardless of their origin. They
might be raised through a Service Desk telephone call or automatically detected through an event
alert. A separate Incident Record must be logged for each additional incident handled. This
record ensures that an historical record is kept and credit is given for the work performed. All
relevant information relating to the nature of the incident must be logged so that a full historical
record is maintained. If the incident has to be referred to other support groups, those groups will
have all the relevant information to assist them.
The information needed for each incident is likely to include the following items:
Unique reference number
Incident categorization (often broken down into between two and four levels of
subcategories)
Incident urgency
Incident impact
Incident prioritization
Date and time recorded
Name and ID of the person or group recording the incident
Method of notifcation (telephone, automatic, e-mail, in person, and so on)
Name, department, phone, and location of user
Callback method (telephone, mail, and so on)
Description of symptoms
Incident status (active, waiting, closed, and so on)
Related Confguration Item
Support group or person to which the Incident is allocated
Related Problem or Known Error
Activities undertaken to resolve the incident
Resolution date and time
Closure category
Closure date and time
Part of the initial logging must allocate suitable incident categorization coding so that the exact
type of the call is recorded. This code will be important later when looking at incident types and
frequencies to establish trends for use in Problem Management, Supplier Management, and other
ITSM activities. Multilevel categorization is available in most tools, usually to three or four levels
deep. For example, an incident may be defned as one of the following categories:
Hardware
Server
Memory Board
Cell Card Failure
Software
Application
Every incident should have an appropriate prioritization code. This code will determine how the
incident is handled both by support tools and support staf.
Prioritization can normally be determined by taking into account both:
The urgency of the incident (how quickly the business needs a resolution)
The level of impact it is causing
An indication of impact is often, but not always, the number of users being afected. In some
cases, the loss of service to a single user can have a major business impact. It all depends upon
who is trying to do what. So numbers alone are not enough to evaluate overall priority.
Urgency, Impact, and Priority
Priority is the required sequence of Incident resolution.
Priority = Impact x Urgency
Impact is the extent to which an Incident leads to a departure from expected service
operations, such as the number of users or CIs afected.
Urgency is the required speed of resolving an incident.
iagnosis and &nvestigation
If the incident has been routed through the Service Desk, the Service Desk Operator must carry
out initial diagnosis, typically while the user is still on the telephone. If the call is raised in this way,
the operator tries to discover the full symptoms of the incident and to determine exactly what has
gone wrong and how to correct it. It is at this stage that diagnostic scripts and known error
information can be most valuable in allowing earlier and accurate diagnosis.
If possible, the Service Desk Operator will resolve the incident while the user is still on the
telephone and close the incident if the resolution is successful. If the Service Desk Operator
cannot resolve the incident while the user is still on the telephone, but there is a prospect that the
Service Desk may be able to do so within the agreed-upon time limit without assistance from
other support groups, they should inform the user of their intentions, give the user the incident
reference number, and attempt to fnd a resolution.
In the case of incidents where the user is just seeking information, the Service Desk should be
able to provide this fairly quickly and resolve the service request. However, a fault being reported
would qualify as an incident and likely to require some degree of investigation and diagnosis.
Each of the support groups involved with the incident handling will investigate and diagnose what
has gone wrong. All such activities (including details of any actions taken to try and resolve or re-
create the incident) should be fully documented in the incident record so that a complete historical
record of all activities is maintained at all times.
Valuable time can often be lost if investigative and diagnostic action (or indeed resolution or
recovery actions) are performed serially. Where possible, such activities should be performed in
parallel to reduce overall time scales, and support tools should be designed and selected to allow
this. However, care should be taken to coordinate activities, particularly resolution or recovery
activities. Otherwise, the actions of diferent groups might confict or further complicate a
resolution.
Incident Escalation
*unctional -scalation
As soon as it becomes clear that the Service Desk is unable to resolve the incident themselves
(or when target times for frst point resolution have been exceeded, whichever comes frst, the
incident must be immediately escalated for further support. If the organization has a second-level
support group and the Service Desk believes that the incident can be resolved by that group, the
Service Desk should refer the incident to them. If it is obvious that the incident will need deeper
technical knowledge, or when the second-level group has not been able to resolve the incident
within agreed-upon target times (whichever comes frst), the incident must be immediately
escalated to the appropriate third-level support group.
Note: Third-level support groups may be internal, but they may also be third parties
such as software suppliers or hardware manufacturers or maintainers.
The rules for escalation and handling of incidents must be agreed upon in Operational Level
Agreements (OLAs) and Underpinning Contracts (UCs) with internal and external support groups
respectively.
.ierarchic -scalation
If incidents are of a serious nature (for example, priority 1 incidents), the appropriate IT managers
must be notifed, for informational purposes at least. Hierarchic escalation is also used if the
Investigation and Diagnosis or Resolution and Recovery steps are taking too long or proving too
difcult. Hierarchic escalation should continue up the management chain so that senior managers
are aware, can be prepared, and take any necessary action, such as allocating additional
resources or involving suppliers or maintainers. Hierarchic escalation is also used when there is
contention about to whom the Incident is allocated. Hierarchic escalation can be initiated by the
afected users or customer management as they see ft. That is why it is important to make IT
managers aware so that they can anticipate and prepare for any such escalation.
The exact levels and time scales for both functional and hierarchic escalation need to be agreed
upon, taking into account Service Level Agreement targets, and embedded within support tools.
The tools can then be used to police and control the process fow within agreed-upon time scales.
Note: The Service Desk should keep the user informed of any relevant escalation
that takes place and ensure the incident record is updated accordingly to keep a full
history of actions.
Incident Resolution, Recovery, and Closure
When a potential resolution has been identifed it should be applied and tested. The specifc
actions to be undertaken and the people who will be involved in taking the recovery actions may
vary, depending upon the nature of the fault. Even when a resolution has been found, sufcient
testing must be performed to ensure that recovery action is complete and that the service has
been fully restored to the users.
In some cases it may be necessary for two or more groups to take separate, though perhaps
coordinated, recovery actions for an overall resolution to be implemented. In such cases Incident
Management must coordinate the activities and interact with all parties involved.
Regardless of the actions taken, or who does them, the incident record must be updated
accordingly with all relevant information and details so that a full history is maintained. The
resolving group should pass the incident back to the Service Desk for closure action. The Service
Desk should check that the incident is fully resolved and that the users are satisfed and willing to
agree that the incident can be closed.
Some organizations may chose to use an automatic closure period on specifc, or even all,
incidents (for example, the incident will be automatically closed after two working days if no
further contact is made by the user). When this approach is considered, it must frst be fully
discussed and agreed upon with the users. It also needs to be widely publicized so that all users
and IT staf are aware of the method. It may be inappropriate to use this method for certain types
of incidents, such as Major Incident or those involving VIPs. Despite all adequate care, there will
be occasions when incidents recur, even though they have been formally closed. Because of such
cases, it is wise to have predefned rules regarding if and when an incident can be re-opened. It
might make sense, for example, to agree that if the incident recurs within one working day then it
can be re-opened. However, beyond this point a new incident must be raised, but it should be
linked to the previous incidents.
Incident Management Interfaces
The following table lists the Incident Management Interfaces.
Incident Management Interface Description
Problem Management
Incident Management forms part of the overall
process of dealing with problems in the
organization. Incidents are often caused by
underlying problems, which must be solved to
prevent the incident from recurring. Incident
Management provides a point where incidents are
reported.
Confguration Management Provides the data used to identify and track the
progress of solving incidents. Uses of the
Confguration Management System (CMS) include
identifying faulty equipment, assessing the impact
of an incident, and identifying the users afected by
potential problems.
The CMS contains information about which
categories of incident should be assigned to which
support group. In turn, Incident Management can
maintain the status of faulty CIs. It can also assist
Confguration Management to audit the
infrastructure when working to resolve an incident.
Change Management
Where a change is required to implement a
workaround or resolution, the change needs to be
logged as a Request for Change (RFC) and sent
through Change Management. In turn, Incident
Management is able to detect and resolve incidents
that arise from failed changes.
Capacity Management
Incident Management provides a trigger for
performance monitoring where there appears to be
a performance problem. Capacity Management
may develop workarounds for incidents.
Availability Management
Availability Management will use Incident
Management data to determine the availability of IT
services and look at where the incident lifecycle
can be improved.
Service Level Management
(SLM)
The ability to resolve incidents in a specifed time is
a key part of delivering an agreed-upon level of
service. Incident Management enables SLM to
defne measurable responses to service
disruptions. It also provides reports that enable
SLM to review SLAs objectively and regularly. In
particular, Incident Management is able to assist in
defning where services are at their weakest, so
that SLM can defne actions as part of the Service
Improvement Program (SIP) (see the Continual
Service Improvement book for more details).
SLM defnes the acceptable levels of service within which Incident Management works, including:
Incident response times
Impact defnitions
Target fx times
Service defnitions, which are mapped to users
Rules for requesting services
Expectations for providing feedback to users
Copyright
Incident Management Key Performance Indicators
The metrics that should be monitored and reported upon to judge the efciency and efectiveness
of the Incident Management process, and its operation, will include:
Total numbers of Incidents (as a control measure)
Breakdown of incidents at each stage (for example logged: WIP, or closed)
Size of current incident backlog
Number and percentage of major incidents
Mean elapsed time to achieve Incident resolution or circumvention, broken down by
impact code
Percentage of incidents handled within agreed response time (Incident response-time
targets may be specifed in SLAs, for example, by impact and urgency codes)
Average cost per Incident
Number of incidents reopened and as a percentage of the total
Number and percentage of incidents incorrectly assigned
Number and percentage of incidents incorrectly categorized
Percentage of Incidents closed by the Service Desk without reference to other levels of
support (often referred to as frst point of contact)
Number and percentage of Incidents processed per Service Desk agent
Number and percentage of Incidents resolved remotely, without the need for a visit
Number of incidents handled by each Incident Model
Breakdown of incidents by time of day, to help pinpoint peaks and ensure matching of
resources
Reports should be produced under the authority of the Incident Manager, who should draw up a
schedule and distribution list, in collaboration with the Service Desk and support groups handling
incidents. Distribution lists should at least include IT services management and specialist support
groups. Consider also making the data available to users and customers, for example, through
SLA reports.
Incident Management challenges include the following factors:
The ability to detect incidents as early as possible. This will require education of the users
reporting and the confguration of Event Management tools.
Convincing all staf (technical teams as well as users) that all incidents must be logged.
Encouraging the use of self-help Web-based capabilities (which can speed up assistance
and reduce resource requirements).
Availability of information about Problems and Known Errors. This will enable Incident
Management staf to learn from previous incidents and also to track the status of
resolutions.
Integration into the Confguration Management System to determine relationships
between CI's, and to refer to the history of CI's when performing frst-line support.
Integration into the Service Level Management process. This will assist Incident
Management to correctly assess the impact and priority of incidents, and assists in
defning and executing escalation procedures. Service Level Management will also
beneft from the information learned during Incident Management, for example, in
determining whether Service Level performance targets are realistic and can be
achieved.
Lesson 2: Event Management
Event Management includes the following topics:
Event Management
Process Event
Management Interfaces
Request Fulfllment
2vent +#oncept,
Events are any detectable or discernable occurrence that has signifcance:
For the management of the IT infrastructure
For the delivery of an IT service and evaluation of the impact a deviation might cause to
the services
Typically, events trigger notifcations created by an IT Service, Confguration Item (CI), or
monitoring tool. Efective Service Operation depends on:
Knowing the status of the infrastructure
Detecting any deviation from normal or expected operation
Two types of monitoring and control systems tools for efective service operation are:
Active monitoring tools that poll key CIs to determine their status and availability. Any
exceptions will generate an alert that needs to be communicated to the appropriate tool or
team for action.
Passive monitoring tools that detect and correlate operational alerts or communications
generated by CIs.
2vent Manage$ent
An Event can be defned as any detectable or discernible occurrence that has signifcance for the
management of the IT infrastructure or the delivery of IT service and evaluation of the impact a
deviation might cause to the services. Events are typically notifcations created by an IT Service,
Confguration Item (CI), or monitoring tool.
Efective Service Operation is dependent on knowing the status of the infrastructure and detecting
any deviation from normal or expected operation. This is provided by good monitoring and control
systems, which are based on two types of tools:
Active monitoring tools that poll key CIs to determine their status and availability. Any
exceptions will generate an alert that needs to be communicated to the appropriate tool or
team for action.
Passive monitoring tools that detect and correlate operational alerts or communications
generated by CIs.
The ability to detect Events, make sense of them, and determine the appropriate control action is
provided by Event Management. Event Management is therefore the basis for Operational
Monitoring and Control. In addition, if these events are programmed to communicate operational
information as well as warnings and exceptions, they can be used as a basis for automating many
routine Operations Management activities. Some examples of Event Management include:
Executing scripts on remote devices
Submitting jobs for processing
Dynamically balancing the demand for a service across multiple devices to enhance
performance
Event Management provides the following functions:
The entry point for the execution of many Service Operation processes and activities
A method of comparing actual performance and behavior, against design standards and
Service Level Agreements
A basis for Service Assurance, Service Reporting, and Service Improvement
There are many diferent types of Events, for example:
Events that signify regular operation:
o Notifcation that a scheduled workload has completed.
o A user has logged in to use an application.
o An e-mail has reached its intended recipient.
Events that signify an exception:
o A user attempts to log on to an application with the incorrect password.
o An unusual situation has occurred in a business process that may indicate an
exception requiring further business investigation. For example, a Web page alert
indicates that a payment authorization site is unavailable, which afects fnancial
approval of business transactions.
o A CPU of a device is above the acceptable utilization rate.
o A PC scan reveals the installation of unauthorized software.
Events that signify unusual, but not exceptional, operation. These indicate that the
situation may require closer monitoring. In some cases the condition will resolve itself. An
example would be an unusual combination of workloads. As the workloads are
completed, normal operation is restored. In other cases, operator intervention may be
required if the situation is repeated or if it continues for too long. These rules or policies
are defned in the monitoring and control objectives for that device or service. Examples
of this type of event are:
The memory utilization of a server reaches within 5% of its highest acceptable
performance level.
The completion time of a transaction is 10% longer than normal.
Two things are signifcant about the previous examples:
No rule precisely defnes what constitutes normal operation, unusual operation, or an
exception. For example, a manufacturer may provide a benchmark of "75% memory
utilization is optimal for application X." However, it is discovered that under the specifc
conditions of the organization, response times begin to degrade above 70% utilization.
Each example relies on the sending and receipt of a message of some type. These are
generally referred to as Event Notifcations, and they do not happen on their own. The
next section will explore exactly how Events are defned, generated, and captured.
2vent Manage$ent &nterfaces
Event Management can be initiated by any type of occurrence. The key is to defne which of these
occurrences is signifcant and which need to be acted upon. Triggers include:
Exceptions to any level of CI performance defned in the Design specifcations,
Operational Level Agreements or Standard Operating Procedures
Exceptions to an automated procedure or process - e.g. a routine Change that has been
assigned to a build team has not been completed in time
An exception within a business process that is being monitored by Event Management
The completion of an automated task or job
A status change in a device or database record
Access of an application or database by a user or automated procedure or job
A situation where a device, database or application, etc. has reached a predefned
threshold of performance
Event Management can interface to any process that requires monitoring and control, especially
those that do not require real-time monitoring, but which do require some form of intervention
following an Event or group of Events.
The primary IT Service Management (ITSM) relationships are with Incident Management,
Problem Management, and Change Management.
Capacity Management and Availability Management are critical in defning which Events are
signifcant, what appropriate thresholds should be, and how to respond to them. In return, Event
Management will improve the performance and availability of services by responding to Events
when they occur and by reporting on actual Events and patterns of Events to determine (by
comparison to SLA targets and KPI's) if there is some aspect of the infrastructure design or
operation that can be improved.
Confguration Management is able to use Events to determine the current status of any CI in the
infrastructure. Comparing Events with the authorized baselines in the Confguration Management
System (CMS) will help to determine whether there is unauthorized activity taking place in the
organizations.
Asset Management (covered in more detail in the Service Design and Transition books) can use
Event Management to determine the lifecycle status of assets. For example, an Event could be
generated to signal that a new asset has been successfully confgured and is now operational.
Events can be a rich source of information that can be processed for inclusion in Knowledge
Management systems. For example, patterns of performance can be correlated with business
activity and used as input into future design and strategy decisions.
Event Management can play an important role in ensuring that potential impact on SLA's is
detected early and any failures are rectifed as soon as possible so that impact on service targets
are minimized.
3e4%est *%lfill$ent
The term service request is used as a generic description for varying types of demands that are
placed upon the IT department by the users. Many of these demands are actually small changes
that are low risk, frequently occurring, low cost and so forth (for example, a request to change a
password, a request to install an additional software application onto a particular workstation, a
request to relocate some items of desktop equipment) or maybe just a question requesting
information. Their scale and frequent, low risk nature means that they are better handled by a
separate process, rather than being allowed to congest and obstruct the normal incident and
change management processes.
Request fulfllment is the processes of dealing with service requests from the users. The
objectives of Request Fulfllment process include:
To provide a channel for users to request and receive standard services for which a
predefned approval and qualifcation process exists
To provide information to users and customers about the availability of services and the
procedure for obtaining them
To source and deliver the components of requested standard services (for example,
licenses and software media)
To assist with general information, complaints, or comments
The value of Request fulfllment is to provide quick and efective access to standard services
which business staf can use to improve their productivity or the quality of business services and
products.
Request fulfllment efectively reduces the bureaucracy involved in requesting and receiving
access to existing or new services, therefore also reducing the cost of providing these services.
Centralizing fulfllment also increases the level of control over these services. This in turn can
help reduce costs through centralized negotiation with suppliers and can also help to reduce the
cost of support.
PROBLEM MANAGEMENT LESSON 3
Problem Management includes the following topics:Problem Management Concepts
Reactive vs. Proactive
Problem Management Process
Problem Management Interfaces
Workaround
Known Error Data Base (KEDB)
ITIL defnes a Problem as the unknown cause of one or more incidents.
The primary objectives of problem management are to:
Prevent problems and resulting incidents from happening
Eliminate recurring incidents
Minimize the impact of incidents that cannot be prevented
Problem Management is the process responsible for managing the Lifecycle of all problems.
Problem Management prevents problems and resulting Incidents from happening, eliminates
recurring incidents, and minimizes the iImpact of Incidents that cannot be prevented.
Problem Management includes the activities required to diagnose the root cause of incidents and
to determine the resolution to those problems. It is also responsible for ensuring that the
resolution is implemented through the appropriate control procedures, especially Change
Management and Release Management.
Problem Management will also maintain information about problems and the appropriate
workarounds and resolutions so that the organization is able to reduce the number and impact of
Incidents over time. In this respect Problem Management has a strong interface with Knowledge
Management, and tools such as the Known Error Database will be used for both.
Although Incident and Problem Management are separate processes, they are closely related and
will typically use the same tools, and they may also use similar categorization, impact and priority
coding systems. This will ensure efective communication when dealing with related incidents and
problems.
Problem Management works together with Incident Management and Change Management to
ensure that IT service availability and quality is increased. When incidents are resolved,
information about the resolution is recorded. Over time, this information is used to speed up the
resolution time and identify permanent solutions, reducing the number of incidents and their
resolution time. This results in less downtime and less disruption to business critical systems
Kno-n 2rror ata 5ase
A Known Error is a Problem for which a cause has been identifed.
The purposes of a Known Error Data Base (KEDB) are to:
Store previous knowledge of incidents and problems
Record how incidents and problems were overcome
Diagnose and resolve recurring incidents or problems quicker
The known error record should hold precise details of the following items:
The fault and the symptoms that occurred
Any workaround or resolution action that can be taken to restore the service, or resolve
the problem, or both
As soon as the diagnosis is complete, a known error record must be raised and placed in the
Known Error Database. An immediate record is particularly important when a workaround has not
been found. Even a temporary workaround, one that is not yet a permanent resolution, has value
in restoring service. When a record exists, future similar incidents or problems can be identifed
and the service restored more quickly.
In some cases you might want to create a known error record even earlier in the overall process,
even if just for informational purposes, even though the diagnosis might not be complete or a
workaround implemented.
It is not advisable to try to set a specifc procedural point exactly when a known error record must
be raised. The point should be set as soon as it becomes useful to do so.
The incident count could be used to determine the frequency with which incidents are likely to
recur and therefore infuence priorities.
Pro(le$ Manage$ent and the Kno-n 2rror ata 5ase
As well as creating a Known Error Record in the Known Error Database to ensure quicker
diagnosis, the creation of a Problem Model for handling such problems in the future may be
helpful. This is very similar in concept to the idea of Incident Models, but applied to Problems as
well as Incidents.
The purpose of a Known Error Database is to allow storage of previous knowledge of incidents
and problems, and how they were overcome, in order to allow quicker diagnosis and resolution if
they recur.
The Known Error record should hold exact details of the fault and the symptoms that occurred,
together with precise details of any workaround or resolution action that can be taken to restore
the service and resolve the problem. An incident count will also be useful to determine the
frequency with which incidents are likely to reoccur and infuence priorities.
Care should be taken to avoid duplication of records, the same problem described in two or more
ways as separate records. To avoid this, the Problem Manager should be the only person able to
enter a new record. Other support groups should be allowed, indeed encouraged, to propose new
records, but these should be vetted by the Problem Manager before entry to the KEDB.
The KEDB should be used during the incident and problem diagnosis phases to try and speed up
the resolution process. New records should be added as quickly as possible when a new problem
has been identifed and diagnosed. All support staf should be fully trained and conversant with
the value that the KEDB can ofer and the way it should be used. They should be able to readily
retrieve and use data.
3eactive Vers%s Proactive Pro(le$ Manage$ent
Problem Management consists of two major processes:
Reactive Problem Management, which is generally executed as part of Service Operation
Proactive Problem Management, which is initiated in Service Operation, but generally
driven as part of Continual Service Improvement
The following image is a fow chart of the Problem Management Process.
This chart shows the Problem Management process fow. Though there can be variations
depending on the problems, most problems will be managed through a similar fow process.
Problem Management interfaces with the groups shown in the following table.
Problem Management Interface Description
Change Management
Problem Management ensures that all resolutions
or workarounds that require a change to a CI are
submitted through Change Management through
an RFC. Change Management will monitor the
progress of these changes and keep Problem
Management advised. Problem Management is
also involved in rectifying the situation caused by
failed changes.
Confguration Management Problem Management uses the CMS to identify
faulty CIs and also to determine the impact of
problems and resolutions. The CMS can also be
used to form the basis for the KEDB and hold or
integrate with the Problem Records.
Release and Deployment
Management
This is responsible for implementing problem fxes
out into the live environment. It also assists in
ensuring that the associated known errors are
transferred from the development Known Error
Database into the live Known Error Database.
Problem Management will assist in resolving
problems caused by faults during the release
process.
Availability Management
Availability Management is involved with
determining how to reduce downtime and increase
uptime. As such it has a close relationship with
Problem Management, especially the proactive
areas. Much of the management information
available in Problem Management will be
communicated to Availability Management.
Capacity Management
Some problems will require investigation by
Capacity Management teams and techniques,
such as performance issues. Capacity
Management will also assist in assessing proactive
measures. Problem Management provides
management information relative to the quality of
decisions made during the Capacity Planning
process.
IT Service Continuity
Problem Management acts as an entry point into
IT Service Continuity Management where a
signifcant Problem is not resolved before it starts
to have a major impact on the business.
Service Level Management The occurrence of incidents and problems afects
the level of service delivery measured by Service
Level Management. Problem Management
contributes to improvements in service levels, and
their management information is used as the basis
of some of the SLA review components. Service
Level Management also provides parameters
within which Problem Management works, such as
impact information and the efect on services of
proposed resolutions and proactive measures.
Financial Management
Financial Management assists in assessing the
impact of proposed resolutions or workarounds, as
well as pain value analysis. Problem Management
provides management information about the cost
of resolving and preventing problems, which is
used as input into the Budgeting and Accounting
systems, and Total Cost of Ownership calculations.
A workaround is a temporary way of overcoming a difculty. When a workaround is found, it is
important that:
The problem record remains open
Details of the workaround are documented within the problem record
In some cases it may be possible to fnd a workaround to the incidents caused by the problem.
Example of a workaround:
A manual amendment is made to an input fle to allow a program to complete the run successfully
and allow the billing process to complete satisfactorily. However, it is important that work on a
permanent resolution continues where this is justifed. In this example, the reason why the fle
became corrupted in the frst place must be found and corrected to prevent this situation from
happening again.
Service Operation Roles includes the following topics:
Service Desk Manager
Service Desk Analyst
Incident Manager
Event Manager
Problem Manager
Service es. Manager
In larger organizations where the Service Desk is of a signifcant size, a Service Desk Manager
role may be justifed. Service Desk Supervisors report to the Service Desk Manager. In such
cases, this role might take responsibility for some of the activities listed and could additionally
perform the following activities:
Manage the overall desk activities, including the supervisors
Act as a further escalation point for the supervisors
Take on a wider customer services role
Report to senior managers on any issue that could signifcantly impact the business
Attend Change Advisory Board meetings
Overall responsibility for Incident and Service Request handling on the Service Desk. This could
also be expanded to any other activity taken on by the Service Desk, such as monitoring certain
classes of event.
The primary Service Desk analyst role is that of providing frst-level support through taking calls
and handling the resulting incidents or service requests using the incident and request fulfllment
processes.
The Incident Manager has the following responsibilities:
Driving the efciency and efectiveness of the Incident Management process
Producing management information
Managing the work of incident support staf (frst line and second line)
Monitoring the efectiveness of Incident Management and making recommendations for
improvement
Developing and maintaining the Incident Management systems
Managing major incidents
Developing and maintaining the Incident Management process and procedures
In many organizations the role of Incident Manager is assigned to the Service Desk supervisor. In
larger organizations with high volumes, a separate role may be necessary. In either case, it is
important to give the Incident Manager the authority to manage incidents efectively through the
frst, second, and third lines.
Problem Manager
A designated person (or in larger organizations, a team) should be responsible for Problem
Management. Smaller organizations may not be able to justify a full-time employee for this role. It
can be combined with other roles in such cases. However, the role of Problem Management must
not be left only to technical staf. A single point of coordination and an owner of the Problem
Management process is essential. This role will coordinate all problem management activities and
will have specifc responsibility for the following duties:
Works with all problem resolution groups to ensure swift resolution of problems within
SLA targets
Owns the Known Error Database. Acts as the gatekeeper for the inclusion of all Known
Errors and management of search algorithms.
Formally closes all problem records.
Works with suppliers and contractors to ensure that third parties fulfl their contractual
obligations to resolve problems
Manages and documents all follow-up activities relating to Major Problem Reviews.
LESSON -7
Service Desk
A Service Desk is a functional unit made up of a dedicated number of staf responsible for dealing
with a variety of service events, often made through telephone calls, Web interface, or
automatically reported infrastructure events. The Service Desk is a vitally important part of the IT
Department of an organization. The Service Desk should be the single point of contact for IT
users on a day-to-day basis. The Service Desk will handle all incidents and service requests,
usually using specialist software tools to log and manage all such events.
A good Service Desk can often compensate for defciencies elsewhere in the IT organization.
However, a poor Service Desk, or the lack of one, can give a poor impression of an IT
organization that might otherwise be efcient and efective.
Providing the correct caliber of staf for the Service Desk is important. To improve staf retention,
IT managers should do their best to make the desk an attractive place to work.
Service Desk Responsibilities
The primary aim of the Service Desk is to restore normal service to the users as quickly as
possible. In this context, "restore normal service" is meant in the widest possible sense. For
example, restoration could involve fxing a technical fault, fulflling a service request, or answering
a query. The phrase means to do anything that is needed to allow the users to satisfactorily return
to work.
Specifc responsibilities will include:
Logging all relevant incident and service request details, allocating categorization and
prioritization codes
Providing frst-line investigation and diagnosis
Resolving all the incidents and service requests that they can
Escalating incidents and service requests that they cannot resolve within the agreed-
upon time scales
Keeping users informed of progress
Closing all resolved incidents, requests, and other calls
Conducting customer and user satisfaction callbacks and surveys as agreed upon
Communicating with users, keeping them informed of incident progress, and notifying
them of impending changes or agreed-upon outages
The main function of the Service Desk is to restore the normal service to the users as quickly as
possible. Restoring to normal service could include repairing a technical fault, or fulflling a
service request, or answering a query. It involves whatever is needed to allow the users to return
to an agreed upon level of work.
Local Service Des/
A Local Service Desk is where a desk is collocated within, or physically close to the user
community it serves. Physical proximity often aids communication and gives a clearly visible
presence, which some users like. However, Local Service Desks can often be inefcient and
expensive. Staf wait to deal with incidents, and the volume and arrival rate of calls may not justify
the staf dedicated to this function.
Centralize! Service Des/
It is possible to reduce the number of Local Service Desks by merging them into a single location,
or into a smaller number of locations, by drawing the staf into one or more centralized Service
Desk structures. This practice can be more efcient and cost efective for the following reasons:
Fewer overall staf members deal with a higher volume of calls.
Staf can develop higher skill levels. More frequent occurrence of events provides greater
familiarization with their resolution.
However, it might still be necessary to maintain some form of local presence to handle physical
support requirements, but such staf can be managed and deployed from the central desk.
0irtual Service Des/
It is possible to give the impression of a single, centralized Service Desk when in fact the
personnel might be located in a number of geographical or structural locations. Technology,
particularly the Internet, and corporate support tools can help build this illusion. These
technologies and tools permit the following practices to meet user demand:
Telecommuting from home
Secondary support group
Of-shoring
Outsourcing
Any combination of the previous items.
Safeguards are needed in all of these circumstances to ensure consistency and uniformity in
service quality and cultural terms.
*ollo(1the1Sun Service
Some global or international organizations may wish to combine two or more of their
geographically dispersed service desks to provide a 24-hour follow-the-sun service. For example,
a Service Desk in the Asia-Pacifc region could handle calls during standard ofce hours. At the
end of this period, they could transfer responsibility for any open incidents to a European-based
desk. That desk handles these calls and their own incidents during the European business day.
Then the European desk transfers its open incidents to a U.S.-based desk, which in turn transfers
responsibility back to the Asia-Pacifc desk to complete the cycle.
Types of Service Desks
This image illustrates types of Service Desks and covers Local, Centralized, and Virtual
applications of the Service Desk. It also includes a description of the Local and Remote Users.
The rollover image describes these sections in the following list:
Local Service Desk: Service desk is co-located within or physically close to the user community
it serves. This often aids communication and gives a clearly visible presence, which some users
like, but can often be inefcient and expensive to resource as staf are tied up waiting to deal with
incidents when the volume and arrival rate of calls may not justify this.
Centralized Service Desk: Service desks are merged into a single location (or into a smaller
number of locations) by drawing the staf into one or more centralized Service Desk structures.
This can be more efcient and cost-efective, allowing fewer overall staf to deal with a higher
volume of calls, and can also lead to higher skill levels through great familiarization through more
frequent occurrence of events.
Virtual Service Desk: Through the use of technology, particularly the Internet, and the use of
corporate support tools, it is possible to give the impression of a single, centralized Service Desk
when in fact the personnel may be spread or located in any number or type of geographical or
structural locations.
Local User: A user who is at the same physical location as the Service Desk.
Remote User: This user and the Service Desk are at physically separate locations.
Service Desk Stafng
An organization must ensure that the correct numbers of staf are available at any given time to
match business demand. Call rates can be volatile. Often in the same day the arrival rate may go
from very high to very low and back again. An organization must decide on the level and range of
skills it requires of service desk staf, and then ensure that these skills are available at the
appropriate times. A range of skill options are possible, from a call-logging service where staf
need only basic technical skills, through to a technical service desk including the organization's
most technically skilled staf.
All Service Desk staf should be adequately trained before they take calls. IT managers need to
recognize the importance of the Service Desk and its staf and give the Service Desk special
attention. Because any signifcant loss of staf can be disruptive and lead to inconsistent service,
eforts should be made to make the Service Desk an attractive place to work.
Many organizations fnd it useful to appoint or designate a number of Super Users throughout the
user community, to act as liaison points with IT in general and the Service Desk in particular.
Super Users can be given some additional training and awareness and used as a conduit for
communications fow in both directions. They can flter requests and issues raised by the user
community, in some cases even going as far as to raise incidents or requests themselves. This
practice can help prevent incident storms, which is when a key service or component fails and
afects many users. Super Users can also transmit information from the Service Desk outward
quickly.
Service Desk Metrics
Metrics should be established so that the performance of the Service Desk can be evaluated at
regular intervals. Regular evaluation is important to assess the health, maturity, efciency, and
efectiveness of Service Desk operations and to be aware of opportunities to improve Service
Desk operations.
Detailed metrics are needed and must be examined over a period of time. These will include the
call-handling statistics previously mentioned in telephony, as well as the following metrics:
The frst-line resolution rate: the percentage of calls resolved at frst line, without the need
for escalation to other support groups
Average time to resolve an incident (when resolved at frst line)
Average time to escalate an incident (where frst-line resolution is not possible)
Average Service Desk cost of handling an incident
Percentage of customer or user updates conducted within target times, as defned in SLA
targets
Average time to review and close a resolved call
The number of calls broken down by time of day and day of week, combined with average
call time, is a critical in determining the number of staf required
Technical Management performs a dual role:
It is the custodian of technical knowledge and expertise related to managing the IT
Infrastructure. In this role, Technical Management ensures that the knowledge required to
design, test, manage, and improve IT services is identifed, developed, and refned.
It provides the actual resources to support the IT Service Management Lifecycle. In this
role, Technical Management ensures that resources are efectively trained and deployed
to design, build, change, operate, and improve the technology required to deliver and
support IT services.
By performing these two roles, Technical Management is able to ensure that the organization has
access to the right type and level of human resources to manage technology and is therefore able
to meet business objectives. Part of this role is also to ensure a balance between the skill level,
utilization, and the cost of these resources. An additional but important role played by Technical
Management is to provide guidance to IT Operations regarding how best to maintain the ongoing
operational management of technology.
The objectives of Technical Management are to help plan, implement, and maintain a stable
technical infrastructure to support the business processes of the organization through:
Well-designed, highly resilient, cost-efective technical topology
Adequate technical skills to maintain the technical infrastructure in optimum condition
The swift use of technical skills to quickly diagnose and resolve any technical failures that
do occur
Application Management is to applications, what Technical Management is to the IT
Infrastructure. Application Management plays a role in all applications, whether purchased or
developed in-house. One of the key decisions to which they contribute is the decision of whether
to buy an application or build it. After that decision is made, Application Management performs a
dual role.
The frst role, Application Management, is the custodian of technical knowledge and
expertise related to managing applications. In this role Application Management, working
together with Technical Management, ensures that the knowledge required to design,
test, manage, and improve IT services is identifed, developed, and refned.
The second role, Application Management, provides the actual resources to support the
IT Service Management Lifecycle. In this role Application Management ensures that
resources are efectively trained and deployed to design, build, transition, operate, and
improve the technology required to deliver and support IT services.
By performing these two roles, Application Management is able to ensure that the organization
has access to the right type and level of human resources to manage applications and is
therefore able to meet business objectives. This function starts in Service Strategy, expands in
Service Design, is tested in Service Transition, and is refned in Continual Service Improvement.
The objectives of Application Management are to support the business processes of the
organization by helping to identify functional and manageability requirements for application
software. The next objectives are to assist in the design and deployment of those applications and
the ongoing support and improvement of those applications.
These objectives are achieved through the following items:
Applications that are well-designed, resilient, and cost-efective
The assurance that the necessary functionality is available to achieve the required
business outcome
The organization of adequate technical skills to maintain operational applications in
optimum condition
Swift use of technical skills to quickly diagnose and resolve any technical failures that do
occur
&T "perations #ontrol and *acilities Manage$ent 3ole
The role of Operations Management is to implement the ongoing activities and procedures
required to manage and maintain the IT infrastructure in order to deliver and support IT services
at the agreed-upon levels. These activities include:
Operations Control, which oversees implementing and monitoring of IT infrastructure
operational activities and events. An Operations Bridge or Network Operations Center
can assist with this activity.
Console Management, which refers to defning central observation and monitoring
capability and then using those consoles to monitor and control activities.
Facilities Management, which refers to the management of the physical IT environment,
typically a data center or computer rooms and recovery sites together with all the power
and cooling equipment. Facilities Management also includes the coordination of large-
scale consolidation projects, for example, data center consolidation or server
consolidation projects.
IT Operations Management is responsible primarily for maintaining existing stability. The
stability of the IT infrastructure and consistency of IT services is a primary concern of IT
Operations. IT Operations Management must be able to continually adapt to and keep
pace with business requirements and demand. IT Operations Management can challenge
current methods and ways of thinking.
&T "perations #ontrol and *acilities Manage$ent "()ectives
The objectives of IT Operations Management include:
Daily maintenance to sustain stability of the day-to-day processes and activities of the
organization
Regular scrutiny and improvements to achieve improved service at reduced costs, while
maintaining stability
Swift application of operational skills to diagnose and resolve any IT operations failures
that occur