TYBSCIT-SEMESTER-6-CBCS-IT-Service-Management-munotes

Page 1

1 1
IT SER VICE MANAGEMENT, SERVICE
STRATE GY PRINCIPLES
Unit Structure:
1.1 IT Service Management
1.1.1 Introduction
1.1.2 What is service management?
1.1.3 What are services?
1.1.4 Business Process
1.1.5 Principles of Service management:
1.1.5.1 Specia lisation and Coordination
1.1.5.2 The agency principle
1.1.5.3 Encapsulation
1.1.5.4 Principles of systems
1.1.5.5 The service Life Cycle
1.1.5.6 Functions and processes across the life cycle
1.2 Service Strategy Principles:
1.2.1 Value creation
1.2.2 Service Assets
1.2.3 Service Provider
1.2.4 Service Structures
1.2.5 4p’s of strategy
1.3 Summary
1.4 Question s
1.5 References


munotes.in

Page 2

IT Service
Management
2 1.1 IT SERVICE MANAGEMENT
1.1. 1 Introduction:
The collection of tasks known as "IT Service Management" (ITSM) can
be us ed to manage the services provided to end users. A set of best
practices and strategies for selecting, planning, delivering, and
maintaining IT services within a company are provided by ITIL service
management, which is based on the ITIL framework of best practices.
These strategies help the IT department's activities and costs to be in line
with changing business demands.
1.1.2 What is service management?
Service management is a collection of unique executive skills for
providing clients with a benefit i n the form of a service. With specialties in
strategy, design, transition, operation, and continuous improvement, the
capabilities appear as functions and processes for managing services over
a lifecycle.
The tasks an organization performs to plan, develop , deliver, operate, and
regulate the information technology (IT) services given to consumers are
referred to as information technology service management (ITSM).
IT service management is characterised from more technologically
oriented approaches to IT man agement, such as network management and
IT systems management, by adopting a process approach to management,
concentrating on customer needs and IT services for customers rather than
IT systems, and emphasizing continuous improvement.
Four perspectives (4P s) or attributes can be used to illustrate the ITSM
concept:
1. People
2. Products
3. Partners
4. Processes

Figure 1.1 : Four perspectives for ITSM Concepts munotes.in

Page 3

It Service Management,
Service Strate gy Principles
3 1. People Perspective: Role and responsibility definitions for all parties
involved, including employees, clients , and other stakeholders.
Concerned about the "soft" side, including employees, clients, and
other stakeholders
2. Process Perspective: An explanation of the procedures needed to
provide and support various client services. Relates the process flows -
based end -to-end service delivery.
3. Product/Technology perspective: The main goal is to offer and
support the goods or technologies that the business needs in order to
achieve important organisational objectives or goals. Analyzes tools,
technology, software, financ es, and business services.
4. Partners/Suppliers Perspective: The administration of outside
vendors (Partners) participating in the delivery and support of the IT -
delivered and -supported technology and goods. Reflects the value of
connections with partners a nd outside suppliers and how they affect
the delivery of services.
Benefits of ITSM :
1. IT aligned with the business: Achieved by increasing service delivery
to business as well as communication between IT and business.
2. To adopt consistent delivery: It ensur es that procedures can be
followed consistently across the organisation.
3. Better quality and efficiency: It’s measuring and control capabilities
enable the identification of areas for cost and quality improvement.
4. Reduced cost of failure: IT events and down time cost money, both in
terms of lost productivity for system users and possible loss of revenue
if services are unavailable and clients may decide to do business
somewhere else.
5. Reduced risk to the business: With IT at the forefront of most
businesses no wadays, any potential risk areas should be reduced to a
minimum.
6. Better management and accountability: Greater visibility leads to
better control and a more accountable service.
7. Better communication: ITSM calls for collaboration and
communication beyond co nventional management boundaries and
divisions.
1.1.3 What are services?
Service is defined as a way of delivering value to customers by helping
customers achieve results without owning specific costs and risks.
Customers want results but do not want to b e responsible or to be
responsible for all associated costs and risks. munotes.in

Page 4

IT Service
Management
4 1.1.4 Business Process:
Business procedures that are constrained by objectives, rules, and laws
provide the desired results. The procedures support resources, information,
applications , and infrastructure. To guarantee appropriate performance and
the desired results, workflow combines the performance of activities and
controls flows between resources and measurements. From the perspective
of service management, business procedures are e specially essential. They
use the organization's collective knowledge and experience to accomplish
the particular goal described here.

Figure 1.2 : Business Process Workflow
1.1.5 Principles of Service management:
1.1.5.1 Specialisa tion and Coordination:
In service management, the goal is to make customer capabilities and
resources available in highly usable form of services at acceptable levels
of quality, cost, and risk. Customer control and ownership of specific
resources are redu ced by service providers. As a result, customers are free
to focus on their core competencies.
The customers are experts in business administration and use a set of
resources (Pool A) to produce one set of results. Similarly, the pool B
service providers s pecialize in service management. The service
management division coordinates insurance and use between the two
parties. A customer is satisfied with the use of certain resources (Pool B)
unless ownership is required.
With specialization, capabilities and r esources are grouped together to
achieve focus, expertise, and excellence. Due to accountability, authority,
and management attention, coordination of capabilities and resources is
easier. Combined capabilities and resources that depend on each other and
interact reduce the need for coordination. Where coordination is easy
through well -defined interfaces, protocols and agreements, they are
controlled by the group that is most able to manage them. munotes.in

Page 5

It Service Management,
Service Strate gy Principles
5 1.1.5. 2. The agency principle:
Leaders employ agents to pursu e specific goals on their behalf. Agents act
on behalf of the leader and can be staff, consultants, or service providers.
Customers are the leaders who have agents working for them, which can
be service providers or users of those services. The agency mode l is used
in client/server models and software design. Software agents interact with
users for their backend functions, processes and systems.

Figure 1.3 : The agency model in service management
1.1.5. 3. Encapsulation:
Customers are worri ed about getting access to the asset utility at a
reasonable price. They don't deal with intricate technical intricacies,
complicated structures, or low -level activities. Instead of complicated
resource setups like those for applications, data, infrastruct ure, and
equipment, they prefer simple and secure interfaces. Encapsulation hides
what the consumer isn't interested in and clarifies what they will find
useful and beneficial in the service. Customers just care about the use.
Three distinct but related id eas govern encapsulation: problem separation,
modularity, and loose connection.
A. Separation of concerns: Complex challenges or problems can be
handled or broken down into smaller ones. Each issue is handled by
specialised resources and capabilities, which i mproves outcomes
overall. This improves focus and makes it possible to enhance systems
and processes on a reasonable scale. With the right information,
abilities, and experience, challenges and opportunities are suitable.
B. Modularity: System complexity can be managed by the structural
principle of modularity. Functionally related elements are grouped to
create self -sufficient and workable modules. Interfaces to other
systems or modules provide access to the functionality. By lowering
duplication, complexity, administrative expenditures, and change
expenses, modularity promotes efficiency and economy. Similar munotes.in

Page 6

IT Service
Management
6 effects are produced via module reuse. At various granularities,
encapsulation is feasible for everything from software and hardware
parts to organisatio nal structure and business processes.
C. Loose connection: The loose coupling of resources with users is
made possible by the separation of concerns and modularity. Loss
coupling makes it simpler to modify the resource internally without
affecting usage. Addi tionally, it prevents imposing modifications that
can come at an unforeseen expense to the consumer. Additionally,
lose coupling enables dynamic resource allocation across many uses.
1.1.5. 4. Principles of systems:
A system is composed of interrelated part s that cooperate to achieve a
common goal.
i) Open -loop And Closed -loop Control Processes:
The action of the control system is unaffected by the output in an open
loop control system; this type of system is also known as a time -dependent
system. It receiv es no feedback. It is incredibly easy to use, requires little
maintenance, runs quickly, and is economical. This system has poor
accuracy and is less trustworthy.
The output of the system that depends on the system's input is known as a
closed -loop control system. One or more feedback loops exist between the
input & output of this control system. This system analyses its input and
produces the desired output. This type of system generates the error signal,
which is the primary discrepancy between the system 's output and input.
ii) Feedback and Learning:
Growing and learning are essential parts of how great organisations
operate. Feedback, which is an input in a cycle based on performance or
results in the preceding cycle, is what causes learning. Positive o r self -
sustaining feedback can lead to exponential development or decline,
depending on the situation. Balance or balance could be the result of
something negative or self -correcting. A common control pattern that can
be established by self -correcting feed back is goal -seeking behaviour.
For each sort of feedback loop, there are multiple examples in
organisations, processes, and functions. When a process operates as a
dynamic system, the interaction of the feedback loops governs the
behaviour of the process.
1.1.5. 5. The service Life Cycle:
The official definition of a Service is “a means of delivering value to
Customers by facilitating outcomes customers want to achieve without the
ownership of specific costs or risks”.
Lifecycle: a creature or inanimate obj ect's development through a series of
natural phases. For instance, there are phases for humans at birth, baby, munotes.in

Page 7

It Service Management,
Service Strate gy Principles
7 toddler, child, pre -teen, adolescent, young adult, adult, old adult, and
death.

Figure 1.4 : The Service Lifecycle
ITIL® Framework provided bes t practices for ITSM based around the
how questions. These included:
• How should we design for availability, capacity and continuity of
services?
• How can we respond to and manage incidents, problems and known
errors?
• As Version 3 now maintains a holistic vi ew covering the entire
lifecycle of a service, no longer does
• ITIL® just answer the how questions, but also why?
• Why does a customer need this service?
• Why should the customer purchase services from us?
• Why should we provide (x) levels of availability, cap acity and
continuity?
By first asking these questions it enables a service provider to provide
overall strategic objectives for the IT organization, which will then be
used to direct how services are designed, transitioned, supported and
improved in order to deliver optimum value to customers and
stakeholders.
munotes.in

Page 8

IT Service
Management
8 1.1.5. 6 Functions and processes across the life cycle:
i) Processes -
A systematic collection of related actions that work together to produce
outcomes and add value for customers or stakeholders is referred to as a
process. Through the actions taken, a process changes one or more inputs
into certain outputs. There are some principles:
● Each and every procedure need to be quantifiable and performance -
based (not just time but overall cost, effort and o ther resources).
● Processes are strategic assets for distinguishing the market and gaining
competitive advantages.
● The definition of roles, responsibilities, tools, management controls,
rules, standards, guidelines, activities, and job instructions may all be
done through processes, if necessary.
A process owner is accountable for the outcomes and for making sure the
process serves the intended purpose. The operational management of a
process is the responsibility of a process manager. One process may have
numerous managers, or (usually in smaller organisations) the process
owner and manager may be the same individual.
When defining and creating processes, it's critical to consider both the
physical and behavioural elements. This can be accomplished by making
sure that all necessary stakeholders (such as staff, clients, and users, etc.)
are sufficiently involved in process design so that:
● They can express their own thoughts, worries, and opinions that may
affect the design, implementation, and improvement of processes.
Present -day, previously unidentified behaviours that might influence
the process' design and execution may be of special significance.
● Stakeholder groups are given adequate training and instruction on how
to carry out their roles in the process and the worth of the process.
● Stakeholders are often more likely to respond favourably than to
actively or quietly oppose organisational changes because they feel
empowered by the change that is being generated.
ii) Functions -
Functions are groupings of r oles and automated actions that perform a
process, activity or combination. Service operations must manage the IT
operating environment in "steady state." There are different roles and
responsibilities for service design, delivery, and management.
iii) Connecting Processes and Functions -
People often claim that processes are perfect. Until you involve people. A
lack of clarity about roles and responsibilities can lead to processes being munotes.in

Page 9

It Service Management,
Service Strate gy Principles
9 dropped due to misunderstandings and a lack of clarity.The RACI model
is useful for defining roles and responsibilities for process design.
● R – Responsibility. The person who performs the work.
● A – Accountability. The person responsible for making the work or
decision.
● C – Consult. Those who must be consulted prior to a de cision being
made and/or the task being completed.
● I – Inform. Anyone who requires to be notified when a decision is
made or work is finished.
Service
Desk Desktop Applications Operations
Manager
Logging RACI - - CI
Classification RACI RCI - CI
Investi gation RACI RCI RCI CI
Table 1.1 : RACI model
A RACI Model is used to define the roles and responsibilities of various
Functions in relation to the activities of Incident Management.
General Rules that exist:
● Only 1 “A” per Row can be defined (ensures acco untability, more than
one “A” would confuse this).
● At least 1 “R” per Row must be (shows that actions are taking place),
with more than one being appropriate where there is shared
responsibility.
1.2 SERVICE STRATEGY PRINCIPLES
The first phase in the ITIL lifecycle is to determine the service's value.
The following principles should be kept in mind by anyone wishing to
define a service.
1.2.1 Value creation:
Any business entity's primary objective is the creation of value. Creating
value for customers ensu res that future investment capital is available by
increasing stock prices, whereas selling products and services relies on
creating value for customers. The excess of revenue over expenditure (or
capital cost) is said to create value from a financial pers pective. Analysts
have a broad definition of "value creation" that goes beyond traditional
financial measures. Today's companies rely on intangible drivers such as
innovation, people, ideas, and brands. munotes.in

Page 10

IT Service
Management
10 From the customer’s point of view the value of a serv ice consists of two
basic elements:
1. Utility is the functionality of a service that meets a specific
requirement or eliminates business constraints. It increases company
performance.
2. Warranty , the commitment or guarantee that a product or service
complies w ith agreed requirements for availability, capacity,
continuity, and safety, reduces service delivery fluctuations.
1.2.2 Service Assets:
Resources and skills are service providers' strategic assets. Resources are
direct delivery inputs, while management, o rganization, and people are
necessary to convert them. Skills are expertise and knowledge -intensive,
linked to people, systems, processes and technologies, and need to be
improved over time. Capabilities, resources, and skills are essential for
generating value. The productive capacity of a service provider depends
on their available resources.
1.2.3 Service Provider:
Service providers are IT companies that provide products and solutions
through on -demand services, pay per use, or a hybrid model of delivery .
There are three types of service providers:
1. Internal Service Provider
2. Shared Services Unit
3. External Service Provider
1. Internal Service Provider (TYPE I ):
Organizations frequently have business units or verticals, to use a common
term. Almost every busi ness unit functions as a separate organisation (an
organisation within an organization).

Figure 1.5 : Type I providers
If you integrate IT teams (IT service providers) into each of these business
divisions, you will have a n equal number of IT teams. Internal service munotes.in

Page 11

It Service Management,
Service Strate gy Principles
11 providers are the groups that work with the business unit's clients to
deliver IT services.
This model costs a fair amount of money and is not optimal. Under each
business unit, a number of roles and t asks will need to be duplicated
2. Shared Services Unit (TYPE II ):
Let's imagine that you create a centralised IT team by gathering all the IT
teams from the previous model into one large group. Additionally, all
business divisions alike will receive IT support fro m this single IT staff.

Figure 1.6: Common Type II providers
The most popular and optimal model is this one. The sole disadvantage is
that, in contrast to the internal service provider model, business units
might not receive pr eferential treatment.
3. External Service Provider (TYPE III ):
The benefit of using an external service provider is that the business does
not have to worry about capital expenditures like the acquisition and
upkeep of the equipment utilised by the service providers. There is a set
amount that must be paid to the service provider, and since it is the service
provider's responsibility to handle that, the company need not worry about
paying individual salaries or over time. munotes.in

Page 12

IT Service
Management
12

Figure 1.7: Type III providers
Utilizing outside service providers gives businesses additional flexibility.
It is not feasible financially for a small business unit to purchase pricey IT
equipment that would only be used for a few tasks. However, outsourcing
IT services is more cost -effective because it enables businesses to take
advantage of the best equipment's advantages without having to pay for its
ownership.
1.2.4 Service Structures:
The best organisational practises outlined in ITIL must be customised to
fit particular organisatio ns and circumstances because there is no one
optimal way to do things. Resource limitations, as well as the size,
character, and needs of the company and its clients, must be taken into
consideration before making any modifications. Strategy serves as the
foundation for organisational design, providing direction and establishing
the standards for each stage of the design process. The roles and
responsibilities necessary to carry out the processes and activities must be
clearly defined by the organisation fo r the plan to be successful.
Age, size, geographic reach, and technological adoption all have an impact
on an organization's structure. Roles and relationships must alter as the
company develops and evolves; otherwise, issues may occur. This is
crucial for businesses adopting a service orientation since efficiency and
discipline -related pressures always result in increased formalisation and
complexity. Multiple jobs may be merged under one individual in a small
organisation. Each of these tasks may be fille d by a number of individuals
in larger organisations, divided according to geography, technology, or
other factors. munotes.in

Page 13

It Service Management,
Service Strate gy Principles
13 The differences between small and large IT organization can be seen in the
table below:
Small IT Organization Large IT Organization
Roles a re combined Roles are separate
Segregation of duties limited Segregation of duties maximized
Generalization of skills Specialization of skills
Less complexity More complexity

1.2.5 4p’s of strategy:
The four "Ps" of perspective, position, plan, and pa ttern—each of which
represents a distinct way to approach your service strategy —are
extensively covered by ITIL. These terms should not be confused with the
four "Ps" of ITIL Service Design.

Figure 1.8: Perspectives, positions, plans and pa tterns
1. Perspective: - It describes the vision and the direction of the
organization. It understands how thge business of the organization is,
how it interacts with the customer, and how its services will be
provided.
2. Position : - The position refers to the attributes and capabilities that the
service provider has that sets them apart from their competitors ( other
service providers). Positions could be based on value or low cost,
specialized services or providing an inclusive range of services,
knowledge of a customers environment or industry variables.
3. Plan: - It gives a blueprint of how service providers will transition
from their current situation to desired situation. Plan describes all the
needed steps the service provider will have to take to achieve the ir
perspective.
4. Pattern: - It describes the repeatable actions that service provider will
have to perform inorde r to meet its strategic objecti ves. munotes.in

Page 14

IT Service
Management
14 1.3 SUMMARY
In this chapter we have covered concept of IT Service Management, What
is service management? Wh at are services? Business Process, Principles
of Service management and types of it. The service Life Cycle with
functions and processes across the life cycle.Service Strategy Principles.
1.4 QUESTIONS
1. Explain ITSM. Describe the four ITSM perspectives.
2. Describe ITSM. Justify the advantages of ITSM.
3. By ITSM, what do you mean? What are the problems with ITSM?
4. A brief note on ITIL, services, and business processes is required.
5. Describe the foundations of service management.
6. Describe the service management noti on of encapsulation briefly.
7. Elaborate ITSM service life cycle.
8. What are Processes across the ITSM life cycle?
9. What are Functions across the ITSM life cycle?
10. How are the functions and processes in the ITSM life cycle related?
11. Write short note on Value Crea tion.
12. Write short note on Service Assets.
13. Who is Service Provider? What are its types?
14. Write short note on Service Structure.
15. Explain four P’s of Service Strategy.
1.5 REFERENCE FOR FURTHER READING
1. ITIL Foundation: ITIL 4 Edition (Itil 4 Foundation) by Axe los
2. ITIL v3 Foundation Complete Certification Kit.
3. ITIL v3 Service Strategy OGC/TSO
Web references :-
1. https://www.tutorialspoint.com/itil/service_strategy_overview.htm
2. https://www.simplilearn.com/tutorials/itil -tutorial/what -is-it-service -
management

munotes.in

Page 15

15
2
SERVICE STRATE GY, CHALLENGES,
CRITICAL SUCCESS FACTORS AND RISK
Unit Structure:
2.1 Service Strategy
2.1.1 Define the market
2.1.2 Develop the offerings
2.1.3 Develop Strategic Assets
2.1.4 Prepare for execution
2.2 Challenges
2.3 Critical Success fact ors and risks
2.3.1 Complexity
2.3.2 Coordination and Control
2.3.3 Preserving value
2.3.4 Effectiveness in measurement
2.3.5 Risks
2.4 Summary
2.5 Questions
2.6 References
2.1 SERVICE STRATEGY
2.1.1 Define the market :
Organizations in the context of servi ce management are interested in
strategy from two distinct but linked perspectives. There are service
strategies and service strategies. Service strategies are designed from one
point of view. Customers can distinguish providers' services from
competitive alternatives.


munotes.in

Page 16

IT Service
Management
16

Figure 2.1: Strategies for services and services for strategies
Instead of actual items and transactions, the marketing approach for
services emphasises giving client’s processes, experiences, and
intangibles. It entails integrating the customer's focus across the entire
organisation and across all functions. To create a successful marketing
plan for services, the company's marketing, sales, human resources,
operations, and R&D departments must collaborate. The strategy of
marketing servi ces places more emphasis on customers, usage, and
connections than traditional products marketing does. Under a variety of
restrictions and with the help of their available resources, organisations
work to fulfil their business objectives. Limitations come in the form of
expenses and risks brought on by complexity, ambiguity, and commercial
disputes. The ability of the corporation to generate value depends on how
well its corporate assets perform. Assets must function well overall. The
corporation might own the assets or someone else might use them in a
variety of financial arrangements.
Most frequently, these arrangements consist of contracts or agreements for
services. Business managers have the obligation, power, and resources to
carry out specific tasks in the most effective way. Managers can enhance
the performance of company assets to provide better results by providing
services. The influence of a service on the performance of corporate assets
is the greatest way to gauge its value in terms of betterin g results.
2.1.2 Develop the offerings :
A collection of business outcomes that a service can facilitate defines a
market segment. The potential to simplify these outcomes identifies a
market sector. The following are examples of business outcomes that
could serve as the foundation for one or more market spaces:
● With the wireless computer sales management system, sales teams are
productive.
● The warehouse management system is connected to the e -commerce
website.
● Major commercial applications are secure and un der surveillance.
● Information on loan applicants is more quickly available to loan
officers. munotes.in

Page 17

Service Strate gy, Challenges,
Critical Success Factors and Risk
17 ● Customers have more payment options with online bill payment
services.
● There is no risk to business continuity.
Each of the terms and conditions is linked to the s ervices that make use of
one or more categories of client assets, such as personnel, facilities, data,
receivables, and purchase orders. There are various ways to satisfy each
requirement. Customers favour the option with lesser costs and risks. In
order t o accomplish certain business goals, service providers establish
these conditions by offering services and assistance to clients. As a result,
a market space provides service providers with a variety of chances to add
value to a customer's business through one or more services.
Even when the SLA's terms and conditions are adhered to, customers
frequently express their discontent with a service provider. Services are
frequently described in terms of resources that clients can use. The context
in which these resources are helpful and the business outcomes that, in the
client's eyes, justify the expense of a service are not sufficiently specified
in the definitions of service. Poor design, ineffective operation, and subpar
service contract performance are the r esults of this issue. If it is evident
where improvements are actually required, then improving services can be
challenging. Customers may comprehend and value improvements only in
the context of their own business assets, performance, and outcomes.
2.1.3 Develop Strategic Assets :
The service provided will only get better over time as both parties gain a
better understanding of their respective service demands. Some
stakeholders may enter into a service agreement with a service provider
that has low value c ontracts.
At this point, it would only make sense for the service provider to invest in
and expand their treasured services and goods by hiring more specialist
workers and using apps that can increase their services. This development
would only persuade a client to renew their partnership.
2.1.4 Prepare for execution :
Each service model exemplifies a process. This model offers a simple and
useful method for creating service strategy. It does not, however, ensure
success. Making a strategy relevant for the c ircumstances or context of an
organisation requires reflection and analysis. Thinking and acting are both
components of strategy.
Before developing a service plan, a supplier should thoroughly assess
what it already performs. Probably a core of distinction already exists. A
seasoned service provider frequently overlooks its own distinctive selling
points. The answers to the following queries can assist in defining a
service provider's unique capabilities:
Which of our services or service varieties are the m ost distinctive?
Which of our services or service varieties are the most profitable? munotes.in

Page 18

IT Service
Management
18 Which of our customers and stakeholders are the most satisfied?
Which customers, channels or purchase occasions are the most profitable?
Factor Description
Strength and Weaknesses The attributes of the organization. e.g.:
resources
Distinctive competencies capabilities, service quality, operating
leverage, experience, skills, cost
structures, customer service, global
reach, product knowledge, customer
relationships and so on.
Business strategy The perspective, position, plans and
patterns received from a business
strategy. For example, a Type I and II
provider may be directed, as part of a
new business model, to expose services
to external partners or over the internet.
Critical success factors How will the service provider know
when it is successful?
Threats and opportunities When must those factors be achieved?
Includes competitive thinking. For
example, 'Is the service provider
vulnerable to substitution?'
Table 2.1 Internal and external factors for a strategic assessment
2.2 CHALLENGES
While strategies are the measures to be taken to accomplish the goals,
challenges are the anticipated outcomes of pursuing them. To prevent
future disagreements, establish clear goals and use consistent decision -
making. They distinguish and act as benchmarks. Companies should steer
clear of the following "goal management" techniques.
● Crisis management: the idea that a company's capacity to resolve
issues is what defines it. Allowing ex ternal circumstances to guide
decisions is the strategy.
● Extrapolation management refers to continuing the same activity in the
same manner while things are going well.
● Managing with the hope that everything will turn out in the end.
● Subjective management: putting in your best effort to carry out the
necessary tasks. There is no overall strategy. munotes.in

Page 19

Service Strate gy, Challenges,
Critical Success Factors and Risk
19 Four typical information categories are frequently gathered and presented
as goals. Senior managers need to be aware of each category's risk, even if
it can't be e ntirely avoided:
1. Solutions - Customers communicate their needs in the form of a
problem solution. Customers might not have the necessary technical
knowledge to develop the most effective solution. In the end, clients
can be dissatisfied with the answer the y offer. To reduce this danger,
look for the standards used to assess the worth of a service rather than
the opinions of customers about the service itself.
2. Specifications - Customers submit their specification needs, including
vendor, product, architectur al style, computer platform, etc. By
adopting specifications, a provider unnecessarily restricts its own
business from offering the best services.
3. Customer wants are presented as high -level descriptions of the general
level of service quality. High -level e xplanations are inherently lacking
in particular client benefits.
4. Benefits - Customers present their needs in the form of benefit
statements. Again, the assertions' vagueness or accuracy pose a risk.
Better security, a quicker response, and high reliabilit y all have various
connotations for the organisation.
2.3 CRITICAL SUCCESS FACTORS
Every market sector has key success criteria that affect whether a service
approach is successful or unsuccessful. In business literature, critical
success elements are also known as strategic industry factors (SIF) and
generally include the following:
● They serve as important factors of the success of industry leaders and
are characterised in terms of competencies and resources.
● They are not unique to any one corporation; rat her, they are defined by
levels of market area.
● They serve as the foundation for rivals' competition.
● They need significant commitment and time to produce, are dynamic
rather than static, and their value is extracted in conjunction with other
elements.
Critical success factors by themselves are altered or influenced by one or
more of the following factors:
● Customers
● Competitors
● Suppliers
● Regulators. munotes.in

Page 20

IT Service
Management
20 2.3.1 Complexity :
IT companies are intricate systems. A complex system is defined by
organised complexity, as opposed to disorganised complexity (random
systems) or organised simplicity (simple systems).
Different from simple systems, complex systems pose peculiar difficulties.
They are closely related. They are adaptable and self -organizing. They are
hence polit ically resistant and self -stabilizing. Our comprehension of
things is limited by their intricacy. As a result, individuals become more
resistant to change the more you try to implement it.
2.3.2 Coordination and Control :
Decision -makers typically have cons trained amounts of time, focus, and
personal capacity. Teams and individuals with expertise in particular
systems, processes, performance, and results are given roles and
responsibilities. Deep knowledge, competence, and experience can be
developed through specialisation. Additionally, it makes it possible for
innovation, enhancements, and modifications to occur in a regulated
setting. The requirement for coordination rises in direct proportion to the
degree of expertise. Due to the degree of specialisation needed for various
phases, processes, and tasks of the service life cycle, this poses a
significant problem for service management. It is possible to strengthen
teamwork and individual control.
The objectives of one or more service management processes or life cycles
serve as the foundation for control perspectives.
They aid managers in concentrating on what is crucial and pertinent to the
operations they are in charge of, and they make sure they have accurate,
useful, and effective control information. De termining the information
needs for effective learning and organisational improvement can also
benefit from control approaches. Such a view of control is provided by
financial management. Customers display the amounts they are willing to
pay for a specific degree of service quality.
2.3.3 Preserving value :
Customers are aware of all relevant expenses that are incurred indirectly
as a result of getting the committed utility and guarantee, in addition to the
direct costs of actual usage. A very clear goal for service providers is to
provide value for their clients. Creating value for one's own stakeholders
is equally crucial. For internal providers, these two sets of objectives can
be tightly correlated. With foreign vendors in particular, they might easily
diverge or clash. Due to the hidden fees that customers pay when using a
service, consumer value is quickly lost. If the effect of the hidden costs is
set, poor service management during the lifespan may result in customers
paying far more than the service's pricing.

munotes.in

Page 21

Service Strate gy, Challenges,
Critical Success Factors and Risk
21 2.3.4 Effectiveness in measurement :
Performance metrics in service companies are frequently out of sync with
the business environment they support. Traditional metrics place a greater
emphasis on internal goals than on external factors that aff ect customer
satisfaction. Even measurements taken by established businesses have an
emphasis on control at the price of client responsiveness. Even though
every company is different, there are some universal principles that can be
used to create measureme nts that are effective. Measures concentrate on
strategic goals, monitor development, and offer commentary. Make sure to
adjust measurements when the plan changes. Because measures rather
than strategic aims dictate incentives and promotions, older measure ments
will achieve new objectives when they conflict. Adding new strategic
goals without altering the corresponding metrics remains unchanged. A
strategy that incorporates and supports cross -domain coordination with
service management has a higher chance o f success.
2.3.5 Risks :
Because risk is frequently associated with dangers, people typically view
it as something to avoid. Changes to the Service Portfolio are frequently
necessary for the implementation of strategies, which calls for risk
management. Ris k is characterised as the unpredictability of an event,
whether a favourable opportunity or a harmful threat. The fulfilment of an
organization's business goals may be impacted by hazards, which must be
identified and controlled in order to manage risks. E very company
controls its risk. The goal of risk management is to make sure the
organisation uses a risk framework with a set of clear processes in a cost -
effective manner. Through a thorough awareness of risks and their
anticipated consequences, it is hop ed to enable improved decision making.
There are two distinct phases: risk analysis and risk management.
● The goal of risk analysis is to acquire data on risk exposure so that the
company can manage risk appropriately and make informed decisions.
● Risk manag ement entails having procedures in place to keep track of
risks, having access to accurate and current risk information, having
the appropriate level of control in place to deal with those risks, and
having decision -making processes backed by a framework o f risk
analysis and evaluation.
2.4 SUMMARY
In this chapter we have covered Service Strategy, How Develop Strategic
Assets?, Prepare for execution.Challenges, critical success factors and
risks in terms of complexity, coordination and control, preserving v alue,
effectiveness in measurement, actual risks.

munotes.in

Page 22

IT Service
Management
22 2.5 QUESTIONS
1. How are markets defined in service strategy?
2. How should service strategy offerings be developed?
3. How should a service strategy create its strategic assets?
4. How should the Service Strategy be prepared for use?
5. What are the Service Strategy's difficulties?
6. What are the key success variables for the service strategy?
7. What level of complexity does Service Strategy involve?
8. In service strategy, what do coordination and control mean?
9. How can servic e strategy value be maintained?
10. Compose a brief essay on the effectiveness of service strategy
measurement.
11. What dangers are connected to service strategy?
2.6 REFERENCE FOR FURTHER READING
1. ITIL Foundation: ITIL 4 Edition (Itil 4 Foundation) by Axelos
2. ITIL v3 Foundation Complete Certification Kit.
3. ITIL v3 Service Strategy OGC/TSO
Web references :
1. https://www.tutorialspoint.com/itil
2. https://www.simplilearn.com /tutorials



munotes.in

Page 23

23 3
SERVICE DESIGN, SERVICE
DESIGN PRINCIPLES
Unit Structure:
3.1 Fundamentals
3.2 Service Design Principles:
3.2.1 Goals
3.2.2 Balanced Design
3.2.3 Identifying Service requirements
3.2.4 Identifying and docume nting business require ments and
drivers
3.2.5 Design activities
3.2.6 Design aspects
3.2.7 Subsequent design activities
3.2.8 Design constraints
3.2.9 Service oriented architecture
3.2.10 Business Service Management
3.2.11 Service Design Models
3.3 Summary
3.4 Questions
3.5 References
3.1 FUNDAMENTALS
The goal of service design is to take a service and adapt it to the demands
of the client and user. It can be applied to revamp current services or start
over to develop a new service. Creating the design standards for the
services that will be offered can be considered as the process of gathering
service demands, translating them into integrated service requirements. In
order to implement the strategy and facilitate the introduction of these
services in the live environment, the main goal of service design is to
design IT services in conjunction with IT practises, processes, and
policies. This ensures quality service delivery, customer satisfaction, and
cost-effective service delivery. The IT services should be efficiently munotes.in

Page 24

IT Service
Management
24 designed as part of service design so that they do not require significant
upgrade during their life cycle.
3.1.1 Objective and aspects of Design :
To develop appropriate and creative IT services, including their
architectures, procedures, policies, and docum entation, to fulfil present
and future business requirements, is the major objective of the service
design stage. The service design process has five distinct components.
1. Updated or new services
2. System and tools for service administration, including the se rvice
portfolio and service catalogue
3. Technology in architecture and management.
4. Required procedures.
5. Metrics and measurement techniques.
3.1.2 Service Design purpose :
Organizations involved in creating, delivering, or supporting services,
including intern al and external service providers, should consider ITIL
Service Design. Organisations with a goal of enhancing services through
the efficient use of service management principles and a service life -cycle
approach. Every professional working in service mana gement should read
the publication.
● IT architects
● IT managers
● IT practitioners
● IT service owners
3.1.3 Usage :
Offering an IT service can be done in -house, externally, or through a
partnership. This article is essentially applicable to all forms of service
delivery. Therefore, this book is relevant to anyone involved in the
delivery of IT services, whether it be within their own company, through
outsourcing, or through joint ventures. This document might be useful to
business managers in understanding and im plementing IT services and
supporting best practises. This document will be helpful for supplier
organisation managers when creating service delivery and support
agreements.
3.1.4 Four P’s of Service Design :
The service design step transforms the needs and desires of the clients into
the services they desire. Determine your target market and how to set your
company's offerings apart from those of your rivals with the use of service
design. When preparing a service, a service designer must take the four Ps
into account: munotes.in

Page 25

Service Design, Service Design Principles
25 1. Peoples: Individuals are in charge of offering IT services. These
specialists ought to possess the abilities needed to render services.
2. Products: The tools, services, and technology utilised in the
provision of and support for the services are referred to as
products.
3. Processes: Processes manage and support the provided services to
ensure that they live up to consumer expectations and set service
levels. Every process needs to be measurable.
4. Partners: Suppliers, manufacturers, and vendors shoul d be taken
into account when designing services because they will be used to
maintain the service once it is live.
3.2 SERVICE DESIGN PRINCIPLES
The entire business process includes IT Service Design. It's critical to have
the appropriate interfaces and c onnections to design tasks. When creating
new or modified services, it is crucial that the full service life cycle and
ITSM processes are involved from the beginning. When a freshly
developed service is abruptly provided for live operation, operational
problems frequently result.
3.2.1 Goals :
1. Create services that are suited to organisational needs in order to
deliver more effective IT and organisational solutions and services to
fulfil corporate objectives based on quality, compliance, risk, and
security cr iteria.
2. Create services that can be built and improved quickly, cheaply, and
efficiently, and that can be curtailed or restricted when necessary.
3. Creating effective and efficient processes for the design, transition,
operation, and improvement of high -quality IT services, together with
ancillary tools, systems, and information, particularly the service
portfolio, to manage services throughout their lifecycles.
4. Creating resilient and secure IT environments, applications,
data/information resources, and infra structures.
5. Creating measurements and methodologies for assessing the
productivity and efficacy of design processes and the products they
produce.
6. Creating and maintaining IT strategies, processes, policies,
architectures, frameworks, and documents for des igning high -quality
IT solutions to satisfy the demands of the company both now and in
the future.
7. Assist in the creation of rules and guidelines for all design fields. munotes.in

Page 26

IT Service
Management
26 3.2.2 Balanced Design :
In order to ensure that both functional needs and performance go als are
met, the design of services must carefully balance any new business
requirements. In order to balance everything, it is necessary to consider
both the expenses of the new services and the resources that can be made
available in the necessary amount of time.
1. Functions: the service or product and its components, including all
necessary management and operational functionality, are both
functional and high -quality.
2. Resources: available personnel, equipment, and financial resources
3. The timelines, or sch edule.
Good communication between the various design activities and all other
stakeholders, including the business and IT planners and strategists, must
be ensured through the overall management of design activities to
accomplish this.
● All designers get ac cess to the most recent iterations of all pertinent
business and IT plans and strategies.
● All business and IT strategies and plans are in accordance with all
architectural and design documentation.
The architectures and designs are adaptable and allow :
● IT to act fast in response to changing business requirements.
● Adapt to all plans and regulations.
● Support the requirements of the Service Lifecycle's various phases.
● Provide new or modified, high -quality services and solutions that are
in line with the dema nds and timelines of the company.
3.2.3 Identifying Service requirements :
By using a holistic approach to the design of a new service, the service
design must consider all components of the service. In order to ensure that
the services offered fulfil the f unctionality and quality of service
expectations of the firm in all sectors, this approach should take into
account the service, its components, and their interrelationships:
● The service's potential to grow to accommodate changing needs and
further the lon g-term business goals.
● The business units and business processes that the service supports.
● The agreed -upon business capabilities and requirements, and the IT
service. munotes.in

Page 27

Service Design, Service Design Principles
27 ● The operational level agreements that go along with the internally
supported services an d components (OLAs).
● The externally supported services, components, and related underlying
contracts, which frequently have their own corresponding schedules or
agreements.
● The metrics and performance measurements needed.
● The needed or regulated standards of security.
3.2.4 Identifying and documenting business requirements and
drivers :
In order for IT to provide the most appropriate service catalog with a
tolerable level of service quality, it must maintain accurate information
about business req uirements. The business drivers are the people, data,
and tasks that help the company reach its goals. For IT to comprehend the
operational, tactical, and strategic needs of the business, it must develop
and maintain close, consistent, and appropriate inte ractions and
information sharing. This data must be acquired and agreed upon in two
key areas in order to ensure service alignment:
Information on the requirements of existing services - What adjustments
will be needed to existing services based on:
● Needs and functional specifications for new facilities.
● Business dependencies, priorities, effects, and criticality are altered.
● Changes in service transaction volumes.
● The new business driver may result in higher service levels and
targets, or lower service le vels for older services, lowering their
priority.
● For the management of services, additional information is required.
Information on the requirements of new services :
● Necessary amenities and skills.
● Management requirements and the information they need.
● Supported business processes, dependencies, priorities, importance,
and impacts.
● Seasonal changes and business cycles.
● Service level objectives and specifications.
● Levels of business transactions, service transaction levels, user types
and numbers, and expected future growth.
munotes.in

Page 28

IT Service
Management
28 3.2.5 Design activities :
Changes in company requirements or bettering of services serve as the
driving force behind all design activities. In order to maintain consistency
and integration across the IT service provider organisation in all design
activities, an organised and comprehensive approach to the design
activities should be used.
● Collection, analysis, and engineering of requirements to make sure that
business requirements are precisely outlined and accepted.
● Designing the rig ht services, technologies, workflows, data, and
process metrics to satisfy business needs.
● Review and updating of all service design -related procedures and
materials, such as designs, plans, architectures, and policies.
● Coordination with all other design a nd planning roles, such as those
involved in solution design.
● All design processes and deliverables are subject to risk assessment
and management.
● Making sure that all business and IT strategies and policies are
adhered to.
3.2.6 Design aspects :
For the de sign activities listed in the preceding section, a comprehensive,
integrated strategy should be used. It should cover the design of:
● Service solutions that meet all agreed -upon functional requirements
and have all necessary resources and capabilities.
● For the management and control of services throughout their lifecycle,
use service management tools and systems, particularly the service
portfolio.
● Tools needed to supply the services, including management structures
and technology architectures.
● Processes re quired for the services' design, transition, operation, and
improvement.
● Measurement techniques, methods, and metrics for processes,
structures, and the parts that make them up.
The most important feature is that new or changed service solutions are
create d to satisfy evolving business requirements. Every time a new
service solution is created, it needs to be compared to all previous ones to
make sure that it interfaces and integrates with all current services. The
next sections go into further information about these five service design
facets. The service design should provide plans that take into account the
design, transition, and operation of these five various aspects: munotes.in

Page 29

Service Design, Service Design Principles
29 ● The method used and the timelines involved.
● The new or modified solution's organisat ional effects on the business
and IT.
● The solution's financial impact on the company, including the funding,
expenses, and budgets needed.
● Planning communications with all interested parties and
communicating in all its forms.
● The effect of the solution on new or current agreements or contracts.
3.2.7 Subsequent design activities :
The following tasks must be finished with the service design stage after
developing the required service solution before the solution can go on to
the service transition stage.
A) Evaluation of Alternative Solutions
If external supplier services and solutions are involved, a further review
stage can be required. These things are included in this:
● Choosing a group of vendors and finishing the tendering procedure.
This calls for the creation and completion of:
o A Statement of Requirement (SoR) and/or Terms of Reference
(ToR) document, as well as documentation of the service's scope.
o Documents that include requests for information (RFI), proposals
(RFP), quotes (RFQ), and tenders (ITT) .
o Creating and approving a set of criteria for evaluating suppliers and
solutions, as well as a score system.
● Picking the preferred supplier(s) and their suggested solutions after
evaluating and assessing the supplier's reply.
● Evaluation and costing of pos sible suppliers' potential proposals,
technologies, solutions, and contracts, as well as perhaps discovering
potential suppliers.
B) Procurement of the preferred solution
It's possible that no more components are needed for the solution. The
steps are as f ollows if external suppliers take part in the preferred solution:
● Completing all required supplier checks on the chosen vendor.
● Completing the criteria and terms of any new contracts.
● Ensuring the application of all organisational policies.
● The purchase of the chosen option. munotes.in

Page 30

IT Service
Management
30 C) Develop the Service Solution
The service design is converted into a plan during the development phase.
Each programme plan or project is in charge of supplying one or more
service components, such as:
● The company's requirements.
● The approach to be taken in the creation and/or acquisition of the
solution.
● The timeframes at play.
● The creation of the service and all of its individual parts, such as
management and other operational processes including measuring,
monitoring, and reporting.
● Plans for service and component testing.
3.2.8 Design constraints :
Every design has a number of limitations. These limitations, which affect
many different industries, are a result of the business and service strategy.
Because it does not fit within the l imitations set, designers are not always
free to create the greatest solution for the business. A less expensive
alternative service should be found and approved by the company as there
may not be enough money for the best solution.
Only a solution that sa tisfies all of the known constraints can be offered by
the designer; otherwise, they must endeavour to relax or renegotiate some
of the restrictions in exchange for a greater budget.
The necessity for excellent corporate and IT governance as well as other
requirements to comply with rules, laws, and international standards are
responsible for many of these external pressures. As a result, it is crucial
that all designers are aware of them and make sure the designs and
solutions they generate include all the required controls and capabilities.
3.2.9 Service oriented architecture :
Business processes and solutions should be designed and developed using
the service -oriented architecture (SOA) methodology. Many firms adopt
the SOA strategy, which is regarded as b est practise, to increase their IT
service delivery effectiveness and efficiency.
SOA is defined by OASIS as:
'A paradigm for organizing and utilizing distributed capabilities that may
be under the control of different ownership domains. It provides a unif orm
means to offer, discover, interact with and use capabilities to produce
desired effects consistent with measurable preconditions and
expectations.'
munotes.in

Page 31

Service Design, Service Design Principles
31 A multinational collaboration that promotes the development,
convergence, and adoption of e -business st andards is called OASIS
(Organization for the Advancement of Structured Information Standards).
A company can benefit from SOA's promotion of the creation of reusable
"self-contained" services and increase its agility. This fosters the creation
of "shared services," which may be applied to numerous departments
inside the organisation, in a flexible and modular manner. Business
processes are being transformed by more and more companies into
standardised "packaged services" that can be shared and used across many
industries.
To create adaptable, reusable IT services that are common, can be shared,
and are utilised in numerous business sectors, IT service providers should
use the SOA and its guiding principles whenever possible. When
employing this strategy, it 's crucial that IT:
● Establishes what a service is and defines it.
● Recognises interfaces and relationships between services with
understanding.
● Makes use of standards in the creation and description of services.
● Use standard equipment and technology.
● Examin es and comprehends the effects of modifications to "shared
services."
3.2.10 Business Service Management :
Business service management (BSM) is a method and strategy for
integrating IT elements with organisational objectives. This can forecast
how technolog y will effect business and how changes in business will
impact technology. To improve the capabilities of the IT service provider
to supply BSM, it is crucial to create a completely integrated service
catalogue that includes business units, processes, and services, as well as
their connections to and dependencies on IT services, technology, and
components. An organisation of an IT service provider is able to:
● Align IT service delivery with corporate objectives and goals.
● Prioritize all IT tasks in accordanc e with their business effect and
urgency to make sure that the most important business services and
processes get the most attention.
● Boost corporate productivity and profitability by making IT
procedures more effective and efficient.
● Support company gover nance requirements with proper IT governance
and controls.
● Utilize and innovate the IT infrastructure as a whole to gain a
competitive advantage. munotes.in

Page 32

IT Service
Management
32 ● Boost user perception, customer satisfaction, and service quality.
● Make sure IT services are and remain in lin e with evolving business
requirements.
3.2.11 Service Design Models:
The model picked for delivering IT services determines the model picked
for designing IT services the most. A review of present capabilities and
provisions should be done for all facets o f the delivery of IT services
before adopting a design model for a significant new service. All facets of
the new service should be taken into account in this review, such as the:
● Business imperatives and needs.
● Demands, objectives, and specifications for the new service.
● Maturity of the processes used by the organisations currently involved.
● The organisations involved and their cultures.
● Components include IT infrastructure, applications, data, and services.
● Resources and financial constraints.
● Talents and staffing levels.
3.3 SUMMARY
In this chapter we have covered concept of Service Design and Service
Design Principles in terms of Goals, Balanced Design, Identifying Service
requirements, identifying and documenting business requirements and
drivers, Desig n activities, Design aspects, Subsequent design activities,
Design constraints, Service oriented architecture, Business Service
Management, Service Design Models .
3.4 QUESTIONS
1. What is Service Design? State its Objectives and Aspects.
2. Define Service Des ign and brief about its purpose and uses.
3. What are four P’s of Service Design?
4. Write note on Service Design principles.
5. Define Service Design and List and explain its goals.
6. What is Balanced Design?
7. What are Service Requirements? How o identify them?
8. How t o Identifying and document business requirements and drivers?
9. Write short note on Design activities. munotes.in

Page 33

Service Design, Service Design Principles
33 10. Write short note on Design aspects.
11. Explain in detail about Subsequent design activities.
12. Write short note on Design constraints.
13. Explain in brief about Se rvice oriented architecture.
14. Explain in details about Business Service Management.
15. Write short note on Service Design Models.
3.5 REFERENCE FOR FURTHER READING
1. ITIL Foundation: ITIL 4 Edition (Itil 4 Foundation) by Axelos
2. ITIL v3 Foundation Complete Certif ication Kit.
3. ITIL v3 Service Strategy OGC/TSO
Web references
1. https://www.tutorialspoint.com/itil
2. https://www.simplilearn.com/tutorials



munotes.in

Page 34

34 4
SERVICE DESIGN PROCESSES,
CHALLENGES, CRITICAL SUCCESS
FACTORS AND RISKS
Unit Structure:
4.1 Introduction
4.2 Service Catalogue Management
4.3 Service Level Management
4.4 Capacity Management
4.5 Availability Management
4.6 IT Service Continuity Management
4.7 Information Security Management
4.8 Supplier Management
4.9 Challenges
4.10 Risks
4.11 Summary
4.12 Questions
4.13 References
4.1 INTRODUCTION
Important data for the creation of new or changed services is primarily
provided by these processes. Five design factors should be taken into
account:
● The design of services, which takes into account all the agreed -upon
functional specifications, resources, and capabilities.
● The process of creating systems and tools for managing and
controlling services throughout their lifecycle, in particular the servic e
portfolio.
● The creation of management systems and technological frameworks.
● Creating the procedures required for creating, implementing, and
improving services, architectures, and procedures.
● Designing the metrics and measuring techniques for services,
architectures, and the processes and parts that make them up. munotes.in

Page 35

Service Design
Processes,
Challenges, Critical
Success factors and
Risks
35 The organised method should be used in each of the five areas to deliver
quality, repeatable consistency, and ongoing progress across the
organisation. No matter how basic, all IT service provide r organisations
already have certain components of their approach to these five issues. A
review of the components that are already in place and function effectively
should be done before beginning the implementation of enhancing
activities and processes.
Key Processes of Service Design are:
● Service Catalogue Management
● Service Level Management
● Capacity Management
● Availability Management
● IT Service Continuity Management
● Information Security Management
● Supplier Management
4.2 SERVICE CATALOGUE MANAGEMENT
Service catalogue management makes certain that a service catalogue, or a
list of all services, is created or maintained for all individuals involved in
IT service management or who have the right to access it. Additionally, it
offers correct details on all available services.
The following are the main goals of service catalogue management:
● To confirm that the agreed -upon services are precisely described,
recorded, and documented.
● The service catalogue must be updated in tandem with the service
portfolio in order to ensure that the business requirements serviced by
the IT service team are defined in the catalogue.
The service catalogue provides assistance in two ways:
● Customers can choose services based on their needs thanks to it.
● IT professionals benefit f rom making assumptions about the types of
technological services that should be offered to support business
services.
Types: Broadly, there are two types of service catalogues:
● Business Service Catalogue (BSC): It includes information on all IT
services fr om the perspective of the customer. Two other
subcategories —Retail Catalogue and Wholesale Catalogue —can be
created from it. munotes.in

Page 36

IT Service
Management
36 ● Technical Service Catalogue (TSC): This document provides
information on all IT services from an IT standpoint. Additionally, it
outlines the connections between the components, shared services,
supporting services, and CIs required to support the delivery of the
service to the business.
4.3 SERVICE LEVEL MANAGEMENT
One of the key clearly defined procedures in the Service Design Proce ss
Group of the ITIL best practise framework is Service Level Management
(SLM). It is the procedure in charge of continuously identifying,
monitoring, and reviewing the SLA -specified IT service standards. By
ensuring that appropriate contracts are reached with internal IT support
providers and external suppliers in the form of operational level
agreements (OLAs) and Underpinning Contracts (UCs) / subcontracts, the
ITIL SLM process aids in achieving the desired level of service.
Scope:
In order to anticipate and plan the resource requirements, the Service
Level Management Process (SLM) collaborates closely with the
management of availability and capacity. to ensure that the necessary
quality and service standards are attained utilising the resources agreed
upon with finance management, and directly tied to event management
and problem management.
Process Objective:
Creating services in accordance with agreed -upon service level objectives
and negotiating service level agreements with consumers. Additionally,
service level management is in charge of making sure that all operational
level contracts and agreements are valid and that service levels are tracked
and reported.
Activities:
● Deciding on, negotiating, drafting, and reaching an agreement on the
requirement s for new or modified services.
● All services are managed and reviewed to ensure they meet operational
service SLAs.
● All operational services are being tracked and their service
performance measured against the SLA goals.
● Customer satisfaction data collecti on, evaluation, and improvement in
collaboration with BRM.
● Scope of Service, SLAs, OLAs, and supporting contracts are all being
examined, revised, and documented.
munotes.in

Page 37

Service Design
Processes,
Challenges, Critical
Success factors and
Risks
37 Sub-Process:
1) Maintainance of the SLM Framework: The fundamental framework
for service level management is upheld by the SLM Framework's sub -
process.
2) Identification of Service Requirements: Used to record the demands or
intended outcomes for new services or significant service adjustments
from the customer's perspective.
3) Agreements Sign -Off and Se rvice Activation: After the service
transition is complete, make sure that all pertinent contracts are signed,
and assess whether the requirements for service acceptance have been
met.
4) Service Level Monitoring and Reporting: Used for reporting, to track
the service levels attained and evaluate them against the agreed -upon
service level targets.
Roles & Responsibilities:
● Service Level Manager: This position serves as the ITIL Service Level
Management Process's Process Owner. This position is in charge of
making sure that all Operational Level Agreements, Underpinning
Contracts, and ITIL Service Management processes are appropriate
and in line with achieving the specified service level goals. The service
level manager keeps track of and updates all stakeholde rs on the
service levels reached.
● Service Owner: The Service Owner is in charge of providing a certain
service within the specified service levels. Typically, while negotiating
operational level agreements, this position serves as the Service Level
Manager 's opponent (OLAs). The Service Owners are frequently seen
in charge of a group of technical experts or an internal support group.
4.4 CAPACITY MANAGEMENT
A procedure called capacity management is used to make sure that the
service provider has enough IT r esources to cost -effectively address
present and future business requirements. It assists in determining how
services are now in demand and how those demands may evolve over
time.
Scope:
The Capacity Management Process gives businesses the knowledge they
need to choose which components to upgrade, when to improve them, and
how much it will cost. This knowledge is about the actual and anticipated
utilisation of each component.
When planning the resource capacity needed to sustain the intended level
of servi ce, ITIL Capacity Management closely collaborates with other
ITIL processes like Service Level Management, IT Service Continuity munotes.in

Page 38

IT Service
Management
38 Management, and Availability Management to access the present IT
infrastructure. Coordinates the financial management process t o gather
data on budget allocation for all resource types and to alert the
organization's financial department if any further budget allocation is
necessary.
Process Objective: ensuring that IT infrastructure and service capabilities
are sufficient to meet the agreed -upon service level targets in a timely,
cost-effective way. Capacity management makes plans for the short -,
medium -, and long -term needs of the business while accounting for all the
resources needed to supply the IT service.
Activities:
● Design ing a service in a way that it will achieve Service Level
Agreement (SLA) goals after being put into use.
● Controlling resource performance to ensure services reach SLA goals.
● Periodically assessing existing service performance and capacity.
● Aiding in the d iagnosis of problems with performance.
● The development and upkeep of a capacity plan that is in line with the
organization's strategic aims.
● Collecting and analysing information on service usage, and, if
necessary, documenting new requirements.
● Directing t he execution of service capacity changes.
Process Steps:
Step 1 - Gather the Data: This step entails a few tasks, such as consulting
with the business to identify the required service levels and quality
standards. Then, with the help of Demand Management, forecast the
demand based on user roles and incorporate information from the Finance
Management team to calculate the expenses.
Step 2 - Design a Service and Create Agreement: After gathering all of the
aforementioned data, Service Level Management is use d to create a SLA
that can be agreed upon by all parties.
Step 3 - Build the Service: The service itself is built in this step. In order
to support the new service, this entails creating the required IT
infrastructure, procedures, and documentation.
Step 4 - Operation: The service's go -live date is set once it has been
constructed and everyone has confirmed that it satisfies the Acceptance
Criteria (SAC).

munotes.in

Page 39

Service Design
Processes,
Challenges, Critical
Success factors and
Risks
39 Sub-Process:
1) Business Capacity Management: Utilized to transform business
requirements into IT re quirements is business capacity management.
Additionally, it guarantees that future performance and capacity
requirements can be met. It estimates shifting demands for capacity and
tactically manages those demands.
2) Service Capacity Management: used to m anage, regulate, and foresee
the capacity and performance of operational services. To ensuring that the
performances and capacities of services reach their predetermined goals,
this involves taking proactive and reactive action.
By monitoring performance a nd comparing it to standards established in
Service Level Agreements (SLAs) or Service Level Requirements, this
aim is met (SLRs). For instance, if the company plans to buy more
desktops and laptops, they should also think about recruiting more IT
support engineers.
3) Component Capacity Management: It is used to manage, regulate,
and forecast the efficiency, capacity, and performance of certain IT
resources and components.
With the help of performance monitoring and forecasting, the overall
amount of servi ce downtime is to be decreased. For instance, if the
organisation notices that more softcopy and software are being used, it
may be time to upgrade the hard drive, RAM, and CPU of the PC.
4) Capacity Management Reporting: This sub -process, referred to as
Capacity Report, is in charge of producing reports on service information,
resource capacity, utilisation, and performance. Then, for the purposes of
planning and monitoring, this report is distributed to other Management
processes and IT Management.
Roles and Responsibilities:
● Capacity Manager: The capacity manager role is in charge of making
sure that services and infrastructure have enough capacity and can
meet the set performance targets in a timely and cost -effective manner.
All resources necessary to p rovide the service, as well as planning in
accordance with the short -, medium -, and long -term needs of the firm.
4.5 AVAILABILITY MANAGEMENT
The implementation of ITIL Availability Management makes sure that the
services are accessible when needed. This ty pically indicates that all
services are provided in accordance with service level agreements (SLAs).
The availability management team routinely evaluates the needs for the
availability of business processes in order to achieve this. Then they make
sure tha t there are the most economical backup plans. To ensure that they
satisfy the demands of the business, these strategies are periodically tested.
munotes.in

Page 40

IT Service
Management
40 Scope:
The component failure impact analysis (CFIA) and service outage analysis
(SOA) processes both heavily r ely on availability management.
Typically, the Availability Management team isolates the issue's root
cause, examines any associated trends, and then implements the necessary
measures to guarantee service availability in accordance with SLAs.
To plan for t he infrastructure requirements necessary to satisfy the
specified service level and quality, the ITIL Availability Management
process collaborates with Capacity Management, Service Level
Management, and IT Service Continuity Management.
In order to support them in achieving the operation level service targets
and quality requirements, it also closely collaborates with the Incident
Management and Event Management processes.
Process Objective: Defining, analysing, planning, monitoring, and
improving every fac et of the availability of IT services. It is in charge of
ensuring that all IT infrastructures, processes, tools, roles, etc. are suitable
for the established availability targets.
Components:
The accuracy of service availability is determined by six comp onents of
availability management. These are listed below:
● Availability: A service's or component's capacity to deliver the
agreed -upon functionality when necessary is evaluated. It is the ability
of a service, component or CI to perform its agreed functio n when
required. It is often measured and reported as a percentage:

● Reliability : - Is the capacity of a service or component to perform at a
predetermined level under specified circumstances. It is a measure of
long a service, component or CI can perform its agreed 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 (i.e.
increasing the component r edundancy, e.g. by using load -balancing
techniques). It is often measured and reported as Mean Time Between
Service Incidents (MTBSI) or Mean Time Between Failures (MTBF): munotes.in

Page 41

Service Design
Processes,
Challenges, Critical
Success factors and
Risks
41

● Maintainability: Describes a service or component's capacity to
continue operating or to be brought back to a functioning state. It is a
measure of how quickly and effectively a service, component or CI
can be reported 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:

MTRS should be used to avoid the ambiguity of the more common
industry term Mean Time To Repair (MTTR), which in some
definations includes only repair time, but in others includes recovery time.
The downt ime in MTRS covers all the contributory factors that make the
service, component or CI unavailable:
 Time to record
 Time to respond
 Time to resolve
 Time to physically repair and replace
 Time to recover
Example: A situation where a 24 × 7 service has be en running for a
period of 5, 020 hours with only two breaks, one of six hours and one of
14 hours, would give the following figures:

munotes.in

Page 42

IT Service
Management
42 ● Serviceability: Describes a supplier's capacity to uphold a service's or
a compo nent's availability under a third -party contract. Is the ability of
a third -party supplier to meet the terms of their contract. Often this
contract will include agreed levels of availability, reliability and/or
maintainability for a supporting service or c omponent.
● Resilience: It is a technique for maintaining the dependability of
services in the event of a significant failure, and it also calculates the
likelihood of such a failure. The necessity for service redundancy is
highlighted in this sentence.
● Secu rity: Security relates to the privacy, accuracy, and accessibility of
any data used to provide services.
Activities:
Availability Management process includes two types of activities, (i)
Reactive and (ii) Proactive.
(i) Reactive Activities: Reactive Availability Management includes
activities such as monitoring, measuring, analysis and management of all
events, incidents, and problems causing service unavailability. These
activities are generally performed by operational roles.
(ii) Proactive Activiti es: Proactive Availability Management includes
proactive planning, design, and monitoring of services to improve the
availability.
These activities are typically performed by design and planning roles.
Proactive activities can be further divided into two categories: Service
Availability & Component Availability.
Activities performed under this proactive category are:
● Participate in IT infrastructure design.
● Monitor actual IT availability achieved.
● Create, maintain & review Availability Plan.
● Schedule Avai lability Testing.
● Attend CAB meetings.
● Assessment & Testing after a major business change.
● Assess & Manage Risk in an economically viable way.
Sub-Process:
1) Design Services for Availability: As its name implies, this sub -process
is in charge of creating the technical features and procedures necessary to
uphold the agreed -upon availability criteria.
2) Availability Testing: All availability, resilience, and recovery
measures must be tested on a regular basis. This sub -process is in charge
of planning and organising those tests. munotes.in

Page 43

Service Design
Processes,
Challenges, Critical
Success factors and
Risks
43 3) Availability Monitoring and Reporting: Used to keep track of the
present success rates of services and components in terms of availability,
compare those results to the established availability benchmarks, pinpoint
improvement ar eas, and create a thorough report. Additionally, it
distributes the report for decision -making to other Service Management
procedures and IT Management.
Roles and Responsibilities:
● Availability Manager: All aspects of the availability of IT services and
components must be defined, analysed, planned, measured, and
improved in accordance with the responsibilities of this job. To ensure
that all IT infrastructure, procedures, tools, roles, etc. are suitable for
attaining the stated service level targets for a vailability, Availability
Manager must work in tandem with Capacity Manager.
4.6 IT SERVICE CONTINUITY MANAGEMENT
(ITSCM)
To ensure business continuity, ITSCM prepares the organisation to
recover from catastrophes and significant emergencies.
Through proac tive disaster and emergency planning and recurring disaster
and emergency management drills, it benefits the organisation in two
ways. The organization's business continuity management must be
integrated with the installation of ITSCM.
Scope:
A service pr ovider may not be able to fully benefit from the service if
service continuity cannot be maintained and/or restored within SLA.
To identify potential threats to service continuity and take preventive
measures, ITIL Continuity Management closely collaborate s with Risk
Management and Information Security Management.
Process Objective: Control hazards that could significantly affect IT
services. By lowering the risk of catastrophic events to an acceptable level
and making plans for IT service recovery, ITSCM m akes sure that the IT
service provider can always deliver the minimal level of service that was
previously agreed upon. Designing ITSCM with Business Continuity
Management in mind is a good idea.
Activities:
The process of managing IT service continuity g enerally consists of four
steps or activities:
1. Initiation: For ITSCM strategy and plans, initiation entails defining
policy, scope, terms of reference, project planning, and resource
allocation.
2. Requirements and Strategy: To identify the assets and their t hreats and
vulnerabilities, business impact analysis and risk assessments are
carried out for each of the IT services in this step. Additionally, the
Services that need to be retrieved are given priority. munotes.in

Page 44

IT Service
Management
44 3. Implementation: This stage comprises testing the im plementation of
the contingency plan, designing the risk reduction, implementing the
risk reduction measures, and evaluating recovery possibilities.
4. Ongoing Operation: This Operation stage takes care of testing,
reviewing, and revising the ITSCM plans on a regular interval, change
control of ITSCM plans, and also responsible for user education and
awareness.
Sub-Process:
There are four subprocesses in the IT Service Continuity Management
(ITSCM) Process.
1) ITSCM Support: This sub -process makes sure that every IT employee
who is in charge of responding to disasters is aware of their precise
tasks and has immediate access to all pertinent information when a
crisis strikes.
2) Develop Continuity Services: This sub -process is used to design
acceptable and financially viable continuity mechanisms and
procedures to satisfy the agreed -upon business continuity targets.
Plans for risk reduction and recovery are included in this.
3) ITSCM Training and Testi ng: This makes sure that all preventative
measures and recovery systems created for disaster recovery are
routinely tested. Additionally, it makes sure that every member of the
IT staff has the proper disaster recovery training.
4) ITSCM Review: This step is used to check if the ITSCM testing is
proceeding according to plan. Additionally, to make sure that the
current catastrophe avoidance measures continue to meet the needs of
the firm.
Roles and Responsibilities:
● IT Service Continuity Manager: It is in char ge of mitigating risks that
could have a significant negative impact on IT services. By lowering
the risk to an acceptable level and preparing for the recovery of IT
services, this role also ensures that a minimum agreed service level
will be offered at th e time of the disaster. The IT Service Continuity
Manager collaborates closely with the Risk Manager & Availability
Manager to accomplish the aforementioned goal.
4.7 INFORMATION SECURITY MANAGEMENT
The approach and controls for IT security within a compan y are described
in the ITIL Information Security Management Process.
Scope:
IT security and business security are aligned using information security
management (ISM), which also makes sure that information security is
effectively managed across all service s and service management tasks.
ISM is closely related to other ITIL processes like IT service continuity
management and availability management. munotes.in

Page 45

Service Design
Processes,
Challenges, Critical
Success factors and
Risks
45 Process Objective: To ensure the confidentiality, integrity and availability
of information, data and IT servi ces of an organization. Information
security management is usually part of a more comprehensive
organizational approach to security management than the IT service
provider.
Activities:
(i) Plan: The objective of this activity is to devise and recommend the
appropriate security measures, based on an understanding of the
organization’s requirement.
(ii) Implement: This key element ensures that appropriate procedures,
tools, and controls are in place to support the ITIL Information
Security Management Policy and Plan .
(iii)Evaluation: This phase is responsible for measuring the success of the
security implementation. For doing this it carries out regular technical
security audits of IT systems.
(iv) Maintain: This phase takes the security evaluation results and suggests
improve ments on security implementation, and on security agreements
as specified in, for example, SLAs and OLAs.
Remember that, these above phases are NOT one -time activity. These are
continuous and cyclic activities, as shown in the following diagram.
Roles:
● Information Security Manager: The confidentiality, integrity, and
availability of an organization's resources, information, data, and IT
services are the responsibility of the information security manager.
Compared to an IT service provider, this function ha s a broader range
of responsibilities that typically cover the complete organization's
monitoring and management of paper (hard copy), building access,
phone calls, etc.
4.8 SUPPLIER MANAGEMENT
The ITIL Supplier Management process is all about managing su ppliers
and the services they supply, to provide seamless quality of IT Services in
an economical manner.
Scope:
Getting value for money from suppliers and contracts is the main goal of
supplier management. All suppliers should be managed under supplier
management, and it should be made sure that all contracts with suppliers
adhere to business requirements, SLAs, and SLRs. To make sure that
suppliers provide the level of service necessary to fulfil service levels and
quality goals, the ITIL Supplier Managem ent Process closely collaborates
with Service Level Management and Availability Management.
Process Objective: to make certain that all agreements with suppliers
support the needs of the company and that all suppliers uphold their end of
the bargain. munotes.in

Page 46

IT Service
Management
46 Activ ities:
● Put in place and uphold the supplier policy.
● Management of suppliers under subcontract.
● Contracts selection, categorization, and risk analysis.
● Continue to use a supporting Supplier and Contract Management
Information System and a supplier policy ( SCMIS).
● Supplier Management for SCMIS.
● In addition to developing, negotiating, and agreeing on contracts with
suppliers and managing them throughout their lifecycles, standard
contracts, terms, and conditions should be maintained.
What is a Contract?
A wri tten agreement that is legally enforceable between a service provider
and a consumer to perform or receive specific services is known as a
contract. A contract with the supplier would typically include all the
relevant details, like the type of service, SL A targets, service fee, etc. The
formal phrase for assigning such a service to a third -party source is
"outsourcing".
ITIL Contract Management and Types of Supplier Contracts:
The following list of supplier -contract and outsourcing kinds is not all -
inclus ive.
Co-sourcing: Co-sourcing is a loosely defined form of outsourcing in
which a number of outsourcing companies collaborate to co -source
important lifecycle components.
Partnership or multi -sourcing: A formal agreement between two or
more organisations t o collaborate on the design, development, transition,
maintenance, operation, and support of IT services is known as multi -
sourcing or a partnership.
Business Process Outsourcing (BPO ): refers to formal agreements under
which a company assigns external org anisations the administration of one
or more of its business processes or functions.
Knowledge Process Outsourcing (KPO ): is a modern improvement to
business process outsourcing that entails the use of highly developed
analytical and specialised subject ab ilities to deliver business expertise.
Application Service Provision: is the process through which outside
companies deliver shared computer -based services to client companies
over a network. munotes.in

Page 47

Service Design
Processes,
Challenges, Critical
Success factors and
Risks
47 Underpinning Contract: contract between a service provider and a third
party provider for the receipt of certain services is known as the
underlying contract.
Sub-Process: Supplier Management has six sub -processes operating
under it.
1) Providing the Supplier Management Framework: Defines the
guidelines and standards f or procurement of services and products.
This also includes the terms of the Supplier Strategy and the
preparation of standard Terms and Conditions.
2) Assessment or Evaluation of new Suppliers and Contracts:
Responsible for evaluating prospective suppliers i n accordance with
the Supplier Strategy, and also to select the most suitable supplier.
3) Establishing new Suppliers and Contracts: This process is used to
negotiate and sign a binding agreement or contract with the suppliers.
This process is typically used for significant investments, either in
externally provided services or in technology.
4) Processing of Standard Orders: Responsible for processing pre -
defined orders and/or items for commodity products and services
within the boundaries of existing contract f rameworks.
5) Supplier and Contract Review: Responsible for verifying if the
contractually agreed performance is actually being delivered by
suppliers, and to define improvement measures if required.
6) Contract Renewal or Termination: It is used to carry out th e regular
assessment of existing contracts to check if they are still relevant with
current requirements. And also to do the renewals or termination of
contracts based on the assessment results.
Roles and Responsibilities:
● Supplier Manager: The Supplier M anager role is responsible for
ensuring that value for money is obtained from all suppliers. Supplier
Manager also makes sure that contracts with suppliers fulfil the
business needs, and that all suppliers are meeting their contractual
commitments.
4.9 CHA LLENGES
With every endeavour, difficulties or challenges must be met and
overcame. This is especially true when creating new services and
procedures that satisfy the needs of all company stakeholders. Experience
has shown that the following assists in over coming the difficulties:
● Recognizing and making sure that company priorities and
requirements are taken into account when designing processes and
services. munotes.in

Page 48

IT Service
Management
48 ● Communication will be essential for listening to the needs and
requirements of the individual as wel l as for describing what is
happening and how it affects people. Talking to people about topics
pertaining to their daily jobs is essential.
● Include as many individuals as you can in the design process. The
creation of focus groups or steering committees c an be quite effective
in finding the best answer and winning over more people.
● Participation from senior management and employees at all levels.
Examples of difficulties that could be encountered include:
● The purchased infrastructure has subpar monitoring and control
capabilities.
● Utilising a range of applications and technology.
● Changing or unclear business needs
● Lack of understanding of service objectives and commercial
requirements.
● The design does not incorporate some facilities.
● Unplanned efforts and purchases are the outcome of planning
opposition or a lack of planning.
4.10 RISKS
The design phase of the service life cycle is directly responsible for a
number of risks. These hazards must be recognised in order to prevent
realisation. These consist of:
● The service design or service management processes will not function
if any of the PFSs for service design are not met.
● Full maturity in other processes won't be possible to reach if one
process has a low maturity level.
● The business's needs for IT person nel are unclear.
● Business time constraints prevent giving enough time for service
design.
● Inadequate testing, which results in bad design and poor
implementation.
● In an effort to gain a competitive edge, the corporation strikes the
wrong balance between in novation, risk, and expense.
● Customers, partners, and infrastructure are insufficient to satisfy the
needs of the entire organisation. munotes.in

Page 49

Service Design
Processes,
Challenges, Critical
Success factors and
Risks
49 ● The strategies and policies are either unavailable or their content is
unclear.
● The budget and resources allocated for se rvice design activities are
insufficient.
● Insufficient design staff training or insufficient design phase time.
● Insufficient engagement or dedication to the application's functional
development, which results in insufficient focus on the needs of
service design.
4.11 SUMMARY
In this chapter we have covered Service Catalogue Management, Service
Level Management, Capacity Management, Availability Management, IT
Service Continuity Management, Information Security Management,
Supplier Management, Challenges an d Risks.
4.12 QUESTIONS
1. What is Service Design Process? List the Key Processes of Service
Design.
2. Explain in details Service Catalogue Management process of Service
design.
3. Explain in details Service Level Management process of Service
design.
4. Explain i n details Capacity Management process of Service design.
5. Explain in details Availability Management process of Service design.
6. Explain in details IT Service Continuity Management process of
Service design.
7. Explain in details Information Security Management process of
Service design.
8. Explain in details Supplier Management process of Service design.
9. Explain the sub processes in Service Level Management.
10. List and explain the Terminologies & Definitions in Service Level
Management.
11. Explain the sub processes in Capacity Management.
12. List and explain the Terminologies, Roles in Capacity Management
process.
13. Explain the components of Availability Management process. munotes.in

Page 50

IT Service
Management
50 14. Write short note on activities of Availability Management process.
15. List and explain the Terminologies & Definitions in Availability
Management.
16. List and explain the Terminologies & Definitions in IT
Service Continuity Management process.
17. List and Explain activities and sub processes of IT Service Continuity
Management process.
18. List and Explain activities o f Information Security Management
process.
19. List and explain the Terminologies & Definitions in Information
Security Management process.
20. What are the activities of Information Security Management process?
21. What is a Contract? Explain Contract Management and Types of
Supplier Contracts.
22. List and Explain sub processes of Information Security Management
process.
23. List and explain the Terminologies & Definitions in Information
Security Management process.
24. Explain in detail Challenges in Service Design Process.
25. Explain in detail Risks associated with Service Design Process.
4.13 REFERENCE FOR FURTHER READING
1. ITIL Foundation: ITIL 4 Edition (Itil 4 Foundation) by Axelos
2. ITIL v3 Foundation Complete Certification Kit.
3. ITIL v3 Service Strategy OGC/TSO
Web references
1. https://www.tutorialspoint.com/itil
2. https://www.simplilearn.com/tutorials

munotes.in

Page 51

51 5
SERVICE TRANSITION AND SERVICE
TRANSITION PRINCIPLES
Unit Structure:
5.0 Objective
5.1 Service Transition Fundamentals
5.2 Principles Supporting Service Transition
5.3 Policies for Service Transition
5.3.1 Define and implement a formal policy for Servic e Transition
5.3.2 Implement all changes to services through Service Transition
5.3.3 Adopt a common framework and standards
5.3.4 Maximize re -use of established processes and systems
5.3.5 Align Service Transition plans with the business needs
5.3.6 Establish and maintain relationships with stakeholders
5.3.7 Establish effective controls and disciplines
5.3.8 Provide systems for knowledge transfer and decision support
5.3.9 Plan release and deployment packages
5.3.10 Anticipate and manage course c orrections
5.3.11 Proactively manage resources across Service Transitions
5.3.12 Ensure early involvement in the service lifecycle
5.3.13 Assure the quality of the new or changed service
5.3.14 Proactively improve quality during Service Transition
5.4 Summary
5.5 Questions
5.6 References


munotes.in

Page 52

IT Service
Management
52 5.0 OBJECTIVES
After studying this chapter, you will be able:
 To Understand the basic fundamentals of service transition stage
 To develop an d improve the capabilities used to implement new or
changed (modified) IT services
 To discuss the principles to be followed at transition stage
 To explain policies for service transition stage.
5.1 SERVICE TRANSITION FUNDAMENTALS
Development and improvement of capabilities for transitioning new and
changed services into oper ations. Service transition is concerned with
management of change and with the introduction of new and changed
services into the environment. The service transition stage in the service
life-cycle has to make sure that the new and modified or retired servi ces
meet the expectations of the business as previously agreed upon in the
service strategy and service design stage of the ITIL life cycle.
5.1.1 PURPOSE, GOALS AND OBJECTIVES :
The purpose of Service Transition is to:
 Plan and manage the capacity and res ources required to package,
build, test and deploy a release into production and establish the
service specified in the customer and stakehold errequirements
 Provide guidance on the development and improvement of the
transition capabilities to modified and new services in the live
environment.
 Establish and maintain the integrity of all identified service assets as
they evolve through the Service Transition stage .
 Provide good -quality knowledge and information so that change,
Release and Deployment Manageme nt provide fast effective decisions
about promoting a release through the test environments and then into
production .
 Provide efficient repeatable build and install action mechanisms that
can be used to deploy releases to the test and production environmen ts
and be rebuilt if required to restore service
 Ensure that the service can be managed, operated and support edin
accordance with the requirements and constraints specified within the
Service Design.
The goals of Service Transitionare to:
 Establish expect ations of customers on how the performance and use
of the new or changed service can be used to enable business change .
 Enable the integration of release into their business processes and
services . munotes.in

Page 53

Service Transition And
Service Transition
Principles
53  Reduce variations in the predicted and actual performance of the
transitioned services
 Reduce the known errors and minimize the risks during transitioning
the new or changed services into production .
 Ensure that the service can be use din accordance with the
requirements and constraints specified within the servi ce requirements.
The objectives are to:
 Plan and manage the changes in service efficiently and effectively into
production within the predicted cost, quality and time estimates .
 Ensure there is minimal unpredicted impact on the production services,
operati ons and support organization .
 Increase the customer, user and Service Management staff satisfaction
with the Service Transition practices .
 Increase proper use of the services and under lying applications and
technology solutions .
 Provide clear and comprehe nsive plans that enable the customer to
align their activities with the Service Transition plans.




Figure 5.1 The scope of Service Transition munotes.in

Page 54

IT Service
Management
54 5.1.2 SCOPE :
The scope of Service Transition includes the management and
coordination of the processes, systems and functions to package, build,
test a nd deploy a release into production and establish the service
according to the requirements.
The scope of the Service Transition lifecycle stage is shown in Figure 5.1.
Service Transition activities are shown in the white boxes. The black
boxes represent a ctivities in the other ITIL .
In some situations, some activities may not apply . For example, the
transfer of a set of services from one organization to another may not
involve release, planning, build, test and acceptance.
5.2 SERVICE TRANSITION PRINCIPLES
These principles can be followed regardless of the organization, but the
approach may differ from organization to organization adapted to
circumstances such as distribution, size, resources and culture

5.2.1 PRINCIPLES SUPPORTING SERVICE TRANSITION :
Service Transition is supported by underlying principles that evolve from
Service Strategy considerations and underpin the Service Transition
practices and approach. These principles, help to understand what a
service is and how it delivers value to the busin ess, provide the foundation
for Service Transition.
1. DEFINE A SERVICE :
The value of a service is defined within the context of customers and
contracts within an eco -system that is commonly known as the business
environment.
ITIL defines a Service as "a means of delivering value to customers by
facilitating outcomes customers want to achieve without the ownership of
specific costs and risks.”
e.g. a “backup service” means that you don’t have to care about how much
tapes, disks or pen drive cost and you do n’t have to worry if one of the
staff is sick or on leave.
Resources are tangible and intangible assets that are owned or controlled
by the service provider or the organization for conversion into final
products or services that are utilized by customers. Resources are
converted into goods and services using knowledge, skills, experience,
processes, systems and technologies, which are by themselves a special
category of intangible assets called capabilities.
Figure 5.2 illustrates the service provider asse ts used to deliver services to
the business and customers. munotes.in

Page 55

Service Transition And
Service Transition
Principles
55 The term asset is used to refer either to capabilities or resources, or both
depending on the surrounding context.
Services are a means for providing value to customers as shown in Figure
5.3. They are a means by which one business unit delivers value to one or
more other business units, or to sub -units within itself. In this publication,
business units that deliver services are commonly referred to as service
providers or service units and those t hat use services are called customers
or simply business units.

Figure 5.2: Service assets required to deliver services to the business

Figure 5.3: Service provide value by increasing the performance of
customer assets and removing risks


munotes.in

Page 56

IT Service
Management
56 2. SERVICE UTILITIES AND WARRANTIES :
Utility is perceived by the customer from the attributes of the service that
have positive effect on the performance of task associated with the desired
business outcomes. This is fir for purpose.
Other way ofdefining utility of a service is in terms of the business
outcomes that customers expect the service to support and the constraints
it will remove. This utility is in the form of enhancing or enabling the
performance of the customer assets, and contributing to the realization of
business outcomes.
Utility is generally stated in terms of:
■ Outcomes supported
■ Ownership costs and risks avoided
Warranty ensures the utility of the service is available as needed with
sufficient capacity , continuity , and security. Value of warranty is
communicated in terms of level of certainty.
Warranty is usually defined in terms of availability, capacity, continuity,
and security of the utilization of the services.
.Three characteristics of warranty:
 Provided in terms of the availa bility and capacit y of services.
 Ensures that customer assets continue to receive utility, even if at
degraded service levels, through major disruptions or disasters .
 Ensures security for the value -creating potential of customer assets.
5.3 POLICIES FOR SERVICE TRANSITION
The following aspects constitute fundamental principles of Service
Transition. Their endorsement and visible support from senior
management contributes to the overall effectiveness.
5.3.1 DEFINE AND IMPLEMENT A FORMAL POLICY FOR
SERVICE TRANSITION :
Policy :
 A formal policy for Service Transition should be defined, documented
and approved by the management team, who ensure that it is
communicated to all relevant suppliers and partners and throughout the
organization.
Principles :
 Policies should clearly st ate the objectives and any non -compliance
with the policy shall be fixed. munotes.in

Page 57

Service Transition And
Service Transition
Principles
57  Align the policies with the overall governance framework,
organization and Service Management policies.
 Sponsors and decision makers involved in developing the policy must
demonstra te their commitment to adapting and implementing the
policy. This includes the commitment to deliver predicted outcomes
from any change in the Services.
 Use processes that integrate teams; blend competencies while
maintaining clear lines of accountability and responsibility.
 Deliver changes in releases.
 Address deployment early in the release planning and design stages.
Best practice :
 Obtain formal sign off from the management team, sponsors and
decision makers involved in developing the policy.
5.3.2 I MPLEMENT ALL CHANGES TO SERVICES THROUGH
SERVICE TRANSITION :
Policy :
 All changes to the Service Portfolio or service catalogue are
implemented through Change Management and the changes are
defines and agreed upon in the Service Transition lifecycle stage.
Principles :
 A single focus for changes to the production services minimizes the
likelihood of conflicting changes and potential disruption to the
production environment. People that do not have the authority to make
a change or release into the production environment should be
prevented from having access.
 Familiarity with the organization of Service Operations increases
mobilization and enables organizational change.
 Increasing knowledge and experience of the services and production
environment improves ef ficiency.
 Each release package will be designed and governed by a Request for
Change raised via the Change Management process to ensure effective
control and traceability.
 Standardized methods and procedures are used for efficient and
prompt handling of a ll changes, in order to minimize the impact of
change -related incidents on business continuity, service quality and re -
work.
 All updates to changes and releases are recorded against service assets
and/or configuration items in the Configuration Management System. munotes.in

Page 58

IT Service
Management
58 Best practices:
 The change definition is clearly defined.
 Distinguished Internal and external changes.
 Changes are justified through the development of a clear Business
Case.
 Changes to services are defined in a Service Design Package that
Servi ce Transition can use to measure the actual vs predicted progress
andperformance.
 The current process of Change Management may need to be
standardized and enforced.
 Management commitment to enforcing the process isessential, and it
must beclearly visible t o allstakeholders.
 Auditing settings aims to identify unauthorized changes.
 Do not accept late requests for modification which cannot be
managedproperly.
5.3.3 ADOPT A COMMON FRAMEWORK AND STANDARDS :
Policy :
 Base Service Transition on a common framework o f standard re -
usable processes and systems to improve integration of the parties
involved in Service Transition and reduce variations in the processes.
Principles :
 Implement best practices from industry as the basis of standardization
to enable integration across the supply chain.
 Control the Service Transition framework and standards under Change
and Configuration Management.
 Ensure processes are adopted consistently by scheduling regular
reviews and audits of the Service Management processes.
Best pract ices:
 Publish standards and best practices for Service Transition.
 Provide a framework for establishing consistent processes for assuring
and evaluating the service capability and risk profile before and after a
release is deployed.
 Provide supporting sy stems to automate standard processes in order to
reduce resistance to adoption. munotes.in

Page 59

Service Transition And
Service Transition
Principles
59  Ensure there is management understanding of the need for standard
ways of working by developing and delivering improvements based on
a sound Business Case.
 Establish the leve l of management and stakeholder commitment and
take action to close any gaps.
 Continually plan how to improve the buy -in to adopting a common
framework and standards.
5.3.4 MAXIMIZE RE -USE OF ESTABLISHED PROCESSES AND
SYSTEMS :
Policy :
 Service Transition p rocesses are aligned with the organization's
processes and related systems to improve efficiency and effectiveness
and where new processes are required; they are developed with re -use
in mind.
Principles :
 Re-use established processes and systems wherever p ossible.
 Capture data and information from the original source to reduce errors
and aid efficiency.
 Develop re -usable standard Service Transition models to build up
experience and confidence in the Service Transition activities.
 Implement industry stand ards and best practices as the basis of
standardization to enable integration of deliverables from many
suppliers.
Best practices :
 Integrate the Service Transition processes into the quality management
system.
 Use the organization's programme and project management practices.
 Use existing communications channels for Service Transition
communication.
 Follow human resources, training, finance and facilities management
processes and common practices.
 Design the Service Transition models that enable easy cu stomization
to suit specific circumstances.
 Structure models such that a consistent approach is repeated for each
target service unit or environment with local variation as required.
5.3.5 ALIGN SERVICE TRANSITION PLANS WITH THE
BUSINESS NEEDS : munotes.in

Page 60

IT Service
Management
60 Policy :
 Align Service Transition plans and new or changed service with the
customer and business organization's requirements in order to
maximize value delivered by the change.
Principles :
 Set customer and user expectations during transition on how the
performance and use of the new or changed service can be used to
enable business change.
 Provide information and establish processes to enable business change
projects and customers to integrate a release into their business
processes and services.
 Ensure that the s ervice can be used in accordancewith the requirements
and constraints specified within the service requirements in order to
improve customer and stakeholder satisfaction.
 Communicate and transfer knowledge to the customers, users and
stakeholders in order to increase their capability to maximize use of
the new orchanged service.
 Monitor and measure the use of the services andunderlying
applications and technology solutions during deployment and early life
support in order to ensure that the service is well established before
transition closure.
 Compare the actual performance of services after a transition against
the predicted performance defined in Service Design with the aim of
reducing variationsin service capability and performance.
Best practices :
 Adopt programme and project management best practices to plan and
manage the resources required to package, build, test and deploy a
release into production successfully within the predicted cost, quality
and time estimates.
 Provide clear and comprehensive p lans that enable the customer and
business change projects to align their activities with the Service
Transition plans.
 Manage stakeholder commitment and communications.
5.3.6 ESTABLISH AND MAINTAIN RELATIONSHIPS WITH
STAKEHOLDERS :
Policy :
 Establish and ma intain relationships with customers, customer
representatives, users and suppliers throughout Service Transition in
order to set their expectations about the new or changed service. munotes.in

Page 61

Service Transition And
Service Transition
Principles
61 Principles:
 Set stakeholder expectations on how the performance and use o f the
new or changed service can be used to enable business change.
 Communicate changes to all stakeholders in order to improve their
understanding and knowledge of the new or changed service.
 Provide good -quality knowledge and information so that stakeho lders
can find information about the Service Transition easily, e.g., release
and deployment plans, and release documentation.
Best practices:
 Check with stakeholders that the new or changed service can be used
in accordance with the requirements and con straints specified within
the service requirements.
 Share Service Transition and release plans and any changes with
stakeholders.
 Work with business relationship management and service level
management to build customer and stakeholder relationships durin g
Service Transition.
5.3.7 ESTABLISH EFFECTIVE CONTROLS AND DISCIPLINES :
Policy:
 Establish suitable controls and disciplines throughout the service
lifecycle to enable the smooth transition of service changes and
releases.
Principles:
 Establish and maint ain the integrity of all identified service assets and
configurations as they evolve through the Service Transition stage.
 Automate audit activities, where beneficial, in order to increase the
detection of unauthorized changes and discrepancies in the
configurations.
 Clearly define 'who is doing what, when and where at all handover
points to increase accountability for delivery against the plans and
processes.
 Define and communicate roles and responsibilities for handover and
acceptance through the Service Transition activities (e.g., build, test,
release and deployment) to reduce errors resulting from
misunderstandings and lack of ownership.
 Establish transaction -based processes for configuration, change and
problem management to provide an audit trail an d the management
information necessary to improve the controls. munotes.in

Page 62

IT Service
Management
62 Best practices:
 Ensure roles and responsibilities are well defined, maintained and
understood by those involved and mapped to any relevant processes
for current and foreseen circumstances.
 Assign people to each role and maintain the assignment in the service
knowledge management system (SKMS) or Configuration
Management system (CMS) to provide visibility of the person
responsible for particular activities.
 Implement integrated incident, probl em, change, Configuration
Management processes with service level management to measure
the quality of configuration items throughout the service lifecycle.
 Ensure that the service can be managed, operated and supported in
accordance with the requirements and constraints specified within the
Service Design by the service provider organization.
 Ensure that only competent staff can implement changes to controlled
test environments and production services.
 Perform configuration audits and process audits to identify
configuration discrepancies and nonconformance that may impact
Service Transitions.
5.3.8 PROVIDE SYSTEMS FOR KNOWLEDGE TRANSFER AND
DECISION SUPPORT :
Policy :
 Service Transition develops systems and processes to transfer
knowledge for effective op eration of the service and enable decisions
to be made at the right time by competent decision makers.
Principles :
 Provide quality data, information and knowledge at the right time to
the right people to reduce effort spent waiting for decisions and
conseq uent delays.
 Ensure there is adequate training and knowledge transfer to users to
reduce the number of training calls that the service desk handles.
 Improve the quality of information and data to improve user and
stakeholder satisfaction while optimising t he cost of production and
maintenance.
 Improve the quality of documentation to reduce the number of
incidents and problems caused by poor quality user documentation,
release, deployment, support or operational documentation.
 Improve the quality of releas e and deployment documentation to
reduce the number of incidents and problems caused by poor -quality munotes.in

Page 63

Service Transition And
Service Transition
Principles
63 user documentation, support or operational documentation time
between changes being implemented and the documentation being
updated.
 Provide easy access t o quality information to reduce the time spent
searching and finding information, particularly during critical
activities such as handling a major incident.
 Establish the definitive source of information and share information
across the service lifecycle and with stakeholders in order to
maximize the quality of information and reduce the overhead in
maintaininginformation
 Provide consolidated information to enable change , release and
deployment m anagement to expedite effective decisions about
promoting a release through the test environments and into
production.
Best practices :
 Provide easy access, presentation and reporting tools for the SKMS
and CMS in order.
 Provide quality user interfaces and tools to the SKMS and CMS for
different people and roles t o make decisions at appropriate times.
 Summarize and publish the predicted and unpredicted effects of
change, deviations from actual vs predicted capability and
performance together with the risk profile.
 Ensure Service Asset and Configuration Management information is
accurate to trigger approval and notification transactions for decision
making via workflow tools, e.g., changes, acceptance of deliverables.
 Provide knowledge, information and data for deployment, service
desk, operations and support teams to resolve incidents and errors.
5.3.9 PLAN RELEASE AND DEPLOYMENT PACKAGES :
Policy :
 Release packages are planned and designed to be built, tested,
delivered, distributed and deployed into the live environment in a
manner that provides the agreed levels o f traceability, in a cost -
effective and efficient way.
Principles :
 A release policy is agreed with the business and all relevant parties.
 Releases are planned well in advance.
 Resource utilization is optimized across Service Transition activities
to redu ce costs. munotes.in

Page 64

IT Service
Management
64  Resources are coordinated during release and deployment.
 Release and distribution mechanisms are planned to ensure the
integrity of components during installation, handling, packaging and
delivery is maintained.
 Emergency releases are managed in line with the emergency change
procedure.
 The risks of backing out or remediating a failed release are assessed
and managed.
 The success and failure of the releases packages is measured with the
aim of improving effectiveness and efficiency while opti mizing costs.
Best practices :
 All updates to releases are recorded in the Configuration
Management System.
 Definitive versions of electronic media, including software, are
captured in a
 Definitive Media Library prior to release into the service operation s
readiness test environment. Record the planned release and
deployment dates and deliverables with references to related change
requests and problems.
 Proven procedures for handling, distribution, delivery of release and
deployment packages including ver ification.
 Pre-requisites and co -requisites for a release are documented and
communicated to the relevant parties, e.g., technical requirements for
test environment.
5.3.10 ANTICIPATE AND MANAGE COURSE CORRECTIONS :
Course corrections :
When plotting a lon g route for a ship or aircraft, assumptions will be made
about prevailing winds, weather and other factors, and plans for the
journey prepared. Checks along the way - observations based on the actual
conditions experienced - will require (usually minor) al terations to ensure
the destination is reached.
Policy:
 Train staff to recognize the need for course corrections and empower
them to apply necessary variations within prescribed and understood
limits.
Principles:
 Build stakeholder expectation that change s to plans are necessary and
encouraged. munotes.in

Page 65

Service Transition And
Service Transition
Principles
65  Learn from previous course corrections to predict future ones and re -
use successful approaches.
 Debrief and propagate knowledge through end -of-transition
debriefing sessions and make conclusions available through the
service knowledge management system.
 Manage course corrections through appropriate Change Management
and baseline procedures.
Best practices :
 Use project management practices and the Change Management
process to manage course corrections.
 Document an d control changes but without makingthe process
bureaucratic (it must be easier to do it right than to cope with the
consequences of doing it wrong).
 Provide information on changes that were applied after the
configuration baseline was established.
 Invol ve stakeholders about changes when appropriate, but manage
issues and risks within Service Transition when appropriate.
5.3.11 PROACTIVELY MANAGE RESOURCES ACROSS
SERVICE TRANSITIONS :
Policy :
 Provide and manage shared and specialist resources across Servic e
Transition activities to eliminate delays.
Principles :
 Recognize the resources, skills and knowledge required to deliver
Service Transition within the organization.
 Develop a team (including externally sourced resources) capable of
successful implementa tion of the Service Transition strategy, Service
Design package and release package.
 Establish dedicated resources to perform critical activities to reduce
delays.
 Establish and manage shared resources to improve the effectiveness
and efficiency of Servi ce Transition.
 Automate repetitive and error -prone processes to improve the
effectiveness and efficiency of key activities, e.g., distribution, build
and installation.

munotes.in

Page 66

IT Service
Management
66 Best practices :
 Work with human resources (HR), supplier management etc. to
identi fy, manage and make use of competent and available resources.
 Recognize and use competent and specialist resources outside the
core ITSM team to deliver Service Transition.
 Proactively manage shared resources to minimize the impact that
delays in one tra nsition have on another transition.
 Measure the impact of using dedicated vs non dedicated resources on
delays, e.g., using operations staff who get diverted to fix major
incidents, scheduling issues with test facilities.
5.3.12 ENSURE EARLY INVOLVEMENT I N THE SERVICE
LIFECYCLE :
Policy:
 Establish suitable controls and disciplines to check at the earliest
possible stage in the service lifecycle that a new or changed service
will be capable of delivering the value required.
Principles:
 Use a range of techniq ues to maximize fault detection early in the
service lifecycle in order to reduce the cost of rectification. (The later
in the lifecycle that an error is detected, the higher the cost of
rectification.)
 Identify changes that will not deliver the expected b enefits and either
change the service requirements or stop the change before resources
are wasted.
Best practices :
 Involve customers or customer representatives in service acceptance
test planning and test design to understand how to validate that the
service will add value to the customer's business processes and
services.
 Involve users in test planning and design whenever possible. Base
testing on how the users actually work with a service - not just how the
designers intended it to be used.
 Use previo us experience to identify errors in the Service Design Build
in - at the earliest possible stage – the ability to check for and to
demonstrate that a new or changed service will be capable of
delivering the value required of it.
 Use an independent evaluati on of the Service Design and internal
audits to establish whether the risks of progressing are acceptable. munotes.in

Page 67

Service Transition And
Service Transition
Principles
67 5.3.13 ASSURE THE QUALITY OF THE NEW OR CHANGED
SERVICE :
Policy:
 Verify and validate that the proposed changes to the operational
services defined in the service and release definitions, service model
and Service Design Package can deliver the required service
requirements and business benefits.
Principles :
 Service Transition is responsible for assuring that the proposed
changes to the operational serv ices can be delivered according to the
agreements, specifications and plans within agreed confidence levels.
 Ensure that Service Transition teams understand what the customers
and business actually require from a service to improve customer and
users' sat isfaction.
 Quality assurance and testing practices provide a comprehensive
method for assuring the quality and risks of new or changed services.
 Test environments need to reflect the live environment to the greatest
degree possible in order to optimize t he testing efforts.
 Test design and execution should be managed and delivered
independently from the service designer and developer in order to
increase the effectiveness of testing and meet any 'segregation of duty'
requirements.
 Perform independent eva luations of the Service Design and the new or
changed service to identify the risks that need to be managed and
mitigated during build, test, deployment and use of the service - see
section 4.6.
 Implement problem and Configuration Management processes acr oss
the service lifecycle in order to measure and reduce the known errors
caused by implementing releases into production.
Best practices :
 Understand the business's process and priorities – this often requires
an understanding of their culture, language, customs and customers.
 Comprehensive stakeholder involvement is important both for
effective testing and to build stakeholder confidence, and so should be
visible across the stakeholder community.
 Understand the differences between the build, test and pr oduction
environments in order to manage any differences and improve the
ability to predict a service's behaviour. munotes.in

Page 68

IT Service
Management
68  Test environments are maintained under Change and Configuration
Management, and their continued relevance is considered directly as
part of any change.
 Establish the current service baseline and the Service Design baseline
prior to evaluation of the change. Evaluate the predicted capability,
quality and costs of the Service Design taking into account the results
of previous experience and stak eholder feedback prior torelease and
deployment.
 Consider the circumstances that will actually be inplace when Service
Transition is complete, not just what was expected at the design stage.
5.3.14 PROACTIVELY IMPROVE QUALITY DURING SERVICE
TRANSITION :
Policy:
 Proactively plan and improve the quality of the new or changed
service during transition.
Principles :
 Detect and resolve incidents and problems during transition to reduce
the likelihood of errors occurring during the operational phase and
directly adversely affecting business operations.
 Proactively manage and reduce incidents, problems and errors detected
during Service Transition to reduce costs, re -work and the impact on
the user's business activities.
 Align the management of incidents, problems and errors during
transition with the production processes in order to measure and
manage the impact and cost of errors across the service lifecycle
easily.
Best practices :
 Compare actual vs predicted service capability, performance and costs
during pilo ts and early life support in order to identify any deviations
and risks that can be removed prior to Service Transition closure.
 Perform an independent evaluation of the new orchanged service to
identify the risk profile and prioritize the risks that need to be
mitigated prior to transition closure, e.g., security risks that may
impact the warranties.
 Use the risk profile from the evaluation of the Service Design to
develop risk -based tests.
 Provide and test the diagnostic tools and aids with theservice d esk,
operations and support staff to ensure that, if something goes wrong in
testing or live production use, it is relatively simple to obtain key munotes.in

Page 69

Service Transition And
Service Transition
Principles
69 information that helps to diagnose the problem without impacting too
much on the user.
 Encourage cross -fertilization of knowledge between transition and
operation stages to improve problem diagnoses and resolution time,
e.g., workarounds and fixes.
 Establish transition incident, problem, error and resolution procedures
and measures that reflect those in use in the live environment.
 Fix known errors and resolve incidents in accordance with their
priority for resolution.
 Document any resolution, e.g., workarounds so that the information
can be analysed.
 Proactively analyse the root cause of high priority and repeat incidents.
 Record, classify and measure the number and impact of incidents and
problems against each release in the test, deployment and production
stages in order to identify early opportunities to fix errors.
 Compare the number and impact of incid ents and problems between
deployments in order to identify improvements and fix any underlying
problems that will improve the user experience for subsequent
deployments.
 Update incident and problem management with workarounds and fixes
identified in trans ition.
5.4 SUMMARY
In this chapter we have covered Service Transition Fundamentals,
Principles Supporting Service Transition and Polici es for Service
Transition like defining and implement ing a formal policy for Service
Transition, Implement ing all changes to services through Service
Transition, Adopt ing a common f ramework and standards, Maximizing re-
use of established processes and systems, Align ing Service Transition
plans with the business needs, Establish ing and maintain ing relationships
with st akeholders, Establish ing effective controls and disciplines,
Providing systems for knowledge transfer and decision support, Plan
release and deployment packages, Anticipating and manage course
correction, Proactively manage resources ac ross Service Trans itions,
Ensuring early involvement in the service life cycle, Assuring the quality
of the new or changed service, Proactively improve quality during Service
Transition .


munotes.in

Page 70

IT Service
Management
70 5.5 QUESTIONS
1. Describe Service Transition. Explain its objectives, purpose and goal.

2. Discuss the Principles of service transition stage.

3. Write short note on Warranty & Utility.

4. Write a short note on Policies.

5. Explain how to align service transition plans with the business needs?

6. Discuss how to establish & maintain relationships with s takeholders?

7. Explain how to establish effective controls and disciplines for service
transition?

8. Write a short note on proactively manage resources across service
transition.

9. Explain how to maximize Re -use of established processes and system
policy?

10. Describe how to assure the quality of the new or modified/ changed
service.

5.6 REFERENCES

 ITIL V3 Foundation Complete Certification Kit

 Foundation of IT Service Management - The Unofficial ITIL V3
Foundation Course by Brady Orand, 2nd Edition

 ITIL V3 Service Transition by OGC/TSO




munotes.in

Page 71

71 6
SERVICE TRANSITION PROCESS,
CHALLENGES, CRITICAL SUCCESS
FACTORS & RISK
Unit Structure:
6.0 Objective
6.1 Service Transition Processes
6.2 Transition Planning and Support
6.3 Change Management
6.4 Service Asset and Configuration Management
6.5 Relea se and Deployment Management
6.7 Service Validation and Testing
6.7 Evaluation
6.8 Knowledge Management
6.9 Critical Success Factors
6.10 Risks
6.11 Service Transition under Difficult Conditions
6.12 Summary
6.13 Questions
6.14 References
6.0 OB JECTIVE
After studying this chapter, you will be able:
 To understand the purpose and scope of each process of service
transition stage
 To explain all the processes executed at service transition stage of
ITSM life cycle
 To understand and handle the chall enges at services transition stage.
 To know critical success factors and risks.
munotes.in

Page 72

IT Service
Management
72 6.1 SERVICE TRANSITION PROCESSES
Service Transition phase aims to build, test and deploy the service in
production in cost -effective manner. There are seven key processes
involved at Service Transition stage of ITIL, which are as follows:
■ Transition Planning and Support
■ Change Management
■ Service Asset and Configuration Management
■ Release and Deployment Management
■ Service Validation and Testing
■ Evaluation
■ Knowledge Management.
6.2 TRANSITION PLANNING AND SUPPORT
Transition Planning & Support is one of the important process under the
ITIL Service Transition phase. Its all about managing service transition
projects. This process also referred as process of ITIL Project
Management.
6.2.1 PURPOSE, GOALS, OBJECTIVES AND SCOPE :
The purpose of the Transition Planning and Support activities is to:
▪ Plan appropriate capacity and resources to release new/changed
service into production
▪ Provide support for transition teams
▪ Ensure integrity o f customer assets, service assets, and configuration
throughout lifecycle
▪ Ensure issues, risks, deviations reported to stakeholders and decision
makers
▪ Coordinate activities across projects, suppliers, and service teams
The goals of Transition Planning and Support are to:
▪ Ensure that the requirements of Service Strategy encoded in Service
accordingly Plan and coordinate the resources.
▪ Identify, manage and control the risks of failure and disruption across
transition activities.

munotes.in

Page 73

Service Transition Process, Challenges, Critical
Success Factors & Risk
73 The objective of Transiti on Planning and Support is to:
▪ Plan and coordinate the resources to establish successfully a new or
changed service into production within the predicted cost, quality and
time estimates.
▪ Ensure that all parties adopt the common framework of standard re -
usable processes and supporting systems.
▪ Provide complete plans that enable the customer to align their
activities with the Service Transition plans.
The scope of the Service Transition Planning and Support activities
includes:
▪ Incorporating design and opera tion requirements into the transition
plans.
▪ Managing and operating Transition Planning and Support activities.
▪ Maintaining and integrating Service Transition plans across the
customer, service and contract portfolios.
▪ Managing Service Transition progress, changes, issues, risks and
deviations.
▪ Quality review of all Service Transition, release and deployment plans
Managing and operating the transition processes, supporting systems
and tools.
▪ Communications with customers, users and stakeholders.
▪ Monitoring and improving Service Transition performance.
6.3 CHANGE MANAGEMENT
Changes happen for a variety of reasons :
■ Proactively, e.g. seeking business benefits such as reducing costs or
improving services or increasing the ease and effectiveness of support
■ Reac tively as a means of resolving errors and adapting to changing
circumstances.
Changes should be managed to:
■ Optimize risk exposure (supporting the risk profile required by the
business)
■ Minimize the severity of any impact and disruption
■ Be successful at t he first attempt.
munotes.in

Page 74

IT Service
Management
74 To make an appropriate response to all requests for change entails a
considered approach to assessment of risk and business continuity, change
impact, resource requirements, change authorization and especially to the
realizable business benefit. This considered approach is essential to
maintain the required balance between the need for change and the impact
of the change.
6.3.1 PURPOSE, GOALS, OBJECTIVESAND SCOPE :
The purpose of the Change Management process is to ensure that:
■ Standardi zed methods and procedures used for efficient and prompt
handling of changes
■ All changes are recorded in Configuration Management System
■ Overall business risk is optimized
The goals of Change Management are to :
■ Respond to the customer's changing business requirements while
maximizing value and reducing incidents, disruption and re -work
■ Respond to the business and IT requests for change that will align the
services with the business needs.
The objective of the Change Management process is to ensure that
■ Changes are recorded and then evaluated, authorized, prioritized,
planned, tested, implemented, documented and reviewed in a
controlled manner.
SCOPE
The definition of a service change is:
The addition, modification or removal of authorized, planned or s upported
service or service component and its associated documentation.'
The scope of Change Management covers
 Changes to baselined service assets and configuration items across the
whole service lifecycle.
 Each organization should define the changes tha t lies outside the scope
of their service change process. That include:
● Changes with significantly wider impacts than service changes, e.g.
departmental organization, policies and business operations – these
changes would produce RFCs to generate consequen tial service
changes
● Changes at an operational level such as repair to printers or other
routine service components. munotes.in

Page 75

Service Transition Process, Challenges, Critical
Success Factors & Risk
75 Figure 6.1 shows a typical scope for the service Change Management
process for an IT department and how it interfaces with the business an d
suppliers at strategic, tactical and operational levels. It covers interfaces to
internal and external service providers where there are shared assets and
configuration items that need to be under Change Management Service
Change Management must interfac e with business Change Management
and with the supplier's Change Management. This may be an external
supplier with a formal Change Management system, or with the project
change mechanisms within an internal development project.
The Service Portfolio provi des a clear definition of all current, planned
and retired services.


6.3.2 TYPES OF CHANGE REQUEST
A change request is a formal communication seeking an alteration to one
or more configuration items. For different change types there are often
specific procedures. There are three different types of service change:
■ Standard change A pre -authorized change that is low risk, relatively
common and follows a procedure or work instruction.
■ Emergency change A change that must be implemented as soon as
possib le, for example to resolve a major incident or implement a security
patch.
■ Normal change Any service change that is not a standard change or an
emergency change.
THE SEVEN R’s OF CHANGE MANAGEMENT
■ Who RAISED the change?
■ What is the REASON for the change?
■ What is the RETURN required from the change? Figure 6.1 Scope of change an d release management for services
munotes.in

Page 76

IT Service
Management
76 ■ What are the RISKS involved in the change?
■ What RESOURCES are required to deliver the change?
■ Who is RESPONSIBLE for the build, test and implementation of the
change?
■ What is the RELATIONSHIP between this change and other changes?
6.4 SERVICE ASSET AND CONFIGURATION
MANAGEMENT (SACM)
No organization can be fully efficient or effective unless it manages its
assets well, particularly those assets that are vital to the running of the
customer's or organization 's business. This process manages the service
assets in order to support the other Service Management processes.
6.4.1 PURPOSE, GOAL AND OBJECTIVE :
The purpose of SACM is to:
■ Identify, control, record, report, audit and verify service assets and
configurat ion items, including versions, baselines, constituent
components, their attributes, and relationships
■ Account for, manage and protect the integrity of service assets and
configuration items
■ Protect the integrity of service assets and configuration items
■ Ensure the integrity of the assets and configurations required to control
the services and IT infrastructure by establishing and maintaining an
accurate and complete Configuration Management System.
The goals of Configuration Management are to:
■ Support t he business and customer's control objectives and
requirements
■ Support efficient and effective Service Management processes by
providing accurate configuration information to enable people to make
decisions at the right time, e.g. to authorize change and r eleases,
resolve incidents and problems faster.
■ Minimize the number of quality and compliance issues caused by
improper configuration of services and assets
■ Optimize the service assets, IT configurations, capabilities and
resources.
The objective is to define and control the components of services and
infrastructure and maintain accurate configuration information on the
historical, planned and current state of the services and infrastructure. munotes.in

Page 77

Service Transition Process, Challenges, Critical
Success Factors & Risk
77 6.4.2 CONFIGURATION MANAGEMENT SYSTEM:
Service Asset and Confi guration Management requires the use of a
supporting system known as the Configuration Management System
(CMS) to manage large and complex IT services and infrastructures.
The CMS holds all the information for Cls within the designated scope.
Some of these items will have related specifications or files that contain
the contents of the item, e.g. software, document or photograph. For
example, a Service Cl will include the details such as supplier, cost,
purchase date and renewal date for licences and mainte nance contracts and
the related documentation such as SLAs and underpinning contracts.
The CMS maintains the relationships between all service components and
any related incidents, problems, known errors, change and release
documentation and may also cont ain corporate data about employees,
suppliers, locations and business units, customers and users.
6.5 RELEASE AND DEPLOYMENT MANAGEMENT
Release and Deployment Management aims to build, test and deliver the
capability to provide the services specified by Se rvice Design and that will
accomplish the stakeholders' requirements and deliver the intended
objectives.
6.5.1 PURPOSE, GOAL AND OBJECTIVE :
The purpose of Release and Deployment Management is to:
■ Define and agree release and deployment plans with customer s and
stakeholders
■ Ensure that each release package consists of a set of related assets and
service components that are compatible with each other
■ Ensure that integrity of a release package and its constituent
components is maintained throughout the tran sition activities and
recorded accurately in the CMS
■ Ensure that all release and deployment packages can be tracked,
installed, tested, verified, and/or uninstalled or backed out if
appropriate
■ Ensure that organization and stakeholder change is managed d uring
the release and deployment activities.
■ Record and manage deviations, risks, issues related to the new or
changed service and take necessary corrective action
■ Ensure that there is knowledge transfer to enable the customers and
users to optimize their use of the service to support their business
activities munotes.in

Page 78

IT Service
Management
78 ■ Ensure that skills and knowledge are transferred to operations and
support staff to enable them to effectively and efficiently deliver,
support and maintain the service according to required warrant ies and
service levels.
The goal of Release and Deployment Management is to deploy releases
into production and establish effective use of the service in order to deliver
value to the customer and be able to handover to service operations.
The objective of Release and Deployment Management is to ensure
that:
■ There are clear and comprehensive release and deployment plans that
enable the customer and business change projects to align their
activities with these plans
■ A release package can be built, install ed, tested and deployed
efficiently to a deployment group or target environment successfully
and on schedule
■ A new or changed service and its enabling systems, technology and
organization are capable of delivering the agreed service requirements,
i.e. uti lities, warranties and service levels
■ There is minimal unpredicted impact on the production services,
operations and support organization.
■ Customers, users and Service Management staff are satisfied with the
Service Transition practices and outputs, e.g. user documentation and
training.
6.6 SERVICE VALIDATION AND TESTING
Service validation and testing is the process used to maintain test
environments and to ensure the releases developed meet the expectations
of the customer. It ensures that the new servic es after deployment can be
supported by IT operations.
The concept to which Service Testing and Validation contributes is quality
assurance.
6.6.1 PURPOSE, GOAL AND OBJECTIVES:
The purpose of the Service Validation and Testing process is to:
■ Plan and impl ement a structured validation and testing process that
demonstrates the new or changed service will support the customer's
business, stakeholder requirements i.e. agreed service levels
■ Provide Quality assurance for the new release (Both Service &
Compone nts)
■ Identify, assess and report issues, errors and risks throughout Service
Transition stage. munotes.in

Page 79

Service Transition Process, Challenges, Critical
Success Factors & Risk
79 The goal of Service Validation and Testing is to assure that a service will
provide value to customers and their business.
The objectives of Service Validation a nd Testing are to:
■ Provide confidence that a release will create a new or changed service
or service offerings that deliver the expected outcomes and value for
the customers within the projected costs, capacity and constraints.
■ Validate that a service is 'fit for purpose' - it will deliver the required
performance with desired constraints removed
■ Assure a service is 'fit for use' - it meets certain specifications under
the specified terms and conditions of use
■ Confirm that the customer and stakeholder r equirements for the new or
changed service are correctly defined and remedy any errors or
variances early in the service lifecycle as this is considerably cheaper
than fixing errors in production.


6.7 EVALUATION
Evaluation is a generic process that con siders whether the performance of
something is acceptable, value for money etc. - and whether it will be
proceeded with, accepted into use, paid for, etc.
6.7.1 PURPOSE, GOAL AND OBJECTIVE :
The purpose of evaluation is to provide a consistent and standardi zed
means of determining the performance of a service change in the context
of existing and proposed services and IT infrastructure. The actual
performance of a change is assessed against its predicted performance and
any deviations between the two are und erstood and managed.
The goal of evaluation is to set stakeholder expectations correctly and
provide effective and accurate information to Change Management to
make sure changes that adversely affect service capability and introduce
risk are not transition ed unchecked.

Figure 6.2 Value Creation from service utilities & warranties
munotes.in

Page 80

IT Service
Management
80 The objective is to:
■ Evaluate the intended effects of a service change and as much of the
unintended effects as is reasonably practical given capacity, resource
and organizational constraints
■ Provide good quality outputs from the evaluati on process so that
Change Management can expedite an effective decision about whether
a service change is to be approved or not.
6.8 KNOWLEDGE MANAGEMENT
The ability to deliver a quality service or process rests to a significant
extent on the ability of th ose involved to respond to circumstances - and
that in turn rests heavily on their understanding of the situation, the
options and the consequences and benefits, i.e. their knowledge of the
situation they are, or may find themselves, in. That knowledge wit hin the
Service Transition domain might include:
■ Identity of stakeholders
■ Acceptable risk levels and performance expectations
■ Available resource and timescales.
The quality and relevance of the knowledge rests in turn on the
accessibility, quality and co ntinued relevance of the underpinning data and
information available to service staff.
6.8.1 PURPOSE, GOAL AND OBJECTIVE:
The purpose of Knowledge Management is to ensure that the right
information is delivered to the appropriate place or competent person at
the right time to enable informed decision.
The goal of Knowledge Management is to enable organizations to improve
the quality of management decision making by ensuring that reliable and
secure information and data is available throughout the service li fecycle.
The objectives of Knowledge Management include:
■ Enabling the service provider to be more efficient and improve quality
of service, increase satisfaction and reduce the cost of service
■ Ensuring staff have a clear and common understanding of the va lue
that their services provide to customers and the ways in which benefits
are realized from the use of those services Ensuring that, at a given
time and location, service provider staff have adequate information on:
-Who is currently using their services ?
-The current states of consumption
-Service delivery constraints
-Difficulties faced by the customer in fully realizing the benefits
expected from the service. munotes.in

Page 81

Service Transition Process, Challenges, Critical
Success Factors & Risk
81 Knowledge Management is typically displayed within the Data -to-
Information -to-Knowledge -to-Wisdom (DIKW) structure. The use of
these terms is set out below.
Data is a set of discrete facts about events. Most organizations capture
significant amounts of data in highly structured databases such as Service
Management and Configuration Management to ols/systems and databases.
The key Knowledge Management activities around data are the ability to:
Capture accurate data Analyse, synthesize, and then transform the data
into information
Identify relevant data and concentrate resources on its capture.
Information comes from providing context to data. Information is
typically stored in semi -structured content such as documents, e -mail, and
multimedia.
The key knowledge Management activity around information is managing
the content in a way that makes it e asy to capture, query, find, re -use and
learn from experiences so that mistakes are not repeated and work is not
duplicated.
Knowledge is composed of the tacit experiences, ideas, insights, values
and judgements of individuals. People gain knowledge both f rom their
own and from their peers' expertise, as well as from the analysis of
information (and data). Through the synthesis of these elements, new
knowledge is created.
Knowledge is dynamic and context based. Knowledge puts information
into an 'ease of u se' form, which can facilitate decision making. In Service
Transition this knowledge is not solely based on the transition in progress,
but is gathered from experience of previous transitions, awareness of
recent and anticipated changes and other areas tha t experienced staff will
have been unconsciously collecting for some time.
Wisdom gives the ultimate discernment of the material and having the
application and contextual awareness to provide a strong common -sense
judgement.
6.8.2 THE SERVICE KNOWLEDGE MA NAGEMENT SYSTEM:
Specifically, within IT Service Management, Knowledge Management
will be focused within the Service Knowledge Management System
(SKMS) concerned, as its name implies, with knowledge. Underpinning
this knowledge will be a considerable quant ity of data, which will be held
in a central logical repository or Configuration Management System
(CMS) and Configuration Management Database (CMDB). However,
clearly the SKMS is a broader concept that covers a much wider base of
knowledge, for example:
munotes.in

Page 82

IT Service
Management
82 ■ The experience of staff
■ Records of peripheral matters, e.g. weather, user numbers and
behaviour, organization's performance figures
■ Suppliers' and partners' requirements, abilities and expectations
■ Typical and anticipated user skill levels.
Challenges, Critical Success Factors and Risks :
The complexity of services across the supply chain is increasing and this
leads to challenges for any service provider that implements new services
or changes existing services. IT within e -business not only supports the
primary business processes, but is part of the primary business processes.
This prime position brings a wide range of challenges to successful
Service Transition, such as:
■ Enabling almost every business process and service in IT, resulting in
a large cus tomer and stakeholder group that is involved and impacted
by Service Transition
■ Managing many contacts, interfaces and relationships through Service
Transition, including a variety of different customers, users,
programmes, projects, suppliers and partner s
■ There being little harmonization and integration of the processes and
disciplines that impact Service Transition, e.g. finance, engineering,
human resource management
■ There being inherent differences among the legacy systems, new
technology and human e lements that result in unknown dependencies
and are risky to change
■ Achieving a balance between maintaining a stable production
environment and being responsive to the business needs for changing
the services
■ Achieving a balance between pragmatism and bu reaucracy
■ Creating an environment that fosters standardization, simplification
and knowledge sharing Being an enabler of business change and,
therefore, an integral component of the business change programmes
■ Establishing leaders to champion the changes and improvements
Establishing 'who is doing what, when and where and 'who should be
doing what, when and where'
■ Developing a culture that encourages people to collaborate and work
effectively together and an atmosphere that fosters the cultural shifts
necessary to get buy -in from people munotes.in

Page 83

Service Transition Process, Challenges, Critical
Success Factors & Risk
83 ■ Developing standard performance measures and measurement methods
across projects and suppliers
■ Ensuring that the quality of delivery and support matches the business
use of new technology Ensuring that the Service Transiti on time and
budget is not impacted by events earlier in the service lifecycle (e.g.
budget cuts)
■ Understanding the different stakeholder perspectives that underpin
effective risk management within an organization
■ Understanding, and being able to assess, the balance between
managing risk and taking risks as it affects the overall strategy of the
organization and potential mismatch between project risks and
business risk
■ Evaluating the effectiveness of reporting in relation to risk
management and corporate governance.
6.9 CRITICAL SUCCESS FACTORS
Service provision, in all organizations, needs to be matched to current and
rapidly changing business demands. The objective is to improve
continually the quality of service, aligned to the business requirements,
cost-effectively. To meet this objective, the following critical success
factors need to be considered for Service Transition:
■ Understanding and managing the different stakeholder
■ perspectives that underpin effective risk management within an
organization a nd establishing and maintaining stakeholder 'buy -in' and
commitment
■ Maintaining the contacts and managing all the relationships during
Service Transition Integrating with the other service lifecycle stages,
processes and disciplines that impact Service Tr ansition
■ Understanding the inherent dependencies among the legacy systems,
new technology and human elements that result in unknown
dependencies and are risky to change
■ Automating processes to eliminate errors and reduce the cycle time
■ Creating and main taining new and updated knowledge in a form that
people can find and use Developing good -quality systems, tools,
processes and procedures required to manage a Service Transition
practice Good Service Management and IT infrastructure tools and
technology
■ Being able to appreciate and exploit the cultural and political
environment munotes.in

Page 84

IT Service
Management
84 ■ Being able to understand the service and technical configurations and
their dependencies Developing a thorough grasp of the hard factors
(processes and procedures) and soft (skills and competencies) factors
required to manage a Service Transition practice
■ Developing a workforce with the right knowledge and skills,
appropriate training and the right service culture
■ Defining clear accountabilities, roles and responsibilities
■ Establi shing a culture that enables knowledge to be shared freely and
willingly
■ Demonstrating improved cycle time to deliver change and less
variation in time, cost and quality predictions during and after
transition
■ Demonstrating improved customer and user sat isfaction ratings during
Service Transition Demonstrating that the benefits of establishing and
improving the Service Transition practice and processes outweigh the
costs (across the organization and services)
■ Being able to communicate the organization's attitude to risk and
approach to risk management more effectively during Service
Transition activities
■ Building a thorough understanding of risks that have
■ Impacted or may impact successful Service Transition of services in
the Service Portfolio.
6.10 RIS KS
Implementing the Service Transition practice should not be made without
recognizing the potential risk to services currently in transition and those
releases that are planned. A baseline assessment of current Service
Transitions and planned projects wi ll help Service Transition to identify
implementation risks.
These risks might include:
■ Change in accountabilities, responsibilities and practices of existing
projects that de -motivate the workforce
■ Alienation of some key support and operations staff
■ Additional unplanned costs to services in transition
■ Resistance to change and circumvention of the processes due to
perceived bureaucracy.
Other implementation risks include:
■ Excessive costs to the business due to overly riskaverse Service
Transition practic es and plans Knowledge sharing (as the wrong
people may have access to information) munotes.in

Page 85

Service Transition Process, Challenges, Critical
Success Factors & Risk
85 ■ Lack of maturity and integration of systems and tools resulting in
people 'blaming' technology for other shortcomings
■ Poor integration between the processes – causing pro cess isolation and
a silo approach to delivering ITSM
■ Loss of productive hours, higher costs, loss of revenue or perhaps even
business failure as a result of poor Service Transition processes.
6.11 SERVICE TRANSITION UNDER DIFFICULT
CONDITIONS
In some cir cumstances, Service Transitions will be required under atypical
or difficult conditions, such as:
■ Short timescale
■ Restricted finances
■ Restricted resource availability - not enough people or lack of test
environments, inadequate tools etc.
■ Absence of anti cipated skills sets Internal political difficulty, staff
disincentives, such as:
-Redundancy/outsourcing or similar threats
-Difficult corporate culture of confrontational management style
-Internal rivalries and competitiveness
■ External difficulties suc h as weather, political instability, post -disaster,
legislation.
Clearly, some of these circumstances overlap with continuity planning,
and many of the approaches set out in the Service Design publication will
be relevant to successful transition in diffi cult circumstances.
If the difficulties are anticipated, then alleviating measures will be
identified and form part of the service package, planning the route through
transition within the transition model, as would any foreseen factors likely
to influenc e transition.
It is quite possible, however, that the difficulties will be unanticipated,
perhaps due to changed circumstances, and will require 'on the fly'
adaptation. This section sets out some of the constraining circumstances
that might require adapta tion, modification or compromise, and elements
of approach that would aid success. A key element common to most (if not
all) of these situations is having a clear understanding of what will
constitute success. When circumstances are difficult priorities ar e often
focused on specific aspects of service, customer base etc. – then to deliver
accepted priorities in the constrained circumstances will often require
compromises in other areas.


munotes.in

Page 86

IT Service
Management
86 6.11.1 WHEN SPEED IS MORE IMPORTANT THAN ACCURACY
OR SMOOTHNESS :
In time critical situations, implementation of a new or changed service
may be more important than a degree of disruption. This is effectively a
risk management decision, and general risk management principles apply.
Some of the key factors that assist with d elivering success in this context
are:
■ Empowerment - with staff given the authority to take appropriate
levels of risk. In volatile industries Service Transition must act in a
way that reflects the corporate risk culture and not suppress or
undermine busin ess risk decisions.
■ A need to know the absolute cut off date/time that Service Transition
must deliver by - too often either 'safety margins' are built in meaning
a product is delivered early that could have been improved, or people
assume there is some l eeway and there isn't - meaning critical
deadlines are missed. It is often better to be totally open and trust key
staff.
■ Deciding which components of the transitioned service must be
available at the cut -off date, and which could be added later.
■ How sep arable are the components and what are the dependencies?
What elements might be required although not initially on the
'essentials' list?
■ Which users/customers/locations etc. must be in place at the cut -off
date?
■ What actually happens if you fail? Again, honesty is often the best
policy here. Consider:
-Business impact
-Money
-Lives
-Political embarrassment
-Reputation.
Understanding crisis management can be very helpful in coping and
especially understanding that the rules for crisis management are d ifferent
from those for everyday management. Just being aware of the first two
laws of crisis management (after Larry Niven) can help to reassure people
that the situation is survivable:
Rule 1: Don't panic.
Rule 2: A good crisis manager makes decisions i nstantly and acts on them.
If they later turn out to have been correct, so much the better, but speed is
often more important than efficiency in a crisis situation.
Success in these circumstances depends on:
■ Empowerment and subsequent support, and a belie f in that support.
Staff must be aware of their empowerment levels and actually believe munotes.in

Page 87

Service Transition Process, Challenges, Critical
Success Factors & Risk
87 that the organization will support their choices – not be in fear of a
'court martial approach.
■ Authorization channels and those channels being open and rapid.
There m ust be agreed actions if the channels don't function - e.g.
increased delegated authority, escalation, alternative support channels.
■ Following the procedures, realizing there is risk, and no blame
afterwards – if not the required flexibility and speed of response is
constrained.
6.11.2 RESTRICTED RESOURCES:
When resources are in short supply, a key aspect here is deciding what to
measure and sticking to that decision and the framework for delivery, e.g.:
■ What is the important parameter – speed, or low cost or whatever?
And knowing that will be the measure of importance afterwards, e.g.
no blame for it being expensive when the understanding was 'get it in
by 3 p.m. whatever the cost'.
■ Establish an applicable hierarchy of measures - speed - money - full
functionality etc. with some subordinate ones having absolute limits,
e.g. as quickly as possible, but not more that £12,500; or as cheaply as
possible but must be in by 30 September. This requires involving
budget holders, business decision makers etc. to ens ure the correct
parameters are built in.
■ Awareness and documentation. All actually and potentially aware staff
need to be aware of requirements, and a mechanism for keeping staff
informed quickly about changes to those requirements is essential.
6.11.3 SA FETY CRITICAL SERVICES AND HIGH -RISK
ENVIRONMENTS:
Ever -increasingly, IT services directly support or actually deliver services
on which lives depend, such as hospital services, emergency services call -
taking, flood control and aircraft 'fly -by-wire'. Extr a security and fool
proof approaches are required, with features such as:
■ Appropriate documentation, which is essential and often includes
counter -signatures and extra checks on stage approval; however,
excessive documentation can be counter -productive; hi gh risk can
often be found in conjunction with time -restricted situations (e.g.
emergency services coordination, meaning careful balancing of safety
and speed is required; in such circumstances skill and experience
and/or extensive training is a major fact or
■ Accuracy typically taking priority over speed
■ More rigorous testing, longer time periods and more detailed data
collected and maintained within the CMS
■ Measures of safety accurately assessed by an accepted authority, e.g.
what constitutes acceptable levels, such as safe radiation doses within
X-ray or radioactive environments munotes.in

Page 88

IT Service
Management
88 ■ Setting the sign -off authority, and ensuring those responsible are not
overly influenced by inappropriate pressures, such as concern about
company profit or staff bonuses as opp osed to risking human lives
■ In extreme circumstances ensuring more than one individual must be
involved for certain actions to be taken (e.g. typically the procedures
for launching nuclear weapons require simultaneous confirmation by
two trained officers)
■ Consider 'veto' rights for sub -groupings whereby those controlling any
key component of the service can stop implementation – as a 'no -go'
from one of a dozen teams can stop a launch of a the space shuttle.
6.11.4 WORKING WITH DIFFICULT CUSTOMERS:
Of cou rse, there is no such thing as a bad customer, really, but often there
are customers who are unclear of their role as a customer and so act in a
way that prevents rather than supports successful implementation.
Examples include customers who:
■ Feel the need to get too involved in the detail of how things are done,
instead of judging by the service delivered
■ Are not able to deliver the decisions and choose options to suit their
business needs
■ Do not make staff and resources available to facilitate
■ Effective Service Transition, for example providing data and staff to
assess the transitioned service, or to effect user testing.
These kinds of situation can often be improved by awareness and
education of:
■ Customers
■ Users
■ Transition staff (e.g. patience and dip lomacy skills)
■ Account management working with the customers to reassure
customers and ascertain their requirements
■ Careful budgetary control, so that customers can see the value
returning for their investment of staff time and other resources.
6.12 SU MMARY
In this chapters we have covered Service Transition Processes like
Transition Planning and Support, Change Management, Service Asset and
Configuration Management, Release and Deployment Management,
Service Validation and Testing, Evaluation, Knowledg e Management,
Challenges of Service Transition :-i) Complexity to change IT service
i.e. transitioning service into service operations phases, ii) Many contacts
and relationalship with stakeholders, users, customers, project teams
members, management peop les, suppliers, etc. iii) Achieving balance
between maintaining a stable live environment and responsive to the
business needs, iv) After change , proper integration between components munotes.in

Page 89

Service Transition Process, Challenges, Critical
Success Factors & Risk
89 have to be maintained, v) Developing leaders to champions and doing
continual improvement, vi) Finding out 'who is doing what, when, where'
and who should be doing, when and where?, vii) Developing a culture that
will encourage people to work together and to the change effectively in a
reliable and secure manner., viii) Achi eve balance between managing
risks and taking risks, ix) Time required for service transition should not
affect other ITSM cycle phases, x) Develop standard measures,
peformances measures and measurement tools across project and
suppliers. Critical Success Factors : - i) Creating and maintaining new
and updated knowledge so that people can use and understand it. ii)
Managing services in terms of high quality i.e. providing utility and
warranty to business. iii) Tools and technology required for building IT
infrastructure for developing good services. iv) Having clear defined
relationalship and interfaces with programme and project management. v)
Developing a culture that enables knowledge too be shared freely and
willingly. vi) Understand the legacy system, s uppliers, human elements
and risks involved to do service transition. vii) Understand technical
configurations and their dependencies. viii) Integrating service transition
with other ITSM life cycle phases and disciplines that impact it. ix)
Demonstrate im proved custoer and user satisfaction rating for service
transition. x) Being able to communicate with others stakeholders, users,
customers, project teams members, management peoples, suppliers, etc.
xi) Demonstrating the benefits of doing service transiti on practices and
processes that will lead to increase our budgets. xii) Understand yours
stakeholders, customers and their requirements and even their perspectives
for successful service transition. Risks involved in Service Transition: -
i) Unplanned costs will involve in service transition. ii) Isolation of some
key support and operations staff. iii) Change in accountabilities,
responsibilities and practices of existing projects that de -movites the
workforce. iv) Various types of risks factors will be invo lved such as short
time scale, restricted finances, restricted resources, absence of anticipated
skills, internal politics, communications problems etc. v) Lack of Spport
from management. vi) Lack of Commitment and Service Transition
under Difficult Condit ions.
6.13 QUESTIONS
1) Explain Transition planning and support process in detail
2) What is the purpose, goal and objectives of transition planning and
support process?
3) Explain in detail service asset configuration management process.
4) Describe the purpose, goa l and objectives of change management.
5) What is Change? What are the different types of Changes?
6) Specify the objectives and scope of release and deployment
management process.
7) List and explain Seven R (7 R’s) of ITIL Change management munotes.in

Page 90

IT Service
Management
90 8) Explain the scope of Asset Configuration Management Process.
9) Explain objectives and goals of Service Asset Configuration
Management Process.
10) What is the purpose of Release and deployment Management Process?
11) State and Explain purpose, objective and Goal of Service Validation
and Testing
12) Explain in detail Service Validation and testing process.
13) Write a short note on Knowledge Management.
14) List all the challenges of service transition stage
15) Write a detail note on critical success factor of service transition phase.
16) What are the mea sures to be taken in service transition phase when
speed is more important than accuracy or smoothness?
17) Explain in detail about the risks associated with service transition
phase.
18) Describe the terms Knowledge, Information and wisdom.
6.14 REFERENCES

 ITIL V3 Foundation Complete Certification Kit

 Foundation of IT Service Management - The Unofficial ITIL V3
Foundation Course by Brady Orand, 2nd Edition

 ITIL V3 Service Transition by OGC/TSO


munotes.in

Page 91

91 7
SERVICE OPERATIONS AND SERVICE
OPERATION PRINCIPLES
Unit Structure:
7.0 Objective
7.1 Service Operations Fundamentals
7.1.1 Purpose/goal/objective
7.1.2 Scope
7.1.3 Value to business
7.1.4 Optimizing Service Operation performance
7.2 Servi ce Operation Principles
7.2.1 Functions, Group, Teams, Departments and Divisions
7.2.2 Achieving Balance in Service Operations
7.2.2.1 Internal IT view versus external business view
7.2.2.2 Stability versus responsiveness
7.2.2.3 Quality of service versus cost of service
7.2.2.4 Reactive versus proactive
7.2.3 Providing Service
7.2.4 Operation Staff involvement in Service Design and Service
Transition
7.2.5 Operational Health
7.2.6 Communication
7.2.6.1 Meetings
7.2.6.1.1 The Operations meeting
7.2.6.1.2 De partment, group or team meetings
7.2.6.1.3 Customer meetings
7.2.7 Documentation
7.3 Summary
7.4 Questions
7.5 References
munotes.in

Page 92

IT Service
Management
92 7.0 OBJECTIVE
After studying this chapter, you will be able:
 To Understand the basic fundamentals of service operation stage
 To exp lain the principles of service operation
 To explain the importance of communication and different modes of
communication followed by different organization
 Explain the different types of meetings conducted in the organizations
7.1 SERVICE OPERATION FUNDAME NTALS
 Service operation manage the day to day IT activities/ operations – i.e.
things you do everyday to deliver a service to provide value to
customer through communication and support.
 Service operation ensures that services are being provided efficientl y
and effectively as per SLAs. (Service Level Agreement). It includes
monitoring services, resolving incidents, fulfilling requests and
carrying out operational tasks.
7.1.1 PURPOSE/GOAL/OBJECTIVE :
The purpose of Service Operation is to coordinate and car ry out the
activities and processes required to deliver and manage services at agreed
levels to business users and customers. Service Operation is also
responsible for the ongoing management of the technology that is used to
deliver and support services. W ell-designed and well -implemented
processes will be of little value if the day -to-day operation of those
processes is not properly conducted, controlled and managed. Nor will
service improvements be possible if day -to-day activities to monitor
performance, assess metrics and gather data are not systematically
conducted during Service Operation.
7.1.2 SCOPE :
Service Operation includes the execution of all ongoing activities required
to deliver and support services. 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 : Operational a spects of all processes
whatever part of the lifecycle they originate from (e.g. operational
aspects of capacity and availability management).

 Technology : All services require some form of technology to deliver
them. Managing this technology is not a sep arate issue, but an integral munotes.in

Page 93

Service Operations And
Service Operation
Principles
93 part of the management of the services concerned with the
management of the infrastructure used to deliver services.

 People : It is people who drive the demand for the organization’s
services and products and it is people who decide how this will be
done. Ultimately, it is people who manage the technology, processes
and services.
7.1.3 VALUE TO BUSINESS :
Each stage in the ITIL Service Lifecycle provides value to business. For
example, service value is modelled in Service St rategy; the cost of the
service is designed, predicted and validated in Service Design and Service
Transition; and measures for optimization are identified in Continual
Service Improvement. The operation of service is where these plans,
designs and optimiz ations are executed and measured. From a customer
viewpoint, Service Operation is where actual value is seen.
7.1.4 OPTIMIZING SERVICE OPERATION PERFORMANCE
Service Operation is optimized in two ways:
 Long -term incremental improvement : This is based on evaluating
the performance and output of all Service Operation processes,
functions and outputs over time. The reports are analyzed and a
decision made about whether improvement is needed and, if so, how
best to implement it through Service Design and Tra nsition. Examples
include the deployment of a new set of tools, changes to process
designs, reconfiguration of the infrastructure, etc. This type of
improvement is covered in detail in the Continual Service
Improvement publication.

 Short -term ongoing impr ovement of working practices within the
Service Operation processes, functions and technology itself. These
are generally smaller improvements that are implemented without any
change to the fundamental nature of a process or technology.
Examples include tu ning, workload balancing, personnel redeployment
and training, etc. Although both of these are discussed in some detail
within the scope of Service Operation, the Continual Service
Improvement publication will provide a framework and alternatives
within wh ich improvement may be driven as part of the overall
support of business objectives.
7.2 SERVICE OPERATION PRINCIPLES
The principles are aimed at helping Service Operation practitioners to
achieve a balance between all the roles and to focus on effectively
managing the day -to-day aspects while maintaining a perspective of the
greater context. munotes.in

Page 94

IT Service
Management
94 7.2.1 FUNCTIONS, GROUPS, TEAMS, DEPARTMENTS AND
DIVISIONS:
The Service Operation uses several terms to refer to the way in which
people are organized to execute proces ses or activities. There are several
definitions for each term
 Function : A function is a logical concept that refers to the people and
automated measures that execute a defined process, an activity or a
combination of processes or activities. In larger or ganizations, a
function may be broken out and performed by several departments,
teams and groups, or it may be embodied within a single
organizational unit (e.g. Service Desk). In smaller organizations, one
person or group can perform multiple functions – e.g. a Technical
Management department could also incorporate the Service Desk
function.

 Group : A group is a number of people who are similar in some way.
In this publication, groups refer to people who perform similar
activities – even though they may w ork on different technology or
report into different organizational structures or even in different
companies. Groups are usually not formal organization structures, but
are very useful in defining common processes across the organization
– e.g. ensuring t hat all people who resolve incidents complete the
Incident Record in the same way. In this publication the term ‘group’
does not refer to a group of companies that are owned by the same
entity.

 Team : A team is a more formal type of group. These are peopl e who
work together to achieve a common objective, but not necessarily in
the same organization structure. Team members can be co -located, or
work in multiple different locations and operate virtually. Teams are
useful for collaboration, or for dealing wit h a situation of a temporary
or transitional nature. Examples of teams include project teams,
application development teams (often consisting of people from
several different business units) and incident or problem resolution
teams.

 Department : Departmen ts are formal organization structures which
exist to perform a specific set of defined activities on an ongoing basis.
Departments have a hierarchical reporting structure with managers
who are usually responsible for the execution of the activities and als o
for dayto -day management of the staff in the department.

 Division : A division refers to a number of departments that have been
grouped together, often by geography or product line. A division is
normally self -contained and is able to plan and execute a ll activities in
a supply chain. munotes.in

Page 95

Service Operations And
Service Operation
Principles
95 7.2.2 ACHIEVING BALANCE IN SERVICE OPERATION:
Service Operation is more than just the repetitive execution of a standard
set of procedures or activities. All functions, processes and activities are
designed to deliver a spe cified and agreed level of services, but they have
to be delivered in an ever -changing environment. This forms a conflict
between maintaining the status quo and adapting to changes in the
business and technological environments. One of Service Operation’s key
roles is therefore to deal with this conflict and to achieve a balance
between conflicting sets of priorities. It also provides some high -level
guidelines on how to resolve the conflict and thus move towards a best -
practice approach. Every conflict the refore represents an opportunity for
growth and improvement.
7.2.2.1 INTERNAL IT VIEW VERSUS EXTERNAL BUSINESS
VIEW :
The most fundamental conflict in all phases of the ITSM Lifecycle is
between the view of IT as a set of IT services (the external business view)
and the view of IT as a set of technology components(internal IT view).

 The external view of IT is the way in which services are experienced
by its users and customers. They do not always understand, nor do
they care about, the details of what tech nology is used to manage those
services. All they are concerned about is that the services are delivered
as required and agreed.

 The internal view of IT is the way in which IT components and
systems are managed to deliver the services. Since IT systems ar e
complex and diverse, this often means that the technology is managed
by several different teams or departments – each of which is focused
on achieving good performance and availability of ‘its’ systems. Both
views are necessary when delivering services. The organization that
focuses only on business requirements without thinking about how
they are going to deliver will end up making promises that cannot be
kept. The organization that focuses only on internal systems without
thinking about what services th ey support will end up with expensive
services that deliver little value. The potential for role conflict between
the external and internal views is the result of many variables,
including the maturity of the organization, its management culture, its
histo ry, etc. This makes a balance difficult to achieve, and most
organizations tend more towards one role than the other. Of course, no
organization will be totally internally or externally focused, but will
find itself in a position along a spectrum between t he two. munotes.in

Page 96

IT Service
Management
96


Building Service Operation with a balance between internal and external
focus requires a long -term, dedicated approach reflected in all phases of
the ITSM Service Lifecycle. This will require the following:
 An understanding of wh at services are used by the business and why.
 Anunderstanding of the relative importance and impact of those
services on the business.
 An understanding of how technology is used to provide IT services.
 Involvement of Service Operation in Continual Service Improvement
projects that aim to identify ways of delivering more, increase service
quality and lower cost.
 Procedures and manuals that outline the role of IT Operations in both
the management of technology and the delivery of IT services.
 A clearly diffe rentiated set of metrics to report to the business on the
achievement of service objectives; and to report to IT managers on the
efficiency and effectiveness of Service Operation.
 All IT Operations staff understand exactly how the performance of the
techno logy affects the delivery of IT services and in turn how these
affect the business and the business goals.
 A set of standard services delivered consistently to all Business Units
and a set of non -standard (sometimes customized) services delivered
to specif ic Business Units – together with a set of Standard Operating
Procedures ( SOPs) that can meet both sets of requirements.
 A cost strategy aimed at balancing the requirements of different
business units with the cost savings available through optimization of
existing technology or investment in new technology – and an
understanding of the cost strategy by all involved IT resources.
 A value -based, rather than cost -based, Return on Investment strategy. Figure 7.1 Achieving a balance between external and internal force
munotes.in

Page 97

Service Operations And
Service Operation
Principles
97  Involvement of IT Operations staff in the Service Design a nd
ServiceTransition phases of the ITSM Lifecycle.
 Input from and feedback to Continual Service Improvement to identify
areas where there is an imbalance and the means to identify and
enforce improvement.
 A clear communication and training plan for busines s. While many
organizations are good at developing Communication Plans for
projects, this often does not extend into their operational phase.
7.2.2.2 STABILITY VERSUS RESPONSIVENESS :
Service Operation needs to ensure that the IT Infrastructure is stable a nd
available as designed. At the same time, Service Operation needs to
recognize that business and IT requirements change. Some of these
changes are evolutionary.
In evolutionary changes, it is possible to plan how to respond to the
change and thus maintai n stability while responding to the changes.
Many changes, though, happen very quickly and sometimes under extreme
pressure. For example, a Business Unit unexpectedly wins a contract that
requires additional IT services, more capacity and faster response t imes.
The ability to respond to this type of change without impacting other
services is a significant challenge. Many IT organizations are unable to
achieve this balance and tend to focus on either the stability of the IT
Infrastructure or the ability to r espond to changes quickly.

Figure 7.2 Achieving a balance between focus on stability and responsiveness
Building an IT organization that achieves a balance between stability and
responsiveness in Service Operation will require the following actions:
 Ensu re investment in technologies and processes that are adaptive
rather than rigid, e.g. virtual server and application technology and the
use of Change Models munotes.in

Page 98

IT Service
Management
98  Build a strong Service Level Management (SLM) process which is
active from the Service Design phas e to the Continual Service
Improvement phase of the ITSM Lifecycle.
 Foster integration between SLM and the other Service Design
processes to ensure proper mapping of business requirements to IT
operational activities and components of the IT Infrastructure . This
makes it easier to model the effect of changes and improvements.
 Initiate changes at the earliest appropriate stage in the ITSM
 Lifecycle. This will ensure that both functional (business) and
manageability (IT operational) requirements can be assess ed and built
or changed together.
 Ensure IT involvement in business changes as early as possible in the
change process to ensure scalability, consistency and achievability of
IT services sustaining business changes.
 Service Operation teams should provide i nput into the ongoing design
and refinement of the architectures and IT services (see Service Design
and Service Strategy publications).
 Implement and use SLM to avoid situations where business and IT
managers and staff negotiate informal agreements.
7.2.2 .3 QUALITY OF SERVICE VERSUS COST OF SERVICE :
Service Operation is required consistently to deliver the agreed level of IT
service to its customers and users, while at the same time keeping costs
and resource utilization at an optimal level. Figure 7.3 re presents the
investment made to deliver a service at increasing levels of quality.


Figure 7.3 Balancing Service Quality and Cost
In Figure 7.3, an increase in the level of quality usually results in
an increase in the cost of that service, and vi ce versa. However, the
relationship is not always directly proportional: munotes.in

Page 99

Service Operations And
Service Operation
Principles
99  Early in the service’s lifecycle it is possible to achieve significant
increases in service quality with a relatively small amount of money. For
example, improving service availabilit y from 55% to 75% is fairly
straightforward and may not require a huge investment.
 Later in the service’s lifecycle, even small improvements in quality are
very expensive. For example, improving the same service’s availability
from 96% to 99.9% may require large investments in high -availability
technology and support staff and tools.
Achieving an optimal balance between cost and quality (shown between
the dotted lines in Figure 7.3 ) is a key role of Service Management. There
is no industry standard for what this range should be, since each service
will have a different range of optimization, depending on the nature of the
service and the type of business objective being met.
Determining the appropriate balance of cost and quality should be done
during the S ervice Strategy and Service Design Lifecycle phases, although
in many organizations it is left to the Service Operation teams – many of
whom do not generally have all the facts or authority to be able to make
this type of decision.
Service Level Requiremen ts – with a clear understanding of the business
purpose of the service and the potential risks – will help to ensure that the
service is delivered at the appropriate cost. They will also help to avoid
‘over -sizing’ of the service just because the budget is available, or ‘under -
sizing’ because the business does not understand the manageability
requirements of the solution. Either result will cause customer
dissatisfaction and even more expense when the solution is re -engineered
or retro -fitted to the require ments that should have been specified during
Service Design.



Figure7.4 Achieving a balance between focus on cost and quality
munotes.in

Page 100

IT Service
Management
100 Achieving a balance will ensure delivery of the level of service necessary
to meet business requirements at an optimal (as opp osed to lowest
possible) cost. This will require the following:
 A Financial Management process and tools that can account for the
cost of providing IT services; and which model alternative methods of
delivering services at differing levels of cost.
 Ensuri ng that decisions around cost versus quality are made by the
appropriate managers during Service Strategy and Service Design. IT
operational managers are generally not equipped to evaluate business
opportunities and should only be asked to make financial d ecisions
that are related to achieving operational efficiencies.
7.2.2.4 REACTIVE VERSUS PROACTIVE
A reactive organization is one which does not act unless it is prompted to
do so by an external driver, e.g. a new business requirement, an
application that has been developed or escalation in complaints made by
users and customers. An unfortunate reality in many organizations is the
focus on reactive management mistakenly as the sole means to ensure
services that are highly consistent and stable, actively dis couraging
proactive behaviour from operational staff. The unfortunate irony of this
approach is that discouraging effort investment in proactive Service
Management can ultimately increase the effort and cost of reactive
activities and further risk stabilit y and consistency in services.
A proactive organization is always looking for ways to improve the
current situation. It will continually scan the internal and external
environments, looking for signs of potentially impacting changes.
Proactive behaviour is usually seen as positive, especially since it enables
the organization to maintain competitive advantage in a changing
environment. However, being too proactive can be expensive and can
result in staff being distracted. The need for proper balance in reac tive and
proactive behaviour often achieves the optimal result.
From a maturity perspective, it is clear that newer organizations will have
different priorities and experiences from a more established organization –
what is best practice for a mature organ ization may not suit a younger
organization. Therefore, an imbalance could result from an organization
being either less or more mature. munotes.in

Page 101

Service Operations And
Service Operation
Principles
101

Figure 7.5 Achieving a balance between being too
reactive or too proactive
While proactive behaviour in Service Opera tion is generally good, there
are also times where reactive behaviour is needed. The role of Service
Operation is therefore to achieve a balance between being reactive and
proactive. This will require:
 Formal Problem Management and Incident Management proc esses,
integrated between Service Operation and Continual Service
Improvement.
 The ability to prioritize technical faults as well as business demands.
This needs to be done during Service Operation, but the mechanisms
need to be put in place during Service Strategy and Design stages.
These mechanisms could include incident categorization systems,
escalation procedures and tools to facilitate impact assessment for
changes.
 Data from Configuration and Asset Management to provide data
where required, saving pr ojects time and making decisions more
accurate.
 Ongoing involvement of SLM in Service Operation.
7.2.3 PROVIDING SERVICE:
All Service Operation staff must be fully aware that they are there to
‘provide service’ to the business. They must provide a timely ( rapid
response and speedy delivery of requirements), professional and courteous
service to allow the business to conduct its own activities – so that the
commercial customer’s needs are met and the business thrives.
It is important that staff are trained n ot only in how to deliver and support
IT services, but also in the manner in which that service should be
provided.
A critical element of being a proficient service provider is placing as much
emphasis on recruiting and training staff to develop competenc y in dealing
with and managing customer relationships and interactions as they do on
technical competencies for managing the IT environment. munotes.in

Page 102

IT Service
Management
102 7.2.4 OPERATION STAFF INVOLVEMENT IN SERVICE DESIGN
AND SERVICE TRANSITION:
Service Operation staff are involved in Service Design and Service
Transition and potentially also in -Service Strategy where appropriate.
One key to achieving balance in Service Operation is an effective set of
Service Design processes. These will provide IT Operations Management
with:
 Clear de finition of IT service objectives and performance criteria
 Linkage of IT service specifications to the performance of the
ITInfrastructure
 Definition of operational performance requirements
 A mapping of services and technology
 The ability to model the effe ct of changes in technology and changes
to business requirements
 Appropriate cost models (e.g. customer or service based) to evaluate
Return on Investment and cost -reduction strategies.
Service Design is a phase in the Service Management Lifecycle using a set
of processes, not a function independent of Service Operation. As such,
many of the people who are involved in Service Design will come from IT
Operations Management.
This should not only be encouraged, but Service Operation staff should be
measured on their involvement in Service Design activities – and such
activities should be included in job descriptions and roles, etc. This will
help to ensure continuity between business requirements and technology
design and operation and it will also help to ensu re that what is designed
can also be operated.
IT Operations Management staff should also be involved during Service
Transition to ensure consistency and to ensure that both stated business
and manageability requirements are met.
Resources must be made av ailable for these activities and the time
required should be taken into account, as appropriate.
7.2.5 OPERATIONAL HEALTH
The IT Infrastructure is like an organism that has vital life signs that can
be monitored to check whether it is functioning normally. This means that
it is not necessary to monitor continuously every component of every IT
system to ensure that it is functioning.
Operational Health can be determined by isolating a few important ‘vital
signs’ on devices or services that are defined as cri tical for the successful
execution of a Vital Business Function. This could be the bandwidth
utilization on a network segment, or memory utilization on a major server.
If these signs are within normal ranges, the system is healthy and does not
require addi tional attention. This reduction in the need for extensive munotes.in

Page 103

Service Operations And
Service Operation
Principles
103 monitoring will result in cost reduction and operational teams and
departments that are focused on the appropriate areas for service success.
However, as with organisms, it is important to check sy stems more
thoroughly from time to time, to check for problems that do not
immediately affect vital signs. For example, a disk may be functioning
perfectly, but it could be nearing its Mean Time Between Failures (MTBF)
threshold. In this case the system sh ould be taken out of service and given
a thorough examination or ‘health check’. At the same time, it should be
stressed that the end result should be the healthy functioning of the service
as a whole. This means that health checks on components should be
balanced against checks of the ‘end -to-end’ service.
Operational Health is dependent on the ability to prevent incidents and
problems by investing in reliable and maintainable infrastructure. This is
achieved through good availability design and proactive Problem
Management. At the same time, Operational Health is also dependent on
the ability to identify faults and localize them effectively so that they have
minimal impact on the service. This requires strong (preferably
automated) Incident and Problem Ma nagement.
The idea of Operational Health has also led to a specialized area called
‘Self -Healing Systems’. This is an application of Availability, Capacity,
Knowledge, Incident and Problem Management and refers to a system that
has been designed to withsta nd the most severe operating conditions and
to detect, diagnose and recover from most incidents and Known Errors.
Self-Healing Systems are known by different names, for example
Autonomic Systems, Adaptive Systems and Dynamic Systems.
7.2.6 COMMUNICATION:
Good communication is needed with IT teams and departments,with users
and internal customers, and between the Service Operation teams and
departments themselves. Issues can often be prevented or mitigated with
appropriate communication.
An important princi ple is that all communication must have an intended
purpose or a resultant action. Information should not be communicated
unless there is a clear audience. In addition, that audience should have
been actively involved in determining the need for that commu nication
and what they will do with the information.
Together with a description of the typical audience and the actions that are
intended to be taken as a result of each communication. These include:
 Routine operational communication
 Communication between shifts
 Performance reporting
 Communication in projects munotes.in

Page 104

IT Service
Management
104  Communication related to changes
 Communication related to exceptions
 Communication related to emergencies
 Training on new or customized processes and service designs
 Communication of strategy and des ign to Service Operation teams.
Although the typical content of communication is fairly consistent once
processes have been defined, the means of communication are changing
with every new introduction of technology. The list of alternatives is
growing and, today, includes:
 E-mail, to traditional clients or mobile devices
 SMS messages
 Pagers
 Instant messaging and web -based ‘chats’
 Voice over Internet Protocol (VoIP) utilities that can turn any
connected device to an inexpensive communication medium
 Teleconfe rence and virtual meeting utilities, have revolutionized
meetings which are now held across long distances
 Document -sharing utilities.
The following points should be noted:
 Communication is primary and the means of communication must
ensure that they serve this goal. For example, the need for secure
communication may eliminate the possibility of some of the above
means.
 The need for quality may eliminate some VoIP options.
It is possible to use any means of communication as long as all
stakeholders understa nd how and when the communication will take place.
7.2.6.1 MEETINGS:
Different organizations communicate in different ways. Where
organizations are distributed, they will tend to rely on email and
teleconferencing facilities. Organizations that have more m ature Service
Management processes and tools will tend to rely on the tools and
processes for communication (e.g. using an Incident Management tool to
escalate and track incidents, instead of requesting e -mail or telephone calls
for updates).
Other organiz ations prefer to communicate using meetings. Face -to-face
meetings tend to increase costs (e.g. travel, time spent in informal
discussions, refreshments, etc.), so meeting organizers should balance the
value of the meeting with the number and identity of t he attendees and the
time they will spend in, and getting to, the meeting.
The purpose of meetings is to communicate effectively to a group of
people about a common set of objectives or activities. Meetings should be munotes.in

Page 105

Service Operations And
Service Operation
Principles
105 well controlled and brief, and the focu s should be on facilitating action. A
good rule is not to hold a meeting if the information can be communicated
effectively by automated means.
Examples of typical meetings are given below:
7.2.6.1.1 THE OPERATIONS MEETING :
Operations meetings are normall y held between the managers of the IT
operational departments, teams or groups, at the beginning of each
business day or week. The purpose is to make staff aware of any issue
relevant to Operations (such as change schedules, business events,
maintenance sc hedules, etc.) and to provide an opportunity for staff to
raise any issues of which they are aware.
In geographically dispersed organizations it may not be possible to have a
single daily Operations meeting. In these cases, it is important to
coordinate t he agenda of the meetings and to ensure that each meeting has
two components:
a. The first part of the meeting will cover aspects that apply to the
organization as a whole, e.g. new policies, changes that affect all
regions and business events that span all r egions.
b. The second part of the meeting will cover aspects thatapply only to the
local region, e.g. local operations schedules, changes to local
equipment, etc.
The Operations meeting is usually chaired by the IT Operations Manager
or a senior Operations Ma nager and attended by all managers and
supervisors
7.2.6.1.2 DEPARTMENT, GROUP OR TEAM MEETINGS :
These meetings are the same as the Operations meeting, but are aimed at a
single IT department, group or team. Each manager or supervisor relays
the informat ion from the Operations meeting that is relevant to their team.
In addition, these meetings will also cover the following:
 A more detailed discussion of incidents, problems and changes that are
still being worked on, with information about:
– Progress to dat e
– Confirmation of what still needs to be done
– Estimatedcompletion times
– Request for additional resources, if required
– Discussion of potential problems or concerns
 Confirmation of staff availability for roster duties
 Confirmation of vacation schedules.
7.2.6.1.3 CUSTOMER MEETINGS :
It will be necessary to hold meetings from time to time with customers ,
apart from the regular Service Level Review meetings.Examples include: munotes.in

Page 106

IT Service
Management
106  Follow -up after serious incidents. The purpose is to repair the
relationship with the customers, but also to ensure that IT has all the
information required to prevent recurrence. Such meetings are helpful
in agreeing actions for similar types of incidents that may occur in
future.

 A customer forum, can be used for a range of purposes like testing
ideas for new services or solutions, or gathering requirements for new
or revised services or procedures. It is a regular meeting with
customers to discuss areas of common concern.
7.2.7 DOCUMENTATION :
IT Operations Management and all of the Techn ical and Application
Management teams and departments are involved in creating and
maintaining a range of documents. It includes the following:
 Participation in the definition and maintenance of process manuals for
all processes they are involved in. These will include processes in
other phases of theIT Service Management Lifecycle (e.g. Capacity
Management, Change Management, Availability Management) as well
as for all processes included in the Service Operation phase.

 Establishing their own technical pro cedures manuals. These must be
kept up to date and new material must be added as it becomes relevant,
under Change Control. The procedures should always be structured to
meet the objectives and constraints defined within higher -level Service
Management pro cesses, such as SLM.

 Participation in the creation and maintenance of planning documents,
e.g. the Capacity and Availability Plans and the IT Service Continuity
Plans.

 Participation in the creation and maintenance of the Service Portfolio.
This will inc lude quantifying costs and establishing the operational
feasibility of each proposed service.

 Participation in the definition and maintenance of Service
Management tool work instructions in order to meet reporting
requirements.

7.3 SUMMARY

In this Chapt ers we have learned the objective and fundamentals of
Service Operations its Purpose/goal/objective, Scope, Value to business,
Optimizing Service Operation performance and different principles of
Service Operation like Functions, Group, Teams, Departments and
Divisions, Achieving Balance in Service Operations based on Internal IT
view versus external business view, Stability versus responsiveness, munotes.in

Page 107

Service Operations And
Service Operation
Principles
107 Quality of service versus cost of service & Reactive versus proactive,
Providing Service ,
Operation Staff inv olvement in Service Design and Service Transition,
Operational Health, Commun ication involves Meetings like Operational
meeting, Department al, group or team meetings and Customer meetings
and based on it preparation of Documentation .

7.4 QUESTIONS

Q1. Define Service operation. Explain the principles of service operation
stage.
Q2. How to achieve balance in service operation stage.
Q3. Write short note on operational health in service operation.
Q4. Why communication is important at service operation stage?
Q5. What is diff erent type of meetings conducted in organization as
mode of communication?
Q6. Explain department, group and team meetings.
Q7. How operations meetings are different from customer meetings?
Q8. State reasons why service operation staff should be involved at
service design and transition stage?
Q9. Elaborate the term Providing Service in context of service
operationstage.
Q10. Explain in detail about Documentation in service operation stage.

7.5 REFERENCES

 ITIL V3 Foundation Complete Certification Kit
 Foundation of IT Serv ice Management - The Unofficial ITIL V3
Foundation Course by Brady Orand, 2nd Edition
 ITIL V3 Service Operation by OGC/TSO


munotes.in

Page 108

108 8
SERVICE OPERATION PROCESSES,
CHALLENGES, CRITICAL SUCCESS
FACTORS AND RISKS
Unit Structure:
8.0 Objective
8.1 Service Operation Processes
8.1.1 Event Management
8.1.2 Incident Management
8.1.3 Request Fulfilment
8.1.4 Problem Management
8.1.5 Access M anagement
8.1.6 Operational Activities of Processes covered in
other Lifecycle Phases
8.2 Challenges, Critical Success Factors and Risks
8.2.1 Challenges
8.2.2 Critical Success Factors
8.2.3 Risks
8.3 Summary
8.4 Questions
8.5 References
8.0 OBJECTIVE
After studying this chapter, you will be able:
 To Understand the basic fundamentals of service operation stage
 To explain all the processes executed at service operation and
processes need to be coordinated with at other stages of ITSM life
cycle
 To unde rstand and handle the challenges at services operation stage.
 To know critical success factors and risks.

munotes.in

Page 109

Service Operation Processes,
Challenges, Crit ical Success
Factors And Risks
109 8.1 SERVICE OPERATION PROCESSES
 Event Management is the process that monitors all events that occur
through the IT Infrastructure to allow for norma l operation and also to
detect and escalate exception conditions.

 Incident Management concentrates on restoring the service to users
as quickly as possible, in order to minimize business impact.

 Problem Management involves root -cause analysis to determ ine and
resolve the cause of events and incidents, proactive activities to detect
and prevent future problems/incidents and a Known Error sub -process
to allow quicker diagnosis and resolution if further incidents do occur.

 Request Fulfilment involves the management of customer or user
requests that are not generated as an incident from an unexpected
service delay or disruption.

 Access Management : this is the process of granting authorized users
the right to use a service, while restricting access to non -authorized
users.
SERVICE OPERATION TERMS :
 Incident – Unplanned Interruption in the Quality of Service or the
failure of a CI (even if the failure did not impact a service)
 Alert – A warning that some threshold has been reached (May or may
not constitute an “incident”)
 Event – An Automated detectable occurrence of significance
 Service Request – A user request for information or advice
 Problem – An unknown underlying cause of an incident
 Known Error – A problem that has a documented root cause and a
workar ound
 Known Error Database (KEDB) - The place Problems and Work
Around are documented.
 Work Around – Means of reducing or eliminating the impact of an
incident for which no permanent solution is available.
 Impact, Urgency, Priority – Priority determines t he order on the
daily operation. Priority is a combination of Impact and Urgency.
Impact + Urgency = Priority.
munotes.in

Page 110

IT Service
Management
110 8.1.1 EVENT MANAGEMENT :
Event is defined as detectable occurrence that has significance for the
delivery of IT service. Event Management ensure s that all CIs are
constantly monitored and define a process to categorize these events so
that appropriate action can be taken if required.
Why to have event management?
 Events are typically notifications created by an IT service,
configuration item or m onitoring tool
 Effective service operation is dependent on knowing the status of the
infrastructure and detecting any deviation from normal or expected
operation. This is provided by good monitoring and control systems,
which are based on two types of too ls:
- Active monitoring tools that poll key configuration items to
determine their status and availability. Any expectations will generate
an alert that needs to be communicated to the appropriate tool or team
for action
- Passive monitoring tools that detec t and correlate operational alerts or
communications generated by configuration items.
8.1.1.1 PURPOSE/ GOAL/ OBJECTIVE :
The purpose of event management is
To manage events throughout their life cycle. This life cycle includes
coordinationactivities to d etect events. Make sense of them and determine
the appropriate control action.
The objectives of event management
 To provide the entry point for the execution of many service operation
processes and activities. In addition, it provides a way of comparing
actual performance and behaviour against design standards and
Service Level Agreements.
8.1.1.2 SCOPE :
Event Management can be applied to any aspect of Service Management
that needs tobe controlled and which can be automated. These include :
 Configurat ion Items:
o Some CIs will be included because they need to stay in a constant state
(e.g. a switch on a network needs to stay on and Event Management
tools confirm this by monitoring responses to ‘pings’).
Some CIs will be included because their statu s needs to change frequently
and Event Management can be used to automate this and update the CMS
(e.g. the updating of a file server). munotes.in

Page 111

Service Operation Processes,
Challenges, Crit ical Success
Factors And Risks
111  Environmental conditions (e.g. fire and smoke detection)
 Software licence monitoring for usage to ensure optimum/lega l licence
utilization and allocation
 Security (e.g. intrusion detection)
 Normal activity (e.g. tracking the use of an application or
the performance of a server).























Figure 8.1 The Event Management process
8.1.1.2.1 SIGNIFICANCE OF EVENTS :
Every organization has its own categorization of the significance of an
event, but threebroad categories are as follows:
 Informational: this refers to an event that does not require any action
and does not represent an exception. They are typic ally stored in the
system or service log files and kept for a predetermined period
 Warning: a warning is an event that is generated when a service or
device is approaching a threshold warning are intended to notify the
appropriate person, process or tool so that the situation can be
checked and appropriate action taken to avoid an exception .
munotes.in

Page 112

IT Service
Management
112  Exception: an exception means that a service or device is currently
operating abnormally. Typically, this means that an Operating Level
Agreement or Service Level Agre ement has been breached and the
business has been impacted. Exceptions could represent a total
failure, impaired functionality or degraded performance.
8.1.1.2.2 EVENT CORRELATION :
If an event is significant, a decision has to be made about exactly what t he
significance is and what actions need to be taken to deal with it. It is here
that the meaning of the event is determined.
Correlation is done by a ‘Correlation Engine’, i.e. part of a management
tool that compares the event with a set of criteria and rules in a prescribed
order.
A Correlation Engine is programmed according to the performance
standards created during Service Design and any additional guidance
specific to the operating environment.
8.1.1.2.3 TRIGGER :
If the correlation activity reco gnizes an event, a response will be required.
The mechanism used to initiate that response is called a trigger. There are
different types of triggers, each designed specifically for the task it has to
initiate. Some examples include:
 Incident Triggers that generate a record in the Incident Management
system, thus initiating the Incident Management process
 Change Triggers that generate a Request for Change (RFC), thus
initiating the Change Management process
 Paging systems that will notify a person o r team of the event by
mobile phone
 Database triggers that restrict access of a user to specific records or
fields, or that create or delete entries in the database.
8.1.1.2.4 RESPONSE SELECTION
The response options can be chosen in any combination. There are a
number of response options available.
 Event logged: There will be a record of the event and any subsequent
actions. The event can be logged as an Event Record in the Event
Management tool. munotes.in

Page 113

Service Operation Processes,
Challenges, Crit ical Success
Factors And Risks
113  Auto response: S ome events are understood well enough that the
appropriate response has already been defined and automated. The
trigger will initiate the action. Examples of auto responses include:
rebooting a device, restarting a service, locking a device or application
to protect it against unauthorised acc ess.
 Alert a nd human intervention: The purpose of the alert is to ensure
that the person with the skills appropriate to deal with the event is
notified. The alert will contain all the information necessary for the
person to determine the appropriate action . E.g. changing a toner
cartridge in a printer when the level is low.
 Incident, problem or change : Some events will represent a situation
where the appropriate response will need to be handled through the
Incident, Problem or Change Management process. Sometimes a
single incident may initiate any one or a combination of these three
processes – for instance, a non -critical server failure is logged as an
incident, but as there is no workaround, a Problem Record is created to
determine the root cause and re solution and an RFC is logged to
relocate the workload onto an alternative server while the problem is
resolved.
 Open an RFC: There are two places in the Event Management
process where an RFC can be created:
 When an exception occurs
 Correlation identi fies that a change is needed
 Open an Incident Record: as with a request for change an incident
can be created as soon as an exception is detected, or when the
correlation engine determines that a specific type or combination of
events represents an inciden t. When an Incident Record is opened, all
possible information should be included – with links to the concerned
events and a completed diagnostic script.
 Open or link to a Problem Record: It is rare for a problem record to
be opened without related inci dents. In most cases this step refers to
linking an incident to an existing problem record.
 Special types of incidents: In some cases, an event will indicate an
exception that does not directly impact any IT service, for example, a
redundant air condition ing unit fails, or unauthorized entry to a data
centre.

munotes.in

Page 114

IT Service
Management
114 8.1.1.2.5 REVIEW ACTIONS :
With thousands of events being generated every day, it is not possible to
review every individual event. However, it is important to check that any
significant events or exceptions have been handled appropriately, or to
track trends or counts of event types, etc. In many cases this can be done
automatically, for instance, polling a server that had been rebooted using
an automated script to see that it is functioning corre ctly. The Review will
also be used as input into continual improvement and the evaluation and
audit of the Event Management process.
8.1.1.2.6 CLOSE EVENT :
Some events will remain open until a certain action takes place, for
example an event that is li nked to an open incident. However, most events
are not ‘opened’ or ‘closed’.
Informational events are simply logged and then used as input to other
processes, such as Backup and Storage Management. Auto -response
events will be closed by the generation of a second event. For instance, a
device generates an event and is rebooted through auto response – as soon
as that device is successfully back online, it generates an event that
effectively closes the loop and clears the first event.
In the case of event s that generated an incident, problem or change, these
should be formally closed with a link to the appropriate record from the
other process.
8.1.2 INCIDENT MANAGEMENT
In ITIL terminology, an ‘incident’ is defined as: An unplanned
interruption to an IT service. Failure of a configuration item that has not
yet impacted service is also an incident, for example failure of one disk
from a mirror set.
Incident Management is the process for dealing with all incidents; this can
include failures, questions or queries reported by the users
Why to have incident management?
 Incident management is highly visible to the organization, and it is
therefore easier to demonstrate its value than in most areas of service
operation.
 For this reason, incident management is often one of the first processes
to be implemented in service management projects. munotes.in

Page 115

Service Operation Processes,
Challenges, Crit ical Success
Factors And Risks
115  The added benefit of doing this is that incident management can be
used to highlight other areas that need attention, thereby providing a
justification for implementing other ITIL processes
8.1.2.1 PURPOSE/GOAL/OBJECTIVE :
The purpose of Incident Management is to restore the service to the
previous stage as early as possible
The primary goal and objective of the Incident Management process is
to restore normal service ope ration as quickly as possible and minimize
the adverse impact on business operations, thus ensuring that the best
possible levels of service quality and availability are maintained.
8.1.2.2 SCOPE :
Incident Management includes any event which disrupts, or which could
disrupt, a service. This includes events which are communicated directly
by users, either through the Service Desk or through an interface from
Event Management to Incident Management tools.
Incidents can also be reported and/or logged by te chnical staff, for
instance, technical staff notice something untoward with a hardware or
network component they may report or log an incident and refer it to the
Service Desk. This does not mean, that all events are incidents.
8.1.2.3 VALUE TO BUSINESS :
The value of Incident Management includes:
 The ability to detect and resolve incidents which results in lower
downtime to the business, which in turn means higher availability of
the service.
 The ability to align IT activity to real -time business priori ties.
 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
staff.
 The Service Desk can, during its h andling of incidents, identify
additional service or training requirements found in IT or the business.
8.1.2.4 PROCESS ACTIVITIES, METHODS AND TECHNIQUES :
The process to be followed during the management of an incident is
shown in Figure 8.2. The proc ess includes the following steps. munotes.in

Page 116

IT Service
Management
116 8.1.2.4.1 INCIDENT IDENTIFICATION :
Work cannot begin on dealing with an incident until it is known that an
incident has occurred. It is usually unacceptable, from a business
perspective, to wait until a user is impacted and contacts the Service Desk.
All key components should be monitored so that potential failures are
detected early to quickly start the Incident Management process.

































Figure 8.2 Incident Management process flow
munotes.in

Page 117

Service Operation Processes,
Challenges, Crit ical Success
Factors And Risks
117
8.1.2.4. 2 INCIDENT LOGGING :
All incidents must be fully logged and date/time stamped, regardless of
whether they are raised through a Service Desk telephone call or whether
automatically detected via an event alert. The information needed for each
incident is li kely to include:
 Unique reference number
 Incident categorization (often broken down into between two and four
levels of sub -categories)
 Incident urgency, impact &prioritization
 Date/time recorded
 Name/ID of the person and/or group recording t he incident
 Method of notification (telephone, automatic, e -mail, in person, etc.)
 Name/department/phone/location of user
 Call-back method (telephone, mail, etc.)
 Description of symptoms
 Incident status (active, waiting, closed, etc.)
 Related CI
 Support group/person to which the incident is allocated
 Related problem/Known Error
 Activities undertaken to resolve the incident
 Resolution date and time
 Closure category & Closure date and time.
8.1.2.4.3 INCIDENT CATEGORIZATION :
The initial logging must be to allocate suitable incident categorization
coding so that the exact type of the call is recorded. This will be important
later when looking at incident types/frequencies to establish trends for use
in Problem Management, Su pplier Management and other ITSM activities.
For instance, an incident may be categorized as shown in Figure 8.3. munotes.in

Page 118

IT Service
Management
118











Figure 8.3 Multi -level incident categorization
All organizations are unique and it is difficult to give generic guidance on
the categories an organization should use, particularly at the lower levels.
However, there is a technique that can be used to assist an organization to
achieve a correct and complete set of categories
8.1.2.4.4 INCIDENT PRIORITIZATION :
Prioritization can normally be determined by taking into account both the
urgency of the incident and the level of impact it is causing. An indication
of impact is often the number of users being affected. 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 is not enough
to evaluate overall priority! Other factors that can also contribute to
impact levels are:
 Risk to life or limb
 The number of services affected – may be mul tiple services
 The level of financial losses
 Effect on business reputation
 Regulatory or legislative breaches.
An effective way of calculating these elements and deriving an overall
priority level for each incident is given in Table 8.1:

munotes.in

Page 119

Service Operation Processes,
Challenges, Crit ical Success
Factors And Risks
119 Impact
High Medium Low
High 1 2 3
Urgency Medium 2 3 4
Low 3 4 5

Table 8.1 Simple priority coding system
8.1.2.4.5 INITIAL DIAGNOSIS :
If the incident has been routed via the Service Desk, initial diagnosis must
be carried out by the Service Desk Analyst while the user is still on the
telephone – if the call is raised – to try 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.
8.1.2.4.6 INCIDENT ESCALATION :
Functional escalation, as soon as it becomes clear that the Service Desk is
unable to resolve the incident itself the incident must be immediately
escalated for further support. Priority Code Description Target resolution time
1 Critical 1 hour
2 High 8 hours
3 Medium 24 hours
4 Low 48 hours
5 Planning Planned
munotes.in

Page 120

IT Service
Management
120
8.1.2.4.7 INVESTIGATION AND DIAGNOSIS :
Investigation is likely to includ e following actions as:
 Establishing exactly what has gone wrong or being sought by the user
 Understanding the chronological order of events
 Confirming the full impact of the incident, including the number and
range of users affected
 Identifying any events that could have triggered the incident (e.g. a
recent change, some user action?)
 Knowledge searches looking for previous occurrences by searching
previous Incident/Problem Records and/or Known
 Error Databases or manufacturers’/suppliers’ Er ror Logs or
Knowledge Databases.
8.1.2.4.8 RESOLUTION AND RECOVERY :
Resolve the incident using the solution/work around or, alternatively, raise
a request for change (RFC) (including a check for resolution) and Take
recovery actions. The resolving grou p should pass the incident back to the
Service Desk for closure action.
8.1.2.4.9 INCIDENT CLOSURE :
The Service Desk should check that the incident is fully resolved and that
the users are satisfied and willing to agree the incident can be closed.
The Service Desk should also check the following:
 Closure categorization. Check and confirm that the initial
incident categorization
 User satisfaction survey. Carry out a user satisfaction
callback or e -mail survey for the agreed percentage of
incidents.
 Incident documentation. ensure that the Incident Record
is fully documented
 Ongoing or recurring problem ? Determine whether it is
likely that the incident could recur and decide whether any
preventive action is necessary to avoid this.
 Formal closure. Formally close the Incident Record

8.1.3 REQUEST FULFILMENT
This process deals with handling requests such as change password, create
new user and create email id etc. munotes.in

Page 121

Service Operation Processes,
Challenges, Crit ical Success
Factors And Risks
121 Why to have request fulfilment?
 Request fulfilment is the process for dealing with s ervice requests via
the Service Desk, using a process similar but separate to that of
incident management.
 Request fulfilment records/tables are linked, where necessary, to the
incident or problem record(s) that initiated the need for the request.
 For a service request , it is normal for some prerequisites to be defined
and met (e.g. needs to be proven, repeatable, pre -approved and
documented as a procedure).
 These are viewed as standard changes – procurement, HR and other
business units may assist/be invo lved
8.1.3.1 PURPOSE/GOAL/OBJECTIVE
Request Fulfilment is the processes of dealing with Service Requests from
the users. The objectives of the Request Fulfilment process include:
 To provide a channel for users to request and receive standard services
for which a pre -defined approval and qualification process exists
 To provide information to users and customers about the availability of
services and the procedure for obtaining them
 To source and deliver the components of requested standard service s
 (e.g. licences and software media)
 To assist with general information, complaints or comments.
8.1.3.2 SCOPE :
The process needed to fulfil a request will vary depending upon exactly
what is being requested – but can usually be broken down into a set of
activities that have to be performed.
Requests can be handled through the incident management processes (and
tools) – with service requests being handled as a particular type of incident
(using a high -level categorization system to identify servic e requests).
However, there is a significant difference – an incident is an unplanned
event whereas a service request is usually something that can and should
be planned.

munotes.in

Page 122

IT Service
Management
122 8.1.3.3 VALUE TO BUSINESS :
The value of Request Fulfilment is to provide quick an d effective access to
standard services which business staff can use to improve their
productivity or quality of business services and products.
It reduces the bureaucracy involved in requesting and receiving access to
existing or new services, thereby r educing the cost of providing these
services.
8.1.3.4 PROCESS ACTIVITIES, METHODS AND TECHNIQUES :
8.1.3.4.1 MENU SELECTION -
Request Fulfilment offers great opportunities for self -help practices where
users can generate a Service Request using technology that links into
Service Management tools. Ideally, users should be offered a ‘menu’ -type
selection via a web interface, so that they can select and input details of
Service Requests from a pre -defined list.
8.1.3.4.2 FINANCIAL APPROVAL -
 One important step that is likely to be needed when dealing with a
service request is that of financial approval.

 Most requests will have some form of financial implication, regardless
of the type of commercial arrangements in place.

 The cost of fulfilling the request m ust first be established. It may be
possible to agree fixed prices for standard requests – and prior
approval for such requests may be given as part of the organisation’s
overall annual financial management.

 In all other cases, an estimate of the cost mus t be produced and
submitted to the user for financial approval.

 If approval is given, in addition to fulfilling the request, the process
must also include charging for the work done – if charging is in place.
8.1.3.4.3 OTHER APPROVAL -
In some cases, furt her approval may be needed – such as compliance
related or wider business approval. Request Fulfilment must have the
ability to define and check such approvals where needed. munotes.in

Page 123

Service Operation Processes,
Challenges, Crit ical Success
Factors And Risks
123 8.1.3.4.4 FULFILMENT -
The actual fulfilment activity will depend upon the natur e of the Service
Request. Some simpler requests may be completed by the Service Desk,
acting as firstline support, while others will have to be forwarded to
specialist groups and/or suppliers for fulfilment.
The Service Desk should monitor and chase prog ress and keep users
informed throughout, regardless of the actual fulfilment source.
8.1.3.4.5 CLOSURE -
When the service request has been fulfilled it must be referred back to the
Service Desk for closure – the Service Desk will check that the user is
satisfied with the outcome.
8.1.4 PROBLEM MANAGEMENT:
ITIL defines a ‘problem’ as the cause of one or more incidents. This
process deals with finding root cause of the problem and prevent incident
to occur again.
Why to have problem management?
 Failure t o halt the recurrence of incidents or understand the root cause
of major incidents leads to lost time, loss of productivity and frustrated
users.
 Effective problem management halts the recurrence of incidents and
has benefits to the individual and the org anisation as a whole as it
improves availability (up time) and user productivity.
8.1.4.1 PURPOSE/GOAL/OBJECTIVE :
The objective of problem management is to minimise the adverse impact
of incidents and problems on the business that are caused by errors wit hin
the IT infrastructure, and to prevent recurrence of incidents related to these
errors.
8.1.4.2 SCOPE :
Problem management includes the activities required to diagnose the root
cause of incidents and to determine the resolution to the problems.
It is a lso responsible for ensuring that the resolution is implemented
through the appropriate control procedures (change management).
Problem management will also maintain information about problems and
the appropriate work arounds and resolutions. munotes.in

Page 124

IT Service
Management
124 8.1.4.3 VALU E TO BUSINESS
Problem Management works together with Incident Management and
Change Management to ensure that IT service availability and quality are
increased. When incidents are resolved, information about the resolution is
recorded. Over time, this in formation is used to speed up the resolution
time and identify permanent solutions, reducing the number and resolution
time of incidents. This results in less downtime and less disruption to
business -critical systems.
8.1.4.4 PROCESS ACTIVITIES, METHODS AND TECHNIQUES
Problem Management consists of two major processes:
 Reactive Problem Management , which is executed as part of Service
Operation – Concerned with solving problems in response to one or
more incidents
 Proactive Problem Management which is i nitiated in Service
Operation, but generally driven as part of Continual Service
Improvement.
The Problem Management process is shown in Figure 8.4.
8.1.4.4.1 REACTIVE ACTIVITIES
The reactive activities are:
 Problem detection and problem logging
- Use i ncident guidelines for problem identification
- Other processes (e.g. availability, security) could log problems prior to
incident occurring
 Problem categorization and prioritization
- Categorize the problem by IT functional area
- Assess urgency and impact t o assign priority
 Problem investigation and diagnosis
- Assign to IT functional area for further investigation

 Workarounds and raising a known error record –
- In cases where a work around is found, it is important that the problem
record remains open, and details of the work around are documented
within the problem record munotes.in

Page 125

Service Operation Processes,
Challenges, Crit ical Success
Factors And Risks
125 - As soon as the diagnosis is complete, and particularly where a work
around has been found (even though it may not be a permanent
resolution), a known error record must be raised and place d in the
Known Error Database, so that, if further incidents or problems arise,
they can be identified and the service restored more quickly

 Problem resolution
- Problem record closed when known error located and work around
identified

 Problem closure
- Problem record closed when known error located and
work around identified
























Figure 8.4 Problem Management process flow
8.1.4.4.2 PROACTIVE ACTIVITIES :
The proactive activities are:
 Major problem review and errors detected in the de velopment
environment
munotes.in

Page 126

IT Service
Management
126 After every major problem, and while memories are still fresh, a review
should be conducted to learn any lessons for the future. The review should
examine:
- Those things that were done correctly
- Those things that were done wrongly
- What could be done better in the future
- How to prevent recurrence
- Whether there has been any third -party responsibility and whether
follow up actions are needed
8.1.4.4.3 MAJOR PROBLEM REVIEW :
Such reviews can be used as part of training and awareness ac tivities for
staff – any lessons learned should be documented in appropriate
procedures, working instructions, diagnostic scripts or known error
records.
- Tracking and monitoring
The Service Desk Manager owns/is accountable for ALL incidents.
Tracking and monitoring takes place throughout all of the other activities.
- Trend analysis
Review reports from other processes (e.g. incident management,
availability management, change management) and Identify recurring
problems or training opportunities.
- Targeting p reventative action
Perform a cost benefit analysis of all costs associated with prevention.
Target specific areas taking up most attention.
8.1.5 ACCESS MANAGEMENT:
This process deals with granting rights to authorized user to use the
service. Access Manag ement deals with granting access to authorized
access while preventing access to non -authorized users. Access Manager
is the process owner of this process.
Why to have access management?
Access management is the process of granting authorized users the ri ght to
use a service, while preventing access to non -authorized users. It is,
therefore, the execution of policies and actions defined in information
security and availability management

munotes.in

Page 127

Service Operation Processes,
Challenges, Crit ical Success
Factors And Risks
127 8.1.5.1 PURPOSE/GOAL/OBJECTIVE :
The objectives of access managemen t
 Protecting Confidentiality, Integrity and Availability (CIA), sometimes
known as Rights Management or Identity Management (removing
access when people change roles or jobs and regularly auditing access
permissions to ensure they are correct)
 Security i ncidents and problems related to access management will be
discreetly recorded
8.1.5.2 SCOPE :
Access Management is effectively the execution of both Availability and
Information Security Management, in that it enables the organization to
manage the confi dentiality, availability and integrity of the organization’s
data and intellectual property.
Access Management ensures that users are given the right to use a service,
but it does not ensure that this access is available at all agreed times – this
is pro vided by Availability Management.
8.1.5.3 VALUE TO BUSINESS :
Access Management provides the following value:
 Controlled access to services ensures that the organization is able to
maintain more effectively the confidentiality of its information
 Employees have the right level of access to execute their jobs
effectively
 There is less likelihood of errors being made in data entry or in the use
of a critical service by an unskilled user (e.g. production control
systems)
 The ability to audit use o f services and to trace the abuse of services
 The ability more easily to revoke access rights when needed – an
important security consideration
8.1.5.4 BASIC CONCEPTS :
Access Management is the process that enables users to use the services
that are documented in the Service Catalogue. It comprises the following
basic concepts:
 Access refers to the level and extent of a service’s functionality or data
that a user is entitled to use.
 Identity refers to the information about them that distinguishes them
as an individual and which verifies their status within the organization.
By definition, the Identity of a user is unique to that user. munotes.in

Page 128

IT Service
Management
128  Rights (also called privileges) refer to the actual settings whereby a
user is provided access to a service or gr oup of services, include read,
write, execute, change, delete.
 Services or service groups are group of users – access to the whole
set of services that they are entitled to use at the same time.
 Directory Services refers to a specific type of tool tha t is used to
manage access and rights.
8.1.5.5 PROCESS ACTIVITIES, METHODS AND TECHNIQUES :
8.1.5.5.1 REQUESTING ACCESS :
Access (or restriction) can be requested using one of any number of
mechanisms, including:
 A standard request generated by the Huma n Resource system.,
whenever a person is hired, promoted, transferred or when they leave
the company
 A Request for Change
 A Service Request submitted via the Request Fulfilment system
 By executing a pre -authorized script or option (e.g. downloadin g an
application from a staging server as and when it is needed).
Rules for requesting access are normally documented as part of the
Service Catalogue.
8.1.5.5.2 VERIFICATION
Access Management needs to verify every request for access to an IT
servic e from two perspectives:
 First, the user requesting access is who they say they are, it can be
achieved by the user providing their username and password.
 Second, that they have a legitimate requirement for that service. This
require some independent ve rification, other than the user’s request.
8.1.5.5.3 PROVIDING RIGHTS
 Access Management does not decide who has access to which IT
services. Rather, it executes the policies and regulations defined during
Service Strategy and Service Design. Access Mana gement enforces
decisions to restrict or provide access, rather than making the decision.
munotes.in

Page 129

Service Operation Processes,
Challenges, Crit ical Success
Factors And Risks
129 8.1.5.5.4 MONITORING IDENTITY STATUS
 As users work in the organization, their roles change as do their needs
to access services, e.g. job changes, promotions/dem otions, resignation
or death.
 Access management should understand and document the typical user
lifecycle for each type of user and use it to automate the process.
 Access management tools should provide features that enable a user to
be moved from one sta te to another easily and with an audit trail.
8.1.5.5.5 LOGGING AND TRACKING ACCESS
 Access management should not only respond to requests. It is also
responsible for ensuring that the rights that have been provided are
being properly used.
 Information s ecurity management plays a vital role in detecting
unauthorized access and comparing it with the rights that were
provided by access management.
 Access management may also be required to provide a record of
access for specific services during forensic inv estigations.
8.1.5.5.6 REMOVING OR RESTRICTING RIGHTS
Just as Access Management provides rights to use a Service, it is also
responsible for revoking those rights. Again, this is not a decision that it
makes on its own. Rather, it will execute the decis ions and policies made
during Service Strategy and Design and also decisions made by managers
in the organization. Removing access is usually done in the following
circumstances:
 Death
 Resignation
 Dismissal
 When the user has changed roles and n o longer requires access to the
service
 Transfer or travel to an area where different regional access applies.
8.1.6 OPERATIONAL ACTIVITIES OF PROCESSES COVERED
IN OTHER LIFECYCLE PHASES:
8.1.6.1 CHANGE MANAGEMENT :
Change Management is primarily covered in the Service Transition stage,
but there are some aspects of Change Management which Service
Operation staff will be involved with on a day -to-day basis. Like raising munotes.in

Page 130

IT Service
Management
130 and submitting RFCs as needed to address Service Operation issues,
implementing changes as directed by Change Management where they
involve Service Operation component or services etc.
8.1.6.2 CONFIGURATION MANAGEMENT :
Configuration Management is primarily covered in the Service Transition
stage, but Service Operation staff will be involve d on a day -to-day basis.
These include:
 Informing Configuration Management of any discrepancies found
between any CIs and the CMS
 Making any amendments necessary to correct any discrepancies, under
the authority of Configuration Management, where they involve any
Service Operation components or services.
8.1.6.3 RELEASE AND DEPLOYMENT MANAGEMENT :
Release and Deployment Management is primarily covered in the Service
Transition stage, but Service Operation staff will be involved with on a
day-to-day basis. These may include:
 Actual implementation actions regarding the deployment of new
releases, under the direction of Release and Deployment Management,
where they relate to Service Operation components or services
 Participation in the planning sta ges of major new releases to advise on
Service Operation issues
 The physical handling of CIs as required to fulfil their operational
roles
8.1.6.4 CAPACITY MANAGEMENT :
Capacity Management should operate at three levels:
 Business Capacity Managemen t involves working with the business
to plan and anticipate both longer -term strategic issues and shorter -
term tactical initiatives that are likely to have an impact on IT
capacity.
 Service Capacity Management is about understanding the
characteristics of each of the IT services, and then the demands that
different types of users or transactions have on the underlying
infrastructure
munotes.in

Page 131

Service Operation Processes,
Challenges, Crit ical Success
Factors And Risks
131  Resource Capacity Management involves understanding the
performance characteristics and capabilities and current utilizat ion
levels of all the technical components (CIs) that make up the IT
Infrastructure, and predicting the impact of any changes or trends.
8.1.6.5 DEMAND MANAGEMENT :
This process maintains balance between consumption of services and their
delivery. There are other aspects of Demand Management that are of a
more operational nature, requiring shorterterm action.
8.1.6.6 WORKLOAD MANAGEMENT :
Sometimes optimization of infrastructure resources is needed to maintain
or improve performance. This can be done through Workload
Management, which is a generic term to cover such actions as:
 Rescheduling a particular service or workload to run at a different time
of day
 Moving a service or workload from one location or set of CIs to
another
 Technical Virtualizati on: setting up and using virtualization systems to
allow movement of processing around the infrastructure to give better
performance/resilience in a dynamic fashion.
 Limiting or moving demand for resources through Demand
Management techniques.
8.1.6.7 M ODELLING AND APPLICATIONS SIZING :
Modelling and/or sizing of new services and/or applications mustbe done
during the planning and transition phases –the Service Operation functions
have a role to play in evaluating the accuracy of the predictions and
feeding back any issues or discrepancies.
8.1.6.8 CAPACITY PLANNING :
During Service Design and Service Transition, the capacity requirements
of IT services are calculated. Service operation will ensure to maintain,
update and review the capacity plan regula rly
8.1.6.9 AVAILABILITY MANAGEMENT :
During Service Design and Service Transition, IT services are designed
for availability and recovery. Service Operation is responsible for actually
making the IT service available to the specified users at the required time
and at the agreed levels. munotes.in

Page 132

IT Service
Management
132 8.1.6.10 KNOWLEDGE MANAGEMENT :
It is vitally important that all data and information that can be useful for
future Service Operation activities are properly gathered, stored and
assessed. Key repositories of Service Opera tion, which have been
frequently mentioned elsewhere, are the CMS and the KEDB, but this
must be widened out to include all of the Service Operation teams’ and
departments’ documentation, such as operations manuals, procedures
manuals, work instructions, e tc.
8.1.6.11 FINANCIAL MANAGEMENT FOR IT SERVICES :
Service Operation staff must participate in and support the overall IT
budgeting and accounting system – and may be actively involved in any
charging system that may be in place. The Service Operation Ma nager
must also be involved in regular, at least monthly, reviews of expenditure
against budgets – as part of the ongoing IT budgeting and accounting
process. Discrepancies must be identified and necessary adjustments
made.
8.1.6.12 IT SERVICE CONTINUITY M ANAGEMENT :
Service Operation functions are responsible for the testing and execution
of system and service recovery plans as determined in the IT Service
Continuity Plans for the organization. In addition, managers of all Service
Operation functions mus t be on the Business Continuity Central
Coordination team.
8.2 CHALLENGES, CRI TICAL SUCCESS FACTORS
AND RISKS
8.2.1 CHALLENGES :
There are a number of challenges faced within Service Operation that need
to be overcome. These include
8.2.1.1 LACK OF EN GAGEMENT WITH DEVELOPMENT &
PROJECT STAFF :
Traditionally, there has been a separation between Service Operation staff
and those staff involved in developing new applications or running
projects that will eventually deliver new functionality into the ope rational
environment.
ITSM is seen as something that has been initiated in the operational areas
and is nothing to do with development or projects. munotes.in

Page 133

Service Operation Processes,
Challenges, Crit ical Success
Factors And Risks
133 8.2.1.2 JUSTIFYING FUNDING :
It is often difficult to justify expenditure in the area of Service Operati on,
as money spent in this sphere is often regarded as ‘infrastructure costs’ –
with nothing new to show for the investment.
8.2.1.3 CHALLENGES FOR SERVICE OPERATION
MANAGERS :
The following is a list of some of the challenges that Managers i n Service
Operation should expect to face.
The differences between Design activities and Operational activities will
continue to present challenges. This is for a number of reasons, including
the following.
 Service Design may tend to focus on an individ ual service at a time,
whereas Service Operation tends to focus on delivering and supporting
all services at the same time.
 Service Design will often be conducted in projects, while Service
Operation focuses on ongoing, repeatable management processes and
activities.
 Service Transition that is not used effectively to manage the transition
between the Design and Operation phases.
These challenges can only be dealt with if Service Operation staff are
involved in Service Design and Transition.
8.2.2 CRITI CAL SUCCESS FACTORS :
8.2.2.1 MANAGEMENT SUPPORT :
Senior and Middle Management support is needed for all ITSM activities
and processes, particularly in -Service Operation.
They should also be fully informed of the dire results that can occur
because of poor Service Operation. Senior Management must provide
visible support during the launch of new Service Operation initiatives and
their ongoing support must be equally well demonstrated.
8.2.2.2 BUSINESS SUPPORT :
It is important that the Business Units a lso support Service Operation. It is
equally important that the Business Units understand, accept and carry out
the role they play in Service Operation. Good service requires good
customers. munotes.in

Page 134

IT Service
Management
134 8.2.2.3 CHAMPIONS :
The champions may be senior managers who are leading from the top. But
champions can also be successful if they come from other tiers of the
organization.
Champions emerge over time, they cannot be created or appointed. It is
important to recognize that the highly motivated staff often voluntarily
take on the greatest workloads. They should be given a chance to work as
the champion.
8.2.2.4 STAFFING AND RETENTION :
Having the appropriate number of staff with the appropriate skills is
critical to the success of Service Operation. Some challenges tha t need to
be overcome include the following.
 Projects for new services are about specifying required new skills, but
often underestimate the number of staff required and how to retain the
new skills.
 Scarcity of resources who have a good understanding of Service
Management. Having good technical people is necessary, but there
needs to be a number of key people who are able to move between
technology issues and service issues.
 Since these resources are fairly scarce it is quite common to train
them, only to have them resign and join another company for a better
salary. Clear career paths and good incentives should be part of every
Service Management initiative.
 Attempting to assign too much, too soon, to existing staff. Achieving
efficient Service Operation will take time, but if approached correctly
it will be achieved.
8.2.2.5 SERVICE MANAGEMENT TRAINING :
Adequate training and awareness can have much wider overall benefits.
Training required for successful Service Management includes:
 Traini ng IT staff on the processes that have been implemented.
 Training on ‘soft’ or ‘people’ skills, especially for those staff in
customerfacing positions
 Training about understanding the business, and the importance of
achieving a service culture
 Train ing on how to use and manage tools
 Also, customers and users need appropriate training on how to work
with IT – access services, request changes, submit requests, use tools,
etc. munotes.in

Page 135

Service Operation Processes,
Challenges, Crit ical Success
Factors And Risks
135 8.2.2.6 SUITABLE TOOLS :
Many Service Operation processes and activitie s cannot be performed
effectively without adequate support tools. Senior management must
ensure that funding for such tools is included in ongoing budgets and
support their procurement, deployment and ongoing maintenance.
8.2.2.7 VALIDITY OF TESTING :
The quality of IT services that can be provided in Service Operation is
dependent upon the quality of systems and components delivered into the
operational environment.
The quality level will be enhanced if adequate and complete testing of new
components a nd releases is carried out in good time. Documentation
should also be tested for completeness and quality. This requires a
comprehensive and realistic testing environment to be in place for all
systems/components. There should be independent testers wher ever
possible.
8.2.2.8 MEASUREMENT AND REPORTING :
A clear definition is needed of how things will be measured and reported
so that all staff have clear targets to aim for and IT and Business Managers
are able to quickly and easily review progress and pin point any areas for
attention.
8.2.3 RISKS :
Failure to meet the challenges already described in section 9.1 or to
address the Critical Success Factors outlined in section 9.2 are obvious
risks – but others are described as set out below.
8.2.3.1 SERV ICE LOSS :
The ultimate risk to the business of weaknesses in Service Operation is the
loss of critical IT services with subsequent adverse impact on its
employees, customers and finances. In extreme cases there may be
potential loss to life and limb where the IT services affected are used for
critical health or safety purposes – such as emergency vehicle deployment
or health scanning, etc.


munotes.in

Page 136

IT Service
Management
136 8.2.3.2 RISKS TO SUCCESSFUL SERVICE OPERATION :
The risks to achieving successful Service Operation are numerous – and in
many cases are the opposite of the Critical Success Factors as described
earlier – but also include:
 Inadequate funding and resources: Funding must be justified,
allocated and held in reserve for its original purpose.
 Loss of momentum: mechan isms should be in place to ensure that the
initiative survives organizational changes.
 Loss of key personnel: Sometimes the loss of one or two key
personnel can have a severe impact: to minimize this effect,
organizations should seek to cross -train sta ff and reduce dependencies
upon individuals.
 Resistance to change: Sometimes people object to new things and are
reluctant to take them on board. Education, training, communication
and highlighting benefits will help.
 Lack of management support: This o ften occursamong Middle
Managers who may not see the overall vision or gain the hands -on
benefits that more junior staff may gain.
 Differing customer expectations. While operational staff are
encouraged to execute against standards, customer and user
expectations sometimes differ. In other cases, one customer may have
paid more for a superior service, but when a user from a different area
sees the superior service, they feel cheated. This problem should be
resolved through clear SLM and careful communica tion during
Service Design. Complaints should be taken up through Continual
Service Improvement processes.
8.3 SUMMARY
In this Chapters we have learned different types of Service Operation
Processes like Event Management, Incident Management, Request
Fulfi lment, Problem Management and Access Management. Operational
Activities of Processes covered in other Lifecycle Phases like Challenges,
Critical Success Factors and Risks.
8.4 QUESTIONS

1) Describe the objectives of service operation phase.
2) Define Event. Why we need Event management process?
3) Explain different types of events.
4) List and explain all activities carried in Event management process
5) Explain purpose, objectives and scope of event management.
6) Explain in detail the Incident Management Process munotes.in

Page 137

Service Operation Processes,
Challenges, Crit ical Success
Factors And Risks
137 7) Explain o bjective and scope of Incident management process.
8) Write short note on Incident Management Lifecycle activities.
9) Explain why to have incident management. How it will add value to
business?
10) State and explain all activities carried out in incident management
process.
11) Explain Request Fulfilment process.
12) Explain objectives and scope of Request Fulfilment process.
13) Write a short note on activities of Request Fulfilment process.
14) Explain why to have Request Fulfilment Process. How it will add
value to business?
15) Define the following terms: (a) Alert (b) Known Error (c)
Workaround (d) Problem (e) Priority
16) What checks to be made while closing Incident at incident Closure
stage?
17) Explain Problem management in detail.
18) Explain objectives and scope of Problem management.
19) Explain in detail access management process.
20) Define objective and scope of access management process.
21) Explain any three basic concepts of access management.
22) Explain any three operational activities of processes covered in
other Lifecycle phases
23) List and ex plain the challenges in service operation phase.
24) List and explain the critical success factors in service operation
phase.
25) List and explain the risks involved in service operation phase.
8.5 REFERENCES

 ITIL V3 Foundation Complete Certification Kit
 Foundat ion of IT Service Management - The Unofficial ITIL V3
Foundation Course by Brady Orand, 2nd Edition
 ITIL V3 Service Operation by OGC/TSO
 munotes.in

Page 138

138 9
CONTINUAL SERVICE IMPROVEMENT
PRINCIPLES, CSI PROCESSES, CSI METHODS AND TECHNIQUES
Unit Structure:
9.0 Objective
9.1 Continual Service Improvement (CSI) Principles:
9.1.1 CSI Approach
9.1.2 CSI and organizational change
9.1.3 Ownership
9.1.4 CSI register
9.1.5 External and Internal drivers
9.1.6 Service level management
9.1.7 Knowledge management
9.1.8 The Deming cycle
9.1.9 Service Measurement
9.1.10 IT governance
9.1.11 Frameworks, models standards and quality Syst ems
9.1.12 CSI inputs and outputs
9.2 Continual Service Improvement (CSI) Process:
9.2.1 The seven -step improvement process
9.3 CSI Methods and Techniques:
9.3.1 Methods and techniques
9.3.2 Assessments
9.3.3 Benchmarking
9.3.4 Service Measurement
9.3.5 Metrics
9.3.6 Return on Investment munotes.in

Page 139

Continual Service
Improvement Principles,
CSI Processes, CSI
Methods and Techniques
139 9.3.7 Service reporting
9.3.8 CSI and other service management processes
9.4 Organising for CSI:
9.4.1 Organisational development
9.4.2 Functions, Roles
9.4.3 Customer Engagement
9.4.4 Responsibility model – RACI
9.4.5 Competence and training.
9.5 Summary
9.6 Questions
9.7 References
9.0 OBJECTIVES
 Service improvement must focus on increasing the efficiency,
maximizing the effectiveness, and to optimize the cost of services and
the underlying ITSM processes.
 The only w ay to do this is to ensure that opportunities for
improvement are identified throughout the entire service lifecycle.
 This chapter will go into more detail on this. What do you measure
and where do you find information? These are two especially
important questions and should not be ignored or taken lightly.
 To ensure consistency of execution and effective measurement,
especially for the activities of gathering and processing data, the
techniques and methodologies used should be clearly documented in
advan ce and communicated to the staff that will be responsible for
their execution.
9.1 CONTINUAL SERVICE IMPROVEMENT (CSI)
PRINCIPLES
9.1.1 Continual Service Improvement (CSI) Approach :
The primary purpose of CSI is to continually align and realign IT service s
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 Servi ce Operation. In
effect, CSI is about looking for ways to improve process effectiveness,
efficiency as well as cost effectiveness. The improvement process can be
summarized in six steps: munotes.in

Page 140

IT Service
Management
140  Embrace the vision by understanding the high -level business
objective s. The vision should align the business and IT strategies.
 Assess the current situation to obtain an accurate, unbiased
snapshot of where the organization is right now. This baseline
assessment is an analysis of the current position in terms of the
busines s, organization, people, process and technology.
 Understand and agree on the priorities for improvement based on a
deeper development of the principles defined in the vision. The full
vision may be years away, but this step provides specific goals and
a ma nageable timeframe.
 Detail the CSI plan to achieve higher quality service provision by
implementing ITSM processes.
 Verify that measurements and metrics are in place to ensure that
milestones were achieved, processes compliance is high, and
business object ives and priorities were met by the level of service.
 Finally, the process should ensure that the momentum for quality
improvement is maintained by assuring that changes become
embedded in the organization.
9.1.2 CSI and organizational change :
Improvement in the service management is to embark upon an
organizational change programme. Many organizational change programs
fail to achieve the desired results. Successful ITSM requires an
understanding the way in which work is done and putting in place a
program me of change within the IT organization. This type of change is,
by its very nature, prone to difficulties. It involves people and the way
they work. People in general do not like to change; the benefits must be
explained to everyone to gain their support and to ensure that they break
out of old working practices. Those responsible for managing and steering
organizational change should consciously address these softer issues.
Using methods such as John P. Kotter’s Eight Steps To Transforming Your
Organizatio n, coupled with formalized project management skills and
practices, will significantly increase the chance of success.
9.1.3 Ownership :
The principle of ownership is fundamental to any improvement strategy.
CSI is a best practice and one of the keys to s uccessful implementation is
to ensure that a specific manager, a CSI manager, is responsible for
ensuring the best practice is adopted and sustained throughout the
organization. The CSI manager becomes the CSI owner and chief
advocate. The CSI owner is acc ountable for the success of Continual
Service Improvement in the organization. This ownership responsibility
extends beyond ensuring the CSI practices are embedded in the
organization but also to ensuring there are adequate resources (including
people and technology) to support and enable CSI. munotes.in

Page 141

Continual Service
Improvement Principles,
CSI Processes, CSI
Methods and Techniques
141 9.1.4 CSI register :
It is likely that several initiatives or possibilities for improvement are
identified. It is recommended that a CSI register is kept to record all the
improvement opportunities and that each one should be categorized into
small, medium or large undertakings.
Additionally, they should be categorized into initiatives that can be
achieved quickly or in the medium term or longer term. Each
improvement initiative should also show the benefits that will be achieved
by its implementation. With this information a clear prioritized list can be
produced.
One failing that has been observed is when something has been identified
as a lower priority. It never makes its way higher up the list for a further
consid eration, thus automated raising of priorities over time may be a
useful addition to the register.
The CSI register contains important information for the overall service
provider and should be held and regarded as part of the service knowledge
management s ystem (SKMS).
The CSI register will introduce a structure and visibility to CSI ensuring
that all initiatives are captured and recorded, and benefits realized.
Additionally, the benefits will be measured to show that they have given
the desired results.
In forecasting the benefits of each proposed improvement, we should also
try to quantify the benefit in terms of aspirational key performance
indicator (KPI) metrics. This will assist in prioritizing those changes that
deliver the most significant incrementa l benefit to the business.
The CSI register provides a coordinated, consistent view of the potentially
numerous improvement activities. It is important to define the interface
from the CSI register of initiatives with strategic initiatives and with
process es such as problem management, capacity management and change
management.
The service review meeting is likely to result in a number of requirements
for improvement. The CSI manager should have accountability and
responsibility for the production and maint enance of the CSI register.
9.1.5 External and Internal drivers :
There are two major areas within every organization driving improvement:
aspects which are external to the organization such as regulation,
legislation, competition, external customer requir ements, market pressures
and economics; and, secondly, aspects which are internal to the
organization such as organizational structures, culture, capacity to accept
change, existing and projected staffing levels, unions rules, etc. In some
cases, these asp ects may serve to hinder improvement rather than drive it
forward. A SWOT analysis (Strengths, Weaknesses, Opportunities, munotes.in

Page 142

IT Service
Management
142 Threats), may be helpful in revealing significant opportunities for
improvement. The strengths and weaknesses concentrate on the inter nal
aspects of the organization while the opportunities and threats focus on
aspects external to the organization.
9.1.6 Service Level management :
Adopting the Service Level Management (SLM) process is a key principle
of CSI. While in the past many IT or ganizations viewed SLM as merely a
smattering of isolated agreements around system availability or help desk
calls this is no longer true. SLM is no longer optional. Today’s business
demands that IT be driven by the service model. Today IT is a core
enable r of every critical business process. IT can no longer afford to
operate as the ‘geeks in the basement’ but rather must strive to be included
in every channel of communication and level of decision making all the
way to the boardroom. SLM involves several steps:
 Fully accepting that the IT organization must become a service
provider to the business or cease to be relevant.

 Involving the company and to determine their service level
requirements.

 Defining the internal portfolio of services: services that are planned, in
development, in production. Such a service portfolio also contains
modular or component services which will make up a finished service
package.

 Defining a customer -facing Service Catalogue that details every
service and service package off ered by IT with options, parameters,
and pricing.

 Identifying existing contractual relationships with external suppliers.
Verifying that these Underpinning Contracts (UCs) meet the revised
business requirements. Renegotiating them, if necessary.

 Utilizi ng the Service Catalogue as well as with the baseline, negotiate
Service Level Agreements (SLAs) with the business.

 Create a Service Improvement Plan (SIP) to continuously monitor and
improve the levels of service.
9.1.7 Knowledge Management :
Knowledge Management plays a key role in CSI. Within each service
lifecycle phase, data should be captured to enable knowledge gain and an
understanding of what is happening, thus enabling wisdom. This is often
referred to as the DIKW (Data, Information, Knowledge, and Wisdom)
model. See Figure 9.1 . All too often an organization will capture the
appropriate data but fail to process the data into information, synthesize
the information in knowledge and then combine that knowledge with
others to bring us wisdom. Wisdo m will lead us to better decisions around
improvement. munotes.in

Page 143

Continual Service
Improvement Principles,
CSI Processes, CSI
Methods and Techniques
143

Figure 9.1 Continual Service Improvement Model
9.1.8 The Deming cycle :
W. Edwards Deming is best known for his management phi losophy
leading to higher quality, increased productivity, and a more competitive
position. As part of this philosophy, he formulated 14 points of attention
for managers. Some of these points are more appropriate to service
management than others. Quality development he proposed the Deming
Cycle or Circle. This cycle is particularly applicable in CSI.
The four key stages of the cycle are Plan, Do, Check and Act , after
which a phase of consolidation prevents the circle from rolling back down
the hill. Our g oal in using the Deming Cycle is steady, continuous
improvement. It is a fundamental tenet of Continual Service Improvement.
The Deming Cycle is critical in two points in CSI: implementation of
CSIs, and for the application of CSI to services and service management
processes. At implementation, all four stages of the Deming Cycle are
used. With ongoing improvement, CSI draws on the check and act stages
to monitor, measure, review and implement proposals. The cycle is
underpinned by a process -led approach t o management where defined
processes are in place, the tasks are measured for compliance to expected
values and outputs are audited to validate and improve the process.
9.1.9 Service Measurement :
9.1.9.1 Baselines
An important beginning point for highl ighting improvement is to establish
baselines as markers or starting points for later comparison. Baselines are
also used to establish an initial data point to determine if a service or
process needs to be improved. Standard values must be established at e ach
level: strategic goals and objectives, tactical process maturity, and
operational metrics and KPIs. munotes.in

Page 144

IT Service
Management
144

Fig 9.2 Service Management
9.1.9.2 Value to Business
Basically, there are fo ur reasons to monitor and measure:
 To validate – monitoring and measuring in order to verify previous
decisions.

 To direct – monitoring and measuring set to the guidance for activities
to meet set targets. It is the most prevalent reason for monitoring a nd
measuring.

 To justify – monitoring and measuring to justify, in conjunction with
factual evidence or proof, that a course of action is required

 To intervene – monitoring and measuring to help identify a point of
intervention including subsequent chan ges and corrective actions.
The four basic reasons to monitor and measure lead to three key questions:
‘Why are we monitoring and measuring?’, ‘When do we stop?’ and ‘Is
anyone using the data?’ Responding to these questions, it is important to
identify wh ich of the above reasons is driving the quantity effort. Too
often, we continue to measure long after the need has passed. Every time
you produce a report you should ask: ‘Do we still need this?’
9.1.10 IT governance
Governance has been around the IT stag e for decades. The mainframe had
significant controls built around its day -today operations. With the advent
of distributed processing in the early 90s, then n -tier processing, the
internet, and increasing virtualization, governance and controls simply
went out of fashion; just when they were the most desperately needed.
With the exposure of high -level corporate scams in the early years of this
century, IT was thrust, without warning, into acompletely unfamiliargame
with incredibly high stakes. Administrati on is back with a vengeance. IT is
now forced to comply with sweeping legislation and an ever -increasing
number of external regulations. munotes.in

Page 145

Continual Service
Improvement Principles,
CSI Processes, CSI
Methods and Techniques
145 9.1.11 Frameworks, Models, Standards, and Quality Systems
9.1.11.1 Frameworks
ITIL, created in 1989, provides detailed guidance on the structure,
integration and improvement of IT services and manufacturing processes.
It has been updated and revised and is governed by the Office of
Government Commerce, UK. It is the most widespread set of principles
for IT Service Managem ent worldwide.
COBIT (Control Objectives for Information and related Technology),
originally created in 1995 as the information structures audit framework,
and has matured to become an overall IT management framework.
COBIT processes and principles are o ften used by IT and SOX auditors.
COBIT is governed by the IT Governance Institute. PMBOK (Project
Management Body of Knowledge) is owned and authored by the Project
Management Institute (PMI). PRINCE2 (PRojects IN Controlled
Environments, v2) is a structu red project management method owned by
the OGC. Structured project management means managing the project in a
logical, organized way following defined steps. A structured project
management method is the written description of this logical, organized
appro ach. Individuals can receive qualifications confirming their
knowledge of each framework.
Organizations may be assessed against a regulatory framework. In many
cases the Capability Maturity Model (CMM) scale is used for these
organizational assessments.
9.1.11.2 CMMI (Capability Maturity Model Integration):
Created by SEI (Software Engineering Institute) at Carnegie Mellon
University in 1991. In the beginning CMM was a model for demonstrating
the reliability of software development processes in the belief that more
mature development processes led to better software. The basic software
CMM model has grown and been revised.
CMMI is now the de facto standard for assessing a maturity of any
process. Organizations can be assessed against the CMMI model using
SCAMPI (Standard CMMI Appraisal Method for Process Improvement).
9.1.11.3 Standards and quality Systems :
Standards exist because a widely recognized governing body, in most
cases a governing body with worldwide scope, has agreed on a specific set
of prin ciples or protocols and has published them for everyone to use.
Standards are usually set by committees working under various trade and
international organizations. The most important standards applying to the
world of ITSM are:
 ISO/IEC 20000:2005 promote s the adoption of an integrated process
approach to effectively deliver managed services to meet business and
customer requirements. An agency to function effectively it must munotes.in

Page 146

IT Service
Management
146 identify and manage numerous linked activities. Coordinated
integration and imple mentation of the service management processes
provides the ongoing control, increased efficiency, and opportunities
for continual improvement. (ISO).

 ISO/IEC 27001:2005 covers all types of organizations and specifies
the requirements for establishing, im plementing, operating,
monitoring, reviewing, maintaining, and improving a documented
Information Security Management System within the context of the
organization’s overall business risks.

 ISO/IEC 15504 (also known as SPICE – Software Process
Improvemen t and Capability determination) provides a framework for
the assessment of process capability. This structure can be used by
organizations involved in planning, managing, monitoring, controlling,
and improving the acquisition, supply, development, function ing,
evolution and support of products and services.

 ISO/IEC 19770:2006 has been established to enable an organization
to prove that it is performing software asset management (SAM) to a
standard sufficient to satisfy corporate governance requirements an d
ensure effective support for IT service management overall. ISO/IEC
19770:2006 is intended to align closely to, and to support, ISO/IEC
20000.
9.1.11.4 Quality Systems :
‘Six Sigma’ was pioneered at Motorola in 1986 and was originally defined
as a metri c for measuring defects and improving quality, and a
methodology to decrease the defect levels below six standard deviations or
six sigma.
The fundamental objective of the Six Sigma methodology is the
implementation of a measurement -based strategy that fo cuses on process
improvement and variation reduction through the implementation of Six
Sigma improvement projects. This is accomplished using two Six Sigma
sub-methodologies: DMAIC and DMADV. The Six Sigma DMAIC
process is an enhancement system for existin g processes falling below
specification and looking for incremental improvement.
The Six Sigma DMADV process (define, measure, analyse, design, verify)
is an improvement system used to develop new processes or products at
Six Sigma quality levels. It can also be employed if a current process
requires more than just a piecemeal improvement. Both Six Sigma
processes are executed by individuals who have been certified as Six
Sigma Green Belts and Six Sigma Black Belts and are overseen by Six
Sigma Master Blac k Belts.
‘Lean manufacturing’ or ‘lean production’ has been pioneered by Toyota
in the mid -1980s. It is a quality system built around these five principles: munotes.in

Page 147

Continual Service
Improvement Principles,
CSI Processes, CSI
Methods and Techniques
147  Specify value from the standpoint of the end customer.

 Identify all the steps in the value curr ent for each product family,
eliminating every step and every action and every practice that
does not create value.

 Make the remaining value -creating steps happen in a tight and
integrated sequence so the product will flow smoothly toward the
customer.

 As flow is introduced, let the customers pull value from the next
upstream activity.

 As these steps lead to greater transparency, enabling managers and
teams to eliminate further waste, pursue perfection through
continual improvement.

9.1.12 CSI inputs and o utputs:
Table 9.1 below provides a summary of the major inputs and outputs
between each stage of the service lifecycle

Table 9.1 CSI Inputs and Outputs munotes.in

Page 148

IT Service
Management
148 9.2 CONTINUAL SERVICE IMPROVEMENT (CSI)
PROCESS
9.2.1 CSI Process: The seven -step improvement process: -
The seven -step improvement process: -
Fundamental to CSI is the concept of measurement. CSI uses the 7 -Step
Improvement Process shown in Figure 9.4 It is obvious that all the
activities of the improvement process will assist CSI in some way. It is
relativ ely simple to identify what takes places, but the difficulty lies in
understanding exactly how this will happen. The improvement procedure
spans not only the management organization but the entire service
lifecycle. This is a cornerstone of CSI.
The 7 -Step Improvement Process
1. Define what you should measure: At the onset of the service lifecycle,
Service Strategy and Service Design should have identified this
information. CSI can then start its cycle all again at ‘Where are we now?’
This identifies the ideal situation for both the Business and IT.
2. Define what you can measure: This activity related to the CSI
activities of ‘Where do we want to be?’ By identifying the new service
level requirements of the business, the IT capabilities and the available
budgets, CSI can conduct a gap analysis to identify the opportunities for
improvement as well as answering the question ‘How do we get there?’
3. Gathering the data: To properly answer the ‘Did we get there?’
question, data must first be gathered (usuall y through Service Operations).
Data is gathered based on goals and objectives identified. At this point the
data is raw and no conclusions are drawn.
4. Processing the data: Here the data is processed in alignment with the
CSFs and KPIs specified. This me ans that timeframes are coordinated,
unaligned data is rationalized and made consistent, and deficiencies in
data are identified. The simple goal of this step is to process data from
multiple disparate sources into an ‘apples to apples’ comparison.
5. Analysing the data: Here the data becomes information as it is
analysed to identify service gaps, trends, and the impact on business. It is
the analysing step that is most often overlooked or forgotten in the rush to
present data to management.
6. Presenting and using the information: Here the answer to ‘Did we get
there?’ is formatted and communicated in any way necessary to present to
the various stakeholders an accurate picture of the results of the
improvement efforts.
7. Implementing corrective action: The knowledge gained is used to
optimize, improve, and correct services. Managers identify problems and
present solutions. The corrective actions that need to be taken to improve munotes.in

Page 149

Continual Service
Improvement Principles,
CSI Processes, CSI
Methods and Techniques
149 the service are communicated and explained to the organization.
Following thi s step, the organization establishes a new baseline, and cycle
begins anew.

Fig: 9.3 Knowledge Spiral – a gathering activity
9.3 CSI METHODS AND TECHNIQUES
9.3.1 CSI Methods and Techniques: -
A wide var iety of methods and techniques can be used in the CSI activities
ranging from ‘soft and vague’ to ‘factual and scientific’ often providing
either both or a mixture of quality and quantity measurement results.
To ensure consistency of execution and the eff ective measurement,
especially for the activities of gathering and processing data, the
techniques and methods that are used should be clearly documented in
advance and communicated to the staff that will be responsible for their
execution.
A goal -oriente d attitude, professional experience and education of the
individuals are required.
Effort and Cost
CSI improvement activities can require a considerable amount of effort
and money for larger -scale projects to improve to minimal time and effort
for some i ncremental improvements. Possible major cost topics are:
Labour cost – Salaries of the organization’s staff who are involved in
implementing the measurement structure or who spend effort on
performing one of the activities in operating or maintaining the
measurement framework; including costs associated with managing it. If munotes.in

Page 150

IT Service
Management
150 (part of) IT is outsourced, outside provider costs should be included here
too.
Tooling cost – Purchase, licenses, installation and configuration,
maintenance costs of computer hardwar e, software and other equipment
specifically used for the measurement activities.
Training cost – Cost of training and mentoring staff in the use of
measurement methods, techniques, tools and procedures.
Expertise cost – Payments to hired experts and con sulting firms, typically
for the planning, implementation and maintenance activities pertaining to
the measurement framework. Includes also out -of-pocket costs of
acquiring information used in the measurement framework that is not in
the possession of the organization itself such as benchmarking data.
Implementation of the measurement framework, initially and if it
changes – In practice these types of costs can be reliably estimated and
controlled by using a project -oriented approach.
Operation – The leve l of costs associated with the operation of the
measurement framework is largely fixed because of the way it is designed
and equipped.
Maintenance – The level of these types of costs depends mainly on the
expected rate at which the measurement framework w ill require adaptation
to changing conditions and on the quality of its implementation.
9.3.1.1 Implementation Review and Evaluation: -
Implementation review and evaluation is key to determining the
effectiveness of a CSI improvement programme. Some common areas for
review include:
 Were we correct in our evaluation of the current situation and in
defining the problem statement?
 When defining the goals for improving IT services did, we commit to
the right goals?
 When developing our strategy for improving the use and management
of IT services, did we make good decisions and take the right
decisions?
 In the new situation, whether we have improved the provision of IT
services?
 And finally, what are the lessons learned and ... where are we now?
Review and ev aluation of a CSI initiative fall within two broad
categories: munotes.in

Page 151

Continual Service
Improvement Principles,
CSI Processes, CSI
Methods and Techniques
151  Issues closely tied to the original problem situation with respect to the
IT service provision to the business and subsequent business aims and
strategy for the improvement thereof
 Issues in relation to the planning, implementation and proceedings of
the IT improvement in the program itself and associated projects such
as measurements, problems, actions and changes.
The issues in the first category are closely related to the characteristics o f
the original problem situation which instigated the actions for
understanding and improvements and will therefore include:
 Ability of IT service to satisfy business needs
 Business satisfaction with the service provision
 Business benefits in the region of productivity, effectiveness,
efficiency and economy
 Degree of understanding and supervision of the management of the IT
infrastructure and IT service provision on the part of the business.
For the second category the following issues should be review ed and
evaluated:
 Costs of staff involved in the improvement schedule and costs of
implementing and maintaining the measurement framework.
 Project management like planning, performance, timeliness of
achieving results and milestones, amount of re -planning .
 Communication, information gathering, reporting.
9.3.2 Assessments: -
Assessments are the formal mechanisms for comparing the operational
process environment to performance standards for the purpose of
measuring improved process capability and/or to ide ntify potential
shortcomings that could be addressed. Organizations need to be more than
just involved in an assessment; they must be committed to improvement.
The initial step in the assessment process is to choose (or define) the
maturity model and in t urn the maturity attributes to be measured at each
level. A suggested approach is to turn to the best practice frameworks such
as CMMI, COBIT, ISO/IEC 20000 or the process maturity framework.
These frameworks define maturity models directly or model can be
inferred. The frameworks are also useful in the definition of process
maturity attributes.
9.3.2.1 When to assess
Assessments can be conducted at any given time. A way to think about
assessment timing is in line with the improvement lifecycle: munotes.in

Page 152

IT Service
Management
152  Plan (pr oject initiation) – Assess the targeted processes at the
inception of process introduction to form the basis for a process
improvement project. Processes may be of many configurations and
design which increases the complexity of assessment data collection.
 Plan (project midstream) – A check during process implementation
or improvement activities serves as validation that process project
objectives are being met and, most importantly, provide tangible
evidence that benefits are being achieved from the inves tment of time,
talent, and resources to process initiatives.
 Do/Check (process in place) – Upon conclusion of a process project,
it is important to validate the maturation of process and the process
organization through the efforts of the project team. In addition to
serving as a decisive conclusion for a project, planning for periodic
reassessments can support overall organizational integration and
quality efforts.
9.3.2.2 What to assess and how: -
The assessment’s scope is one of the key decisions. Scope should be based
on the assessment’s objective and anticipated future use of process
assessments and assessment reports. There are three potential scope levels:
 Process only – Assessment only of process attributes based on the
general principles and the g uidelines of the process framework which
defines the subject process.
 People, process and technology – Extend the process assessment to
include assessment of the skills, roles and talents of the managers and
practitioners of the process as well as the abi lity of the process -
enabling technology deployed to support the objectives and transaction
state of the process.
 Full assessment – Extend the people, process and technology
assessment to include an assessment of the culture of acceptance
within the organ ization, the ability of the organization to articulate a
process strategy, the definition of a vision for the process environment
as an ‘end state’, the structure and function of the process
organization, the ability of process governance to assure that pr ocess
objectives and goals are met, the business/IT alignment via a process
framework, the effectiveness of process reporting/metrics, and the
capability and capacity of decision -making practices to improve
processes over time. munotes.in

Page 153

Continual Service
Improvement Principles,
CSI Processes, CSI
Methods and Techniques
153

Table 9.2: -Assessment Res ources
9.3.2.3 Advantages and disadvantages of assessments: -
The advantages include:
 They can provide an objective perspective of the current operational
process state compared to a standard maturity model and a process
framework. Through a thorough asses sment, an accurate determination
of any process gaps can be rapidly completed, recommendations put
forward and action steps planned.
 Using a common or universally accepted maturity framework, applied
to a standard process framework, may serve to support c omparing
company process maturity to industry benchmarks.
The disadvantages include:
 An assessment provides only a snapshot in time of the process
environment. As such it does not reflect current economic activity or
cultural dynamics and process operati onal issues.
 Assessments are labor -intensive efforts. Resources are needed to
conduct the assessments beyond those responding such as process or
tool practitioners, management, and others.
 Assessments attempt to be as objective as possible in terms of
measurements and evaluation factors, but when all is said and done
assessment results are still subject to opinion of assessors.
9.3.3 Benchmarking: -
In management, and particularly strategic management, benchmarking is a
technique whereby firms assess seve ral facets of their operations in
comparison to best practise, typically within their own industry. This then
enables businesses to create plans for implementing such best practises,
typically with the intention of enhancing some area of performance. It wi ll
be necessary to: munotes.in

Page 154

IT Service
Management
154  Ensure top management support.
 Take an external view – Bringing together the business intelligence
and internal performance to draw conclusions about the way internal
resources and processes must be improved to accomplish and surpass
the performance of others.
 Involve process owners – Their involvement encourages acceptance
and buy -in by those that will be affected immediately by the changes
which will be required to improve performance.
 Set up benchmarking teams – As the benchmarkin g culture develops,
people will apply the method as part of the normal way in which they
manage their work.
 Acquire the skills – People who commit to benchmarking require a
small amount of training and guidance; an experienced in -house
facilitator or exte rnal consultant will be required to provide technical
assurance and encouragement to in the application of the method.
9.3.3.1 BenchmarkingProcedure: -
Identify your problem zones. Because benchmarking can be applied to any
business process or function, a range of research techniques may be
required. They include:
 Informal conversations with customers, employees, or suppliers
 Focus groups
 In-depth marketing research
 Quantitative research
 Questionnaires
 Re-engineering analysis
 Process mapping
 Quality control variance reports
 Financial ratio analysis.
 Benchmarking Costs
9.3.3.2 Benchmarking is a moderately expensive process, but most
organizations find that it more than pays for itself. The three main
types of costs are:
Visit costs – This includes travel - and subsistence -related expenses for
team members who need to travel to the site. munotes.in

Page 155

Continual Service
Improvement Principles,
CSI Processes, CSI
Methods and Techniques
155 Time costs – Members of the comparative assessment team will be
investing time in researching problems, finding exceptional companies to
study, visits and implement ation.
Benchmarking database costs – Organizations that institutionalize
benchmarking into their daily procedures find it is useful to create and
maintain a database of best practices and companies associated with each
best practice.
Value of Benchmarkin g
The results of benchmarking and self -assessments lead to identification of
gaps in terms of people, processes, and technologies. A benchmark can be
the catalyst to initiating prioritization of where to begin formal process
improvement. To summarize, a b enchmark is the basis for:
Profiling quality in the market
Boosting self -confidence and pride in employees as well as motivating and
tying employees to an organization. This is significant with today’s staff
shortages in the IT industry – IT personnel wa nt to work in a highly
efficient, cutting -edge environment
Trust from customers that the organization is a good IT service
management provider.
9.3.3.3 Benefits: -
Using benchmark results will help provide major benefits in:
 Achieving economy in the form of lower prices and higher
productivity on the part of the service provider.
 Achieving efficiency by examining the costs of providing IT services
and the contribution these services make to the business with what is
achieved in other organizations. This h elps the organization in order to
identify areas for improvement.
 Achieving efficiency in terms of actual business objectives realized
compared with what was planned.
 Benchmarking helps the organization to focus on strategic planning by
identifying the re lative effectiveness of IT support for the businessTo
obtain the maximum benefit, it is necessary to look at all of these three
areas, rather than focusing on one to the exclusion of the others.
9.3.3.4 Who is involved?
Within an organization there will be three parties involved in
benchmarking:
The customer – that is, the business manager responsible for acquiring IT
services to meet business objectives. The customer’s interest in
benchmarking would be: ‘How can I improve my performance in munotes.in

Page 156

IT Service
Management
156 procuring ser vices and managing a service provider, and in supporting the
business through IT services?’
The user or consumer – that is, anyone using IT services to support his
or her work. The user’s interest in benchmarking would be: ‘How can I
improve my performanc e by leveraging IT?’
The internal service provider – providing IT services to users under
Service Level Agreements negotiated with and manages the customer. The
provider’s interest in benchmarking would be: ‘How can we improve our
performance in the suppl y of IT services which meet the requirements of
our customers and which are cost -effective and timely?’
There will also be participation from external parties:
External service providers – providing IT services to users under
contracts and Service Agreem ents negotiated with and managed by the
customer
Members of the public – becoming increasingly direct users of IT
services
Benchmarking partners – that is, other organizations with whom
comparisons are made to determine best practices to be adopted for
improvements.
9.3.3.5 What to benchmark?
Differences in benchmarks between organizations are normal. All
organizations and service -provider infrastructures are unique, and most are
continually changing. There are also intangible but influential factors th at
cannot be measured, such as the development, goodwill, image and
culture. It is important to understand the size and nature of the business
area, including the geographical distribution and the extent to which the
service is used for business or time -critical activities. Benchmarking
techniques can be applied at various levels from simple in -house
comparisons through to an industry -wide search for best practice. Or
better yet, let us apply the improvement process to benchmarking.
9.3.3.5.1 What should we measure?
 Select the broad service or a service management process or function
to benchmark (such as Service Desk) relative to stakeholder needs.
 Draw up a preliminary list of potential benchmarking partners (these
may be within the organization or outsi de).
 Identify sources of information and methods of collection in order to
confirm the suitability of potential partners.

munotes.in

Page 157

Continual Service
Improvement Principles,
CSI Processes, CSI
Methods and Techniques
157 9.3.3.5.2 What can we measure?
 Within that process, define the activities to be benchmarked (such as
incident lifecycle).
 Identi fy the resources required for the study.
 Document the way tasks are currently completed.
 Agree the plan and its implementation.
9.3.3.5.3 Gathering:
 Collect information to identify potential benchmarking partner to
contact.
9.3.3.5.4 Analysing:
 Confi rm the best potential comparative analysis partner and make a
preliminary assessment of the performance gap.
 Establish contacts and visits, if necessary, to validate and substantiate
the information.
 Compare the existing process with that of the benchmar king partner to
identify differences and innovations.
9.3.3.5.5 Presenting and using:
 Communicate the results of the study throughout the relevant parts of
the organization and to the benchmarking partner.
 Plan how to achieve the improvements.
9.3.3.5. 6 Taking corrective action:
 Review performance when the changes were embedded in the
organization.
 Identify and rectify anything that may have caused the organization to
fall short of its target.
 Communicate the results of the desired changes implemente d to the
organization and the benchmarking partner.
 Consider benchmarking again to continue the improvement process.
9.3.3.6 Benchmark Approach: -
Benchmarking will establish the extent of an organization’s existing
maturity with best practice and will he lp in understanding how that
organization compares with the industry's norms. Deciding what the KPIs
are going to be and then measuring against them will give solid
management information for future improvement and targets. A munotes.in

Page 158

IT Service
Management
158 benchmark exercise would be us ed as the first stage in this approach. This
could be any or other of:
An internal benchmark – completed internally using resources from
within the organization to assess the maturity of the service management
processes against a reference framework
An e xternal benchmark – an external third -party company would
complete this. Most of these have its own proprietary models for the
assessment of service management process maturity.
There is a variety of IT for comparative analysis types available separately
or in combination, including:
 Cost and performance for internal service providers
 Process performance against industry best practice
 Financial results of high -level IT costs against industry or peers
 Effectiveness considering satisfaction ratings and b usiness alignment
at all levels.
9.3.3.7 The context for benchmarking requires information on the
organization’s profile, complexity, and relative comparators. An
effective and meaningful profile contains four key components:
Company information profile – The company profile defines the
landscape of an organization, i.e. basic information about company size,
industry type, geographic location and types of user are typical of data
gathered to establish this profile.
Current assets – The IT assets mix with in the company may include
production IT, desktop and mobile clients, peripherals, network and server
assets.
Current best practices – These include policies, procedures and/or tools
that improve returns, and their maturity and degree of usage.
Complexit y – Complexity includes information about the end -user
community, the types and quantities of varied technologies in use and how
IT is managed.
9.3.4 Service Measurement:
Objective:
For services there are three basic measurements that most organizations
utilize.
Availability of the service
Reliability of the service
Performance of the service munotes.in

Page 159

Continual Service
Improvement Principles,
CSI Processes, CSI
Methods and Techniques
159 In many cases when an organization is monitoring, measuring and
reporting on component levels they are doing so to protect themselves and
possibly to point the bl ame elsewhere. Service measurement is not about
placing blame or protecting oneself but is about providing a meaningful
view of the IT service as the customer experiences the service. Service
measurement will also require someone to take the individual
measurements and combine them to provide a view of the true customer
experience. Figure 9.6 shows how it is possible to measure and report
against various levels of systems and components to provide a true service
measurement. Even though the figure reference s availability measure and
report the same can apply for performance measuring and reporting.
9.3.4.1 Developing a Service Measurement Framework
A challenge many organizations face is the creation of a Service
Measurement Framework that leads to value - added reporting. Setting up a
framework is as much an art as a science. An organization may go through
some trial and error in the beginning so it should not be afraid to admit
mistakes on particular measures or targets and make adjustments to the
framework . One of their first steps in developing a Service Measurement
Framework is to understand the business processes and to identify those
that are most critical to the delivery of value to the business. The IT goals
and objectives must support the business go als and targets. Service
measurement is not only looking at the past but also the future
 What do we need to be able to do and how can we do things better?
The output of any Service Metering Framework should allow
individuals to make operational, tactical or strategic decisions. The
following steps are key to service measurement.
Origins
 Defining what success looks like. What are we trying to achieve and
how will we know when we’ve achieved it?
Building the framework and choosing measures
 What do we ne ed to measure that will provide us with useful
information that allows us to make strategic, tactical and/or operational
decisions?
 What measures will provide us with the data and information we need?
 Setting targets for all measures. This may be set by Service Level
Agreements or service level targets/objectives that have been agreed
internally within IT.


munotes.in

Page 160

IT Service
Management
160 Defining the procedures and policies

Fig 9.4 Measurement of Services
 Define the procedures f or making metrics and determine the tools to
be used to support gathering of the data and other measurement
activities.
 Identify the roles and responsibilities for service measurement – who
will do what?
 Decide the criteria for the continuous improvement initiatives.
 Consider when targets should be raised?
9.3.4.2 Different Levels of Measurement and Reporting: -
Creating a Service Measurement Framework will require the ability to
build upon different metrics and measurements. The end result is a view of
the way individual component measurements feed the end -to-end service
measurement which should be in support of key performance indicators
defined for the service.
The service scorecard will then be used to populate an overall Balanced
Scorecard or IT sco recard. As shown in Figure 9.5 there are multiple
levels that need to be considered when developing a Service Measurement
Framework.
Service Measurement Model
Starting at the bottom, the technology domain areas will be monitoring
and reporting on a compone nt basis. This is valuable as each domain area
is responsible for ensuring the servers are operating within defined
guidelines and objectives. Such measurements will also feed into any munotes.in

Page 161

Continual Service
Improvement Principles,
CSI Processes, CSI
Methods and Techniques
161 incremental operations improvements and into a more formal CSI
initiati ve.
Defining what to measure
Effective service measures concentrate on a few vital, meaningful
indicators that are economical, quantitative, and usable for the desired
results. A guiding principle is to measure that which matters most.
Defining what to m easure is important to ensure that the proper measures
are in place to support the following:
Service performance versus strategic business and IT plans – this would
be a part of a Balanced Scorecard or IT scorecard.
Risk and compliance with regulations and security requirements for the
service – monitoring of security incidents and embedding security
requirements in the Service Design and Transition practices.

Fig 9.5 Service Measurement Level
 Busine ss contribution including but not limited to financials – how
does IT support the company in delivering services. As an example, if
your organization is an insurance company the major business services
are writing policies and paying claims.
 Key IT proces ses that support the service – how do availability,
capacity and IT service continuity support the service?
 Internal and external customer satisfaction – that measures the
customer satisfaction to ensure that the customer’s needs are being
met.
Service l evels: -
This measure will include service, system, component availability,
transaction, and response time on components as well as the service, munotes.in

Page 162

IT Service
Management
162 delivery of the service/application on time and on budget, quality of the
service and compliance with any regula tory or safety requirements. Many
SLAs at the same time require monitoring and reporting on Incident
Management measures such as mean time to repair (MTTR) and mean
time to restore a service (MTRS). Other normal measurements will be
mean time between syste m incidents (MTBSI) and mean time between
failures (MTBF).
Customer satisfaction
Surveys are conducted on a continual basis to measure and track customer
satisfaction. It is common for the Service Desk and Incident Management
to conduct a random sampling of client satisfaction on incident tickets.
Business impact
Measure what actions are invoked for any disruption in service that
adversely affects the customer’s business operation, processes, or its own
customers.
Supplier performance
Whenever an orga nization has entered a supplier relationship where some
services or parts of services have been outsourced or co -sourced it is
important to measure the performance of the supplier. Each vendor
relationship should have defined, quantifiable measures and tar gets and
measurement and reporting should be against the delivery of these
measures and targets.
Setting targets
Targets set by management are quantified objectives to be attained. They
express the aims of the service or process at every level and provid e the
basis for the identification of problems and early progress towards
solutions and improvement opportunities. Service measurement targets are
often defined in response to business demands, or they may result from
new policy or regulatory requirements. Service Level Management
through Service Level Agreements will often drive the target that is
required. With a new service it would be unwise to enter into a Service
Level Agreement as long as the overall capabilities are clearly identified.
Setting targe ts is just as important as selecting the right measures. It's
important that the targets are realistic but challenging. Good targets will be
SMART (specific, measurable, achievable, relevant, and timely). When
setting targets, it is important to determine the baseline: that is the starting
point from which you will measure improvement.
9.3.4.3 Service Management Process Measurement: -
The same principles applied when measuring the efficiency and
effectiveness of a service management process. As the figure b elow
Figure 9.6 shows you will need to define what to measure at the process
activity level. These activity measures should be in support of the course
key performance indicators (KPIs). munotes.in

Page 163

Continual Service
Improvement Principles,
CSI Processes, CSI
Methods and Techniques
163 The KPIs a need to promote higher -level goals. The next level contai ns the
KPIs associated with each process. The activity metrics should feed into
and support the KPIs.
The KPIs will provide support to the next level which is the high -level
goals such as improving service quality, reducing IT costs or improving
customer satisfaction, etc.
Finally, these will feed into an organization's Balanced Scorecard or IT
scorecard. When first starting out, be careful to not pick too many KPIs to
support the high -level goals. Additional KPIs can always be added later.
9.3.4.4 Servi ce Management Model: -
Creating a measurement framework grid
It is recommended to create a framework grid that will lay out the high -
level targets and define which KPIs will support the goal and also which
category the KPI addresses. KPI categories can be classified as the
following:
 Compliance – are we doing it?
 Quality – how well are we doing it?
 Performance – how fast or slow are we doing it?
 Value – is what we are doing making a difference?
9.3.5 Metrics:

 It is important to remember that there are three types of metrics that an
organization will need to collect to support CSI activities as well as
other process activities:

 Technology metrics :-These metrics are often associated with
component and applicationbased metrics such as performance,
availability etc.

 Process metrics: - These metrics are captured in the form of critical
success factors (CSFs), KPIs and activity metrics for the service
management processes. They can help determine the overall health of
a process. KPIs can help answer four key ques tions on quality,
performance, value, and compliance of following the process. CSI
would use these metrics as input in identifying improvement
opportunities for each process.

 Service metrics: - These metrics are a measure of the end -to-end
service performa nce. Individual technology and process metrics are
used when calculating the end -to-end service metrics.

munotes.in

Page 164

IT Service
Management
164 Interpreting and using metrics: -
Results must be examined in context of the objectives, natural
environment, and any external factors. Thus, after co llecting the results,
organizations will conduct measurement reviews to determine how well
the indicators worked and how the results contribute to objectives. If they
do not, then instead of interpreting results, action should be taken to
identify the reas ons the results appear the way they do.
Using measurement and metrics
Metrics can be used for several purposes such as to:
Validate – are we support the strategy and vision?

Fig 9.6 Process Activity Level
 Justify – do we have the right objectives and metrics?
 Direct – based on factual data, people may be guided to change
behaviour
 Intervene – take corrective actions such as defining improvement
opportunities.
Service measurements and metrics should be used to drive decisions.
Whichever is being measured the decision could be a strategic, tactical or
operational decision. This is the case for CSI. There are many
opportunities to improve but there is often only a limited budget to address
the improvem ent opportunities, so decisions must be made.
Using the measurements and metrics can also help define any external
factors that may exist outside the control of the internal or external service
provider. Individual measurements and actions by themselves m ay tell an
organization very little from a strategic or tactical point of view. munotes.in

Page 165

Continual Service
Improvement Principles,
CSI Processes, CSI
Methods and Techniques
165 Creating Scorecards and Reports
Service measurement information will be used for three main purposes: to
report on the service to interested parties; to compare against target s; and
also, to identify improvement opportunities. Reports must be appropriate
and useful for all those who use them. There are typically three distinct
audiences for reporting purposes.
 The business – is it really focused on supply to time and budget?
 IT management – the administration will be interested in the tactical
and strategic outcomes that support the business.
 IT operational/technology managers – these people will be concerned
with the tactical and functional metrics which support better plann ing,
coordination and scheduling of resources. The operational managers
will be interested in their technology domain measures such as
component availability and performance.
Many organizations make the mistake of create and distribute the same
report to everyone. This does not offer value for everyone.
Figure 9.7 illustrates how the overall goals and objectives can be used to
derive the measurements and metrics needed to support overall goals and
objectives. The arrows point both ways since strategy, goa ls and
objectives will drive the identification of required KPIs and measures, but
it's also important to remember that the measures are input in KPIs and the
KPIs support the goals in balanced Scorecards.
9.3.5.1 Deriving Measurements and Metrics from Goals and
Objectives :-
When creating reports, it is important to know their purpose and the
details that are required. Reports may be used to provide information for
one month, or a comparison of the current month with other months to
provide a trend for a certain time period. Reports can show whether
service levels are being met or breached. Before starting the design of any
report, it is also important to know the following:

Fig 9.7 Goals and Objectives munotes.in

Page 166

IT Service
Management
166  Who is target readers of the report?
 What will the report be used for?
 Who is responsible for creating the report?
 What information is produced, shared, or exchanged? Reports can be
set up to show the following:
 Results for a service – that support reports w ould be the individual
measurements on components
 Health of a service management process – this report will have certain
process KPI results
 Practical reports – such as telephony reports for the Service Desk.
9.3.6 Return on Investment :-
Few organizati ons are willing to subsidize the cost and effort associated
with process improvement without some quantification of costs and
evidence of benefits and outcomes. Unfortunately, going beyond the
‘sounds like a good idea’ point into quantifiable outcomes pres ents several
challenges. These may include the following:
 There is no true understanding of current IT capabilities or costs.
 There is limited knowledge of entrepreneurial drivers, and their link
with IT.
 Viable data is difficult to find in a low -proces s maturity, data -poor
environment.
 Frequently there is limited information of the cost of IT downtime in
the business and IT.
 There is limited knowledge of the support at a unit level (e.g. cost of
an incident, cost of a Level 2 support visit).
 Compilin g a clear and persuasive case for improving the process is
difficult.
 Success criteria are inadequately identified, or a way to measure them
is not clear.
 A failure to progressively measure and monitor benefits/returns.
The Return -on-Investment challeng e needs to take into consideration
many factors. On one side is the investment cost. This is the money an
organization pays to improve services and services management
processes. These costs will be internal resource costs, tool costs,
consulting costs, et c. Availability is a good measure to understand the cost
of productivity losses, the cost of not being able to complete a business
transaction, or the true cost of downtime. munotes.in

Page 167

Continual Service
Improvement Principles,
CSI Processes, CSI
Methods and Techniques
167 The Business Case should articulate the reason for undertaking a service
or proce ss improvement project. As far as possible, data and evidence
should be provided relating to the costs and the expected benefits of
undertaking process improvement. This could in turn result in worthwhile
initiatives not being approved, or revision of the initiative revealing
apparent failure when it was successful.
While the initial identification of benefits is an estimate of those likely to
be realized by the proposed process improvement initiative, there is also a
need to subsequently measure the advan tages achieved. These
measurements attest to whether the improvement activity achieved the
intended outcomes and should consider:
 Whether the planned improvements were realized
 Whether benefits from improvements were achieved
 Whether the target ROI was achieved
 Whether the intended value -added has actually been achieved (VOI)
 Whether the outcomes of the preceding points lead to further process
improvement actions being re - evaluated
 Whether adequate time has passed before measuring the benefits.
Some benefits will not be immediately apparent; and it is likely that
benefits will continue to change over time, as both ongoing costs and
continuing benefits continue to move.
9.3.7 Service reporting: -
A significant amount of data is collated and monitored by IT i n the daily
delivery of quality service to the business; however, only a small subset is
of real interest and meaning to the business. The reporting ethos which
focuses on the future as strong as it focuses on the past also provides the
means for IT to mar ket its wares directly aligned to the positive or
negative experiences of the business.
An ideal approach to building a business -focused service -reporting
framework is to take the time to define and agree the policy and rules with
the business and Service Design about how reporting will be implemented
and managed. This includes:
 Targeted audience(s) and the related business views on what the
service delivered is
 Agreement on what to measure and what to report on
 Agreed definitions of all terms and bound aries
 Basis of all estimates
 Reporting schedules
 Access to reports and medium to be used
 Meetings planned to review and discuss reports. munotes.in

Page 168

IT Service
Management
168 Numerous policies and rules can exist as long as it is clear for each report
which policies and rules have been ap plied, e.g. one policy may be applied
to production whereas a variant may be more suited to the sales team.
However, all policies and rules form part of the single reporting
framework.
Targeting appropriately designed reports simply becomes a process of
converting flat historical data into useful business views once the
structure, standards, and rules are in place (which can be automated). As a
result, the intended recipient is provided with precise, unambiguous, and
pertinent information that is accessibl e in the medium of their choice and
that describes how IT was delivered into their environment and within
their boundaries without being muddled by information about how IT was
delivered into other parts of the company. The procedure for reporting
services is shown in Figure 9.8.

Fig 9.8 Service Reporting
9.3.8 CSI and other service management processes: -
The CSI process makes extensive use of methods and practices found in
many ITIL processes throughout the l ifecycle of a service. Far from being
redundant, the use of the outputs in the form of flows, matrices, statistics
or analysis reports provide valuable insight into the service’s design and
operation.
9.3.8.1 Availability Management: -
Availability Management (AM) plays a key role in helping the IT support
organization recognize where they can add value by exploiting technical
skills and competencies in an availability context. The data provided by
AM is made available to CSI through the Availability Management
Information System (AMIS).
Fault Tree Analysis (FTA) is a technique that is used to determine the
chain of events that cause a disruption of IT services. This technique
offers detailed models of accessibility. When provided to CSI, FTA
information indicates w hich part of the organisation, process or service
was responsible in the service disruptions. munotes.in

Page 169

Continual Service
Improvement Principles,
CSI Processes, CSI
Methods and Techniques
169 Service Failure Analysis (SFA) is a method designed to provide a
structured approach to identify end -to-end accessibility improvement
opportunities that deliver benefits to the user. CSI and SFA work hand in
hand. SFA classifies the business impact of an outage on a service, system
or process. This information, combined with business requirements,
enables CSI to make proposals about how to address improvement
oppo rtunities.
A Technical Observation (TO) is a prearranged gathering of specialist
technical support staff from within IT support. The TO gathers, processes
and analyses information about the situation. Too often the TO is reactive
by nature and is assemble d hastily to deal with an alternative.
Expanded Incident lifecycle – A technique to help with the technical
analysis of Incidents affecting the availability of components and IT
services. The Expanded Incident lifecycle is further made up of two parts:
time to restore service (aka downtime) and time between failures (aka
uptime). There is a diagnosis part to the Incident lifecycle as well as
repair, restoration and recovery of the service.
9.3.8.2 Capacity Management:


Fig 9.9 Capacity Management
Capacity Management must ensure sufficient hardware, software and
personnel resources are in place to support existing and future business
capacity and performance requirements. This can be used with either small
group s of technical staff or a wider group within a workshop environment.
A prime objective of the Business Capacity Management sub-process is
to ensure that future business requirements for IT services are considered munotes.in

Page 170

IT Service
Management
170 and understood, and that sufficient capaci ty to support the services is
planned and implemented in an appropriate timescale. The consequences
of changes in the use of services can be estimated based on information
and understanding of the performance needs for each service, and steps
can be made t o guarantee that the necessary service performance can be
accomplished.
A prime objective of the Service Capacity Management sub-process is to
identify and understand the IT services, their use of resource, working
patterns, peaks and troughs, as well as t o ensure that the services can and
do meet their SLA targets.
A prime objective of Component Capacity Management sub-process is
to identify and understand the capacity and utilization of each of the
components of the IT infrastructure.
9.3.8.3 Workload M anagement can be defined as understanding which
customers use what service, when they use the service, how they use the
service and finally how using the service impacts the performance of a
single or multiple systems and/or components that make up a servi ce.
9.3.8.4 Demand Management is often associated with influencing the
end users’ behaviour. By influencing the end users’ behaviour an
organization can change the workload thus improving the performance of
components that support IT services.
9.3.8.5 IT Service Continuity Management:
Any CSI initiative to enhance services must also integrate with ITSM
since any changes to the infrastructure, service requirements, etc. must be
taken into consideration for any adjustments that might be necessary for
the con tinuity plan. Reducing risk to a manageable level and preparing for
the restoration of business processes in the event that a risk materializes
and a disruption to the business takes place are both parts of the business
continuity management process. An IT business can better understand the
environment in which it operates, choose which risks it wants to mitigate,
and take proactive steps to safeguard the interests of all stakeholders by
using ITSM to identify, assess, and manage its risks. CSI can support this
effort and aid in generating revenue.
The task of Risk Management is to ensure that the organization makes
cost-effective use of a risk process that has a series of well -defined steps.
There are two distinct phases: risk analysis and risk management. Risk
analysis involves the identification and assessment of the level (measure)
of the risks calculated from the assessed values of assets and the assessed
levels of threats to, and vulnerabilities of, those assets.
9.3.8.6 Problem Management:
CSI and Pro blem Management are closely related because one of the
objectives of Problem Management is to locate and permanently fix faults
that affect infrastructure services. This directly aids CSI initiatives to find munotes.in

Page 171

Continual Service
Improvement Principles,
CSI Processes, CSI
Methods and Techniques
171 and implement service improvement measures. Thro ugh trend monitoring
and the targeted application of preventive action, problem management
additionally complements CSI operations. Any PIR on changes made to a
service in order to improve it must include CSI.
9.3.8.7 Change, Release and Deployment Managem ent :
All CSI activities will fall under the scope of Change, Release and
Deployment Management. CSI’s goal is to identify and implement
improvement activities on IT services that support the business processes
as well as identify and implement improvement s to ITSM processes.
9.3.8.8 Knowledge Management:
Knowledge Management is one of the core areas that supports CSI.
Knowledge gathering, organisation, quality assessment, and application
are all significant contributions to CSI operations. For identifying trends in
Service Level Achievements and/or outcomes and output of facility
management procedures, an organisation must collect information and
analyse what the results are. This information is used to decide which
service improvement initiatives to focus on. Successful knowledge
management requires two key elements:
An open culture where knowledge, both best practices and lessons
learned is shared across the organization and people are rewarded for it.
The infrastructure – a culture may be open to knowle dge sharing, but
without the means or infrastructure to support it, even the best intentions
can be compromised, and over time this serves as a demotivator, quelling
the behaviour.
9.4 ORGANISING FOR CONTINUAL SERVICE
IMPROVEMENT (CSI)
9.4.1 Organisationa l development: -
CSI activities will be successful if specific roles and responsibilities are
properly identified. As with many roles, these may or may not be a full -
time position, however, itis important that roles are identified at the outset
of any CSI i nitiative.
9.4.1.1 Define what you should measure Roles:
Individuals involved with decision making from IT and the business who
understand the internal and external factors that influence the necessary
elements that should be measured to support the busine ss, governance and,
possibly, regulatory legislation. Example titles: Service Manager, Service
Owner, Service Level Manager, CSI Manager, Process Owner, process
managers, customers, business/IT analysts and senior IT managers. munotes.in

Page 172

IT Service
Management
172

Fig: 9.10 Activities and Sk ills levels needed for CSI.
9.4.1.2 Roles involved in the 'define what you should measure'
activity.
Roles: Individuals involved with decision making from IT and the
business who understand the internal and external factors that influence
the necessary ele ments that should be measured to support the business,
governance and, possibly, regulatory legislation.
Example titles: Service Manager, Service Owner, Service Level Manager,
CSI Manager, Process Owner, process managers, customers, business/IT
analysts an d senior IT managers.
9.4.1.3 Roles involved in the 'define what you can measure' activity.
Roles: Individuals involved with providing the service (internal and
external providers) who understand the capabilities of the measuring
processes, procedures, too ls and staff.
Example titles: Service Manager, Service Owner, Process Owner, process
managers, internal and external providers.
9.4.1.4 Roles involved in the ' gathering the data' activity.
Roles: Individuals involved in day -to-day process activities within the
Service Transition and Service Operation lifecycle phases.
Example titles: Service desk staff, technical management staff, application
management staff, IT security staff.
9.4.1.5 Roles involved in the ' processing the data' activity.
Roles: Individual s involved in day -to-day process activities within the
Service Transition and Service Operation lifecycle phases.
Example titles: Service desk staff, technical management staff, application
management staff, IT security staff. Analysing the data munotes.in

Page 173

Continual Service
Improvement Principles,
CSI Processes, CSI
Methods and Techniques
173 9.4.1.6 Roles involved in the ' analyzing the data' activity.
Roles: Individuals involved with providing the service (internal and
external providers) who understand the capabilities of the measuring
processes, procedures, tools and staff.
Example titles: Service Own er, Process Owner, process managers,
business/IT analysts, senior IT analysts, supervisors and team leaders.
9.4.1.7 Roles involved in the ' presenting and using the information'
activity.
Roles: Individuals involved with providing the service (internal and
external providers) who understand the capabilities of the service and the
underpinning processes and possess good communication skills. Key
personnel involved with decision making from both IT and the business.
Example titles: CSI Manager, Service Owner, Service Manager, Service
Level Manager, Process Owner, process managers, customers, business/IT
analysts, senior IT managers, internal and external providers.
9.4.1.8 Roles involved in the ' implement ing corrective action' activity.
Roles: Individuals invo lved with providing the service (internal and
external providers).
Example titles: CSI Manager, Service Owner, Service Manager, Service
Level Manager, Process Owner, process managers, customers, business/IT
analysts, senior IT managers, internal and extern al providers.
9.4.2 Functions, roles: -
9.4.2.1 Service Manager:
Service Manager is an important role that manages the development,
implementation, evaluation and on -going management of new and existing
products and services. Responsibilities include busine ss strategy
development, competitive market assessment/benchmarking, financial and
internal customer analysis, vendor management, inventory management,
internal supplier management, cost management, delivery and full
lifecycle management of products and/or services. Service Managers are
responsible for managing very complex projects in order to achieve
objectives and strategies and strive for global leadership in the
marketplace. In order to attain this goal, they must evaluate new market
opportunities, ope rating models, technologies and the emerging needs of
customers in a company with international scope.
At this level, Service Managers are recognized as global product/service
experts. They drive the decision -making processes, manage
product/service object ives and strategies, hold internal and external
suppliers accountable via formal agreements, and provide the integration
of individual product plans and new technologies into a seamless
customer -focused services. Service Managers may also be required to munotes.in

Page 174

IT Service
Management
174 coach other managers (Service Owners, Process Owners) with differing
levels of expertise for managing a business function or a particular
product/service, within a specified product/service family.
Key Responsibilities
 Provide leadership on the development o f the 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 conflicting objectives to achieve the
organization's goals and financial commitments.
 Instil a market focus.
 Create an imaginative organization whic h encourages high
performance and innovative contributions from its members within a
rapidly changing environment.
Service Managers are able to effectively communicate product/service line
strategies to corporate business leaders, and develop partnerships with
other organizations within the company with both similar and dissimilar
objectives and also with suppliers in order to satisfy internal and external
customer needs. This is most often achieved via formalized agreement for
both internal and external su ppliers.
They must be able to formulate development programmes in response to
new market opportunities, assess the impact of new technologies and
guide creation of innovative solutions to bring best -in-breed solutions to
our internal and external customers . They market the development and
implementation of products/services that incorporate new technologies or
system development. This requires extensive cross -organization
communications. They also can identify, develop and implement financial
improvement op portunities in order to meet the firm's commitments.
Key Skills and Competencies
 Previous product/market management experience
 Working knowledge of market analysis techniques and marketing
programmes
 Advanced degree or equivalent experience
 Working knowled ge of the domestic and international marketplace
including industry applications, needs/trends, competitive vendor
offerings, outsourcing, licensing, vendor management and customer
relationships. munotes.in

Page 175

Continual Service
Improvement Principles,
CSI Processes, CSI
Methods and Techniques
175  Product knowledge must include complex engineering,
telecomm unications, and data protocols, as well as data processing
applications and the ability to analyse the impact of new technologies.
 Demonstrated sustained performance in previous assignments
 Sound business judgment
 Negotiating skills
 Human resource manageme nt skills
 Excellent communications skills
 Accept challenges and manage risk effectively and innovatively
 Produce solutions on time within cost objectives.
9.4.2.2 CSI Manager:
This new role is essential for a successful improvement programme. The
CSI owner is ultimately responsible for the success of all improvement
activities. This single point of accountability coupled with competence and
authority virtually guarantees a successful improvement programme.
Key Responsibilities
 Responsible for development of the CSI domain
 Responsible for communicating the vision of CSI across the IT
organization.
 Ensures that CSI roles have been filled.
 Works with the Service Owner to identify and prioritize improvement
opportunities.
 Works with the Service Level Manager to ensure that monitoring
requirements are defined.
 Works with the Service Level Manager to identity service
improvement plans
 Ensures that monitoring tools are in place to gather data.
 Ensures that baseline data is captured to measure improvement against
it.
 Defines and reports on CSI CSFs, KPIs and CSI activity metrics.
 Identifies other frameworks, models and standards that will support
CSI activities.
 Ensures that Knowledge Management is an integral part of the day -to-
day operations. munotes.in

Page 176

IT Service
Management
176  Ensures that CSI activi ties are coordinated throughout the service
lifecycle.
 Reviews analysed data.
 Presents recommendations to senior management for improvement.
 Helps prioritize improvement opportunities.
 Lead, manage and deliver cross -functional and cross divisional
improvem ent projects.
 Build effective relationships with the business and IT senior managers.
 Identify and deliver process improvements in critical business areas
across manufacturing and relevant divisions.
 Set direction and provide framework through which improv ement
objectives can be delivered.
 Coach, mentor and support fellow service improvement professionals.
 Possess the ability to positively influence all levels of management to
ensure that service improvement activities are receiving the necessary
support an d are resourced sufficiently to implement solutions.
9.4.2.3 Service Owner
The Service Owner is accountable for a specific service within an
organization regardless of where the underpinning technology
components, processes or professional capabilities res ide. Service
ownership is as critical to service management as establishing ownership
for processes which cross multiple vertical silos or departments.
Key Responsibilities
 Service Owner for a specified service
 Provides input in service attributes such as performance, availability
etc.
 Represents the service across the organization.
 Understands the service (components etc.)
 Point of escalation (notification) for major Incidents
 Represents the service in Change Advisory Board meetings.
 Provides input in CSI.
 Participates in internal service review meetings (within IT)
 Works with the CSI Manager to identify and prioritize service
improvement. munotes.in

Page 177

Continual Service
Improvement Principles,
CSI Processes, CSI
Methods and Techniques
177  Participates in external service review meetings (with the business)
 Responsible for ensuring that the service entry in the Service
Catalogue is accurate and is maintained.
 Participates in negotiating SLAs and OLAs.
To ensure that a service is managed with a business focus, the definition of
a single point of accountability is essential to provide the level of attention
and focus required for its delivery.
The Service Owner is responsible for continual improvement and the
management of change affecting the services under their care. The Service
Owner is a primary stakeholder in all of the underlying IT processes which
enabl e or support the service they own. For example:
 Incident Management - Involved in or perhaps chairs the crisis
management team for high -priority incidents impacting the service
owned
 Problem Management - Plays a major role in establishing the root
cause an d proposed permanent fix for the service being evaluated
 Release and Deployment Management - Is a key stakeholder in
determining whether a new release affecting a service in production is
ready for promotion
 Change Management - Participates in Change Advis ory Board
decisions, approving changes to the services they own
 Asset and Configuration Management - Ensures that all groups
which maintain the data and relationships for the service architecture
they are responsible for have done so with the level of inte grity
required
 Service Level Management - Acts as the single point of contact for a
specific service and ensures that the Service Portfolio and Service
Catalogue are accurate in relationship to their service
 Availability and Capacity Management - Reviews t echnical
monitoring data from a domain perspective to ensure that the needs of
the overall service are being met
 IT Service Continuity Management - Understands and is responsible
for ensuring that all elements required to restore their service are
known an d in place in the event of a crisis
 IT Financial Management - Assists in defining and tracking the cost
models in relationship to how their service is costed and recovered.

munotes.in

Page 178

IT Service
Management
178 P = Primary Responsibility S = Secondary Responsibility CSI
Manager Service
Level
Manager Service
Owner
Focus
IT services S P P
IT systems S P
Processes P S S
Customers S P S
Technology P S P
Responsible For:
development and maintenance of the
catalogue of existing services P S
developing and maintaining OLAs P S
gather ing Service Level Requirements
from the customer S P S
negotiating and maintaining SLAs with
the Customer S P S
understanding UCs as they relate to
OLAs and SLAs S P S
ensuring appropriate service level
monitoring is in place P P S
producing, reviewing and evaluating
reports on service performance and
achievements on a regular basis P P P
conducting meetings with the customer
on a regular basis to discuss service
level performance and improvement S P S munotes.in

Page 179

Continual Service
Improvement Principles,
CSI Processes, CSI
Methods and Techniques
179 conducting yearly SLA review meetings
with the cu stomer S P S
ensuring customer satisfaction with the
use of a customer satisfaction survey S P S
initiating appropriate actions to improve
service levels (SIP) P P P
the negotiation and agreement of OLAs
and SLAs P P S
ensuring the management of
underp inning contracts as they relate to
OLAs and SLAs S P S
working with the Service Level
Manager to provide services to meet the
customer's requirements P P
appropriate monitoring of services or
systems P P P
producing, reviewing and evaluating
reports o n service or system
performance and achievement to the
Service Level Manager and the Service
Level Process Manager P P P
Assisting in appropriate actions to
improve service levels (SIP) P P P
Skills, knowledge and competencies
relationshlp management sk ills P P P
A good understanding of IT services
and qualifying factors in order to
understand how customer requirements
will affect delivery P P P
An understanding of the customer's
business and how IT contributes to the
delivery of that product or servic e P P P munotes.in

Page 180

IT Service
Management
180 Good communication skills P P P
Good negotiation skills P P P
Knowledge and experience of contract
and/or supplier management roles S P S
Good people management and meeting
facilitating skills P P P
Good understanding of statistical and
analyt ical principles and processes P S S
Good presentation skills P P S
Good technical understanding and an
ability to translate technical
requirements and specifications into
easily understood business concepts and
vice versa S P S
Innovative in respect of service quality
and ways in which it can be improved
within the bounds of the organization's
limits (resource, budgetary, legal etc.) P P P
Good organizational and planning skills P P P
Good vendor management skills S P S
Table showing Comparison of CSI Manager, Service Level Manager
and Service Owner

9.4.2.4 Process Owner:
The initial planning phase of any ITIL project must include establishing
the role of Process Owner. This key role is accountable for the overall
quality of the process and oversees the management of, and organizational
compliance to, the process flows, procedures, data models, policies and
technologies associated with the IT business process.
The Process Owner performs the essential role of process champion,
design lead, advocate, co ach and protector. Typically, a Process Owner
should be a senior level manager with credibility, influence and authority
across the various areas impacted by the activities of the process. The munotes.in

Page 181

Continual Service
Improvement Principles,
CSI Processes, CSI
Methods and Techniques
181 Process Owner is required to have the ability to influence and ensure
compliance to the policies and procedures put in place across the cultural
and departmental silos of the IT organization.
9.4.2.5 Reporting analyst:
The reporting analyst is a key role for CSI and will often work in concert
with the Service Level Ma nagement roles. The reporting analyst reviews
and analyses data from components, systems and sub -systems in order to
obtain a true end -to-end service achievement. The reporting analyst will
also identify trends and establish if the trends are positive or n egative
trends. This information is then used in the presenting of the data.
Key responsibilities
 Participating in CSI meetings and Service Level Management
meetings to ensure the validity of the reporting metrics, notification
thresholds and overall solut ion.
 Responsible for consolidating data from multiple sources.
 Responsible for producing trends and provides feedback on the trends
such as whether the trends are positive or negative, what their impact
is likely to be, and if the trends are predictable fo r the future.
 Responsible for producing reports on service or system performance
based on the negotiated OLAs and SLAs and improvement initiatives.
Key Skills and Competencies
 Good understanding of statistical and analytical principles and
processes
 Strong technical foundation in the reporting tool(s)
 Good communication skills
 Good technical understanding and an ability to translate technical
requirements and specifications into easily understood reporting
requirements.
9.4.3 Customer Engagement: -
These new roles are the embodiment of the concepts of a service -oriented
organization. To run a traditional IT organization focusing on technical
excellence, these roles will seem extraneous. To run a forward -thinking,
service -oriented IT partner to the business, t hese roles are crucial.
Improvement will not happen by itself. It requires a structured programme
and mature processes. The roles shown below are responsible for that
programme.
munotes.in

Page 182

IT Service
Management
182

Fig 9.11 Customer Engagement
9.4.4 Responsibility model - RACI: -
ITIL utili zes the RACI model as a generic tool for reviewing and
assigning four key roles to any important task or activity. Whereas role
assignments are often well -defined within functions , the RACI model
holds value for ensuring that roles are appropriately filled or covered
within processes.
 Those in the R = RESPONSIBLE role for a given activity are
charged with executing or performing the activity or task.
 The single entity in the A = ACCOUNTABLE role owns the task or
activity and must respond for its outcomes. Only one party can be
responsible for a given task/activity.
 Those in the C = CONSULTED role review and provide assistance
and authorization around the task or activity.
 Those in the I = INFORMED role receives updates as the job or
activity progresses.
The table below provides a sample of how RACI might be used to assign
roles to a series of tasks associated with an application development
project. Note that all rows have one and only one ACCOUNTABLE and
at least one RESPONSIBLE.
To build a RACI chart , the following steps should be followed:
 Identify the individual processes activities
 Identify and define the roles within the process.
 Conduct meetings with stakeholders and assign the RACI codes. munotes.in

Page 183

Continual Service
Improvement Principles,
CSI Processes, CSI
Methods and Techniques
183  Identify any gaps or overlaps – for example, where th ere is multiple
A’s or no R’s

Fig 9.12Using RACI model to assign roles
 Distribute the chart and incorporate feedback.
 Ensure that the allocations are being followed.
Analysis of a RACI chart to identi fy weaknesses or areas for improvement
should include considering both the role and activity perspectives.
Potential problems with the RACI model:
 Having more than one person accountable for a process means that in
practice no one is accountable
 Delegat ion of responsibility or accountability without necessary
authority
 Focus on matching processes and activities with departments will lead
to confusion as the focus should be on roles.
 Incorrect division/combination of functions; conflicting agendas or
goals
9.4.5 Competenceand training: -
Delivering service successfully depends on personnel involved in service
management having the appropriate education, training, skills and
experience. People need to understand their role and how they contribute
to the o verall organization, services and processes to be effective and
motivated. As changes are made, job requirements, roles, responsibilities
and competencies should be updated if necessary. Each service lifecycle
stage depends on appropriate skills and experi ence of people and their
knowledge to make key decisions.
many organizations, personnel will deliver tasks appropriate to more than
one lifecycle stage. They may well find themselves allocated (fully or
partially) from operational tasks to support a design exercise and then
follow that service through service transition. They may then, via early life
support activities, move into support of the new or changed services that
they have been involved in designing and implementing into the live
environment. The specific roles within ITIL service management all munotes.in

Page 184

IT Service
Management
184 require specific skills, attributes and competences from the people
involved to enable them to work effectively and efficiently. However,
whatever the role, it is imperative that the person carrying out tha t role has
the following attributes:
 Awareness of the business priorities, objectives, and business drivers
 Awareness of the role IT plays in enabling the business objectives to
be met.
 Customer service skills
 Awareness of what IT can deliver to the busine ss, including latest
capabilities.
 The competence, knowledge, and information necessary to complete
their role.
 The ability to use, understand and interpret the best practice, policies,
and procedures to ensure adherence.
9.5 SUMMARY
In a nutshell, the Continual Service Improvement (CSI) process uses
methods from quality management to learn from past successes and
failures.Here we will cover everything about the processes in continual
service improvement, the managerial and supervisory aspects and more.
By the end, you will be able to:
 Understand and describe the knowledge, interpretation, and analysis of
improvement principles, techniques, and relationships, and their
application to ensure continual service improvement.
 Know what the seven -step improvement process is, how each step can
be applied, and the benefits produced.
 Know how CSI integrates with the other stages in the ITIL Service
Lifecycle
 Understand how other processes play key roles in the seven -step
improvement process.
9.6 QUESTIONS
1. What methods and techniques can be used in CSI activities?
2. Explain how assessment plays a key role in CSI activities.
3. Write a brief note on Gap Analysis.
4. Explain benchmarking in CSI with respect to its procedure, cost and
value to the organization. munotes.in

Page 185

Continual Service
Improvement Principles,
CSI Processes, CSI
Methods and Techniques
185 5. Explain steps in benchmarking techniques and the approach used for
benchmarking.
6. What is the objective of service measurement? What is the key to
service measurement?
7. Explain the importance of scorecards and reports in service
measurement.
8. Write a brief no te on:
a. Service Reporting
b. Return on Investment
9. Explain the role of Availability Management in CSI.
10. Explain the role of Capacity Management in CSI.
11. Explain the RACI model.
12. Explain the types of metrics that are used by an organization to support
CSI activities.
13. Explain the 7 -step improvement process.
14. List and explain the different levels of management and reporting.
15. Explain the Continual Service methods and techniques which can be
used to perform and interpret CSI initiatives.
16. Distinguish betwe en process and service owner.
17. Write a short note on authority matrix.
18. List and explain the primary responsibilities of CSI manager.
19. Define the various roles for processing and analysing the data.
20. Write a short note on the CSI inputs and outputs for the var ious stages.
21. Write a short note on CSI register.
9.7 REFERENCES
 ITIL v3 Foundation Complete Certification Kit
 ITIL v3 Service Strategy
 ITIL v3 Service Design
 ITIL v3 Service Transition
 ITIL v3 Service Operation
 ITIL v3 Continual Service Improvement

munotes.in

Page 186

186 10
ORGA NISING FOR CSI,
TECHNOLOGY CONSIDERATIONS
AND IMPLEMENTING CSI
Unit Structure:
10.0 Objectives
10.1 Tools to Support CSI Activities
10.2 Critical Consideration for Implementing CSI
10.3 Governance
10.4 CSI and Organizational Change
10.5 Communication and Strat egy Plan
10.6 Summary
10.7 Questions
10.8 References
10.0 OBJECTIVES
 CSI activities will require software tools to support tracking and
reporting on IT services as well as to underpin the ITSM processes.
 These tools will be used for data gathering, supervision , analysis,
reporting for services and will also assist in determining the efficiency
and effectiveness of IT service control processes .
 From a process perspective the use of tools enables centralizing of key
processes and automation and integ ration of core service management
processes.
 The raw data collected in the databases can be analyzed resulting in
the identification of trends.
 Preventive measures can then be implemented thus increasing
stability, reliability, and availability of the IT infrastructure.
10.1 TOOLS TO SUPPORT CSI ACTIVITIES
As part of the assessment of ‘Where do we want to be?’ the requirements
for enhancing tools need to be addressed and documented. Necessity and
sophistication of the tools required depend on the busine ss need for IT
services and, to some extent, the size of the organization. These tools can munotes.in

Page 187

Organising for CSI,
Technology Considerations
and Implementing CSI
187 be defined into broad categories that support and comment on various
aspects of the systems and service management domains:
IT Service Management Suites
The succes s of ITIL within the industry has encouraged software vendors
to provide tools and suites of tools that are highly compatible with the
ITIL process framework providing significant levels of integration
between the processes and their associated record type s. This feature
creates a rich source of data and creates many of the inputs to CSI
including:
 Incidents that capture the service or the Configuration Item (CI)
affected are a prime input to CSI enabling the understanding of the
issues that are affecting the overall service provision and related
support activities. Incident that matched the functionality allows the
Service Desk to quickly relate like issues and to create the master
records that highlight common situations that are affecting the users
with associated resolution data to enhance problem identification and
reduce the mean time to restore service (MTRS).
 Problems are defined with integrated links to the associated incidents
that confirmed their existence. Using the configuration data from the
CMS to understand the relationships, Managing Issues now has a
source of related data to enable the Root Cause Analysis process
including change and Release history of the affected CI or service.
 Changes are often the first area of investigation following a service
failure, again using the integration capabilities of the ITSM tool suite;
it can be easier to trace changes made to a service or a CI.
The CMS is the foundation for the integration of all ITSM tool
functionality and is a critical data source for the CSI mission. While the
service provider must still define the overall Configuration Management
process and create the data model that is associated with their specific
environment, the tools to establish and manage the CMS and the overall
service deliv ery architecture have become enormously powerful .
Systems and Network Management
These tools are typically specific to technology platforms that are under
management and are used to administer the various domains but can
provide a wide variety of data su pporting of the service management
mission. These tools generate error messages for event management and
correlation that feed the Incident Management and Availability
Management processes.
Many of these tools also support technology proprietary methods f or
software deployment within their domains and, as such, can provide
metric data in support of CSI alterations and Release Management and
dynamic updates to the CMS.
munotes.in

Page 188

IT Service
Management
188 Event Management
Events are status messages generated from the systems, network, and
application management platforms. These events are created when one of
the above tools senses a threshold has been met or an error condition is
discovered. The major issue with this capability is the significant volume
of messages that are created from both the actual event and the up - and
down -stream impact which can be difficult to determine the real issue.
Events are captured and assessed by rules -based, model -based and policy -
based correlation technologies that can interpret a sequence of events and
deriv e, isolate and report on the true cause and impact.
Automated Incident/Problem Resolution
There are many products in the marketplace which support the automation
of the traditional manual, labour -intensive and error -prone process of
incident and problem discovery and resolution. Utilizing data from
proactive detection monitors, any component or service outage generates
an alert that automatically triggers diagnosis and repair procedures. These
procedures then identify the root cause and fix the problem using pre -
programmed and scripted self -healing techniques reducing the MTRS of
many common causes of incidents and in some cases preventing service
outages completely.
Knowledge Management
There are specialist tools available that support and streamline th e
discipline of Knowledge Management. Providing efficient and accurate
access to previous cases with proven resolution data, these tools address
the symptoms associated with the current incident or problem. KM tools
also generate significant metrics design ed to measure the improvement
process itself.
Key CSI data adds transparency to incident recurrence and frequency,
utilization rates, the effectiveness of your stored resolutions and the
impact KM has on the efficacy of the overall support function.
Serv ice Request and Fulfilment
There are specialized tools that deal with Service Catalogue definition,
request management and the workflow associated with the fulfilment of
these requests. Some of these tools provide the workflow engines and
some rely heavil y on the capabilities of the companion ITSM suite. These
tools provide the technology required to define the services within a
catalogue structure in conjunction with the business customers and create
a service portal (normally web -based) that allows users to request services.
These tools typically also capture related cost data to be fed to the
financial systems for later charging activities.
Performance Management
Performance management tools allow for the collection of availability,
capacity, and perfo rmance data from a multitude of domains and platforms munotes.in

Page 189

Organising for CSI,
Technology Considerations
and Implementing CSI
189 within the IT infrastructure environment. This data is used to populate the
Availability and Capacity Management Information Systems (AMIS and
CMIS) giving IT organizations a historical, current and pro spective view
of performance, resource and service usage for offline analysis and
modelling activities. Capabilities of these tools include :
 Analysis of responsiveness, transaction and traffic throughput and
utilization levels supporting the balancing of resources to optimize
performance of the IT services
 Workload assessment with predictive trend analysis of future growth
and required capacity for each of the IT services being provided.
 Predictive performance technology enabling the evaluation of tuning
alternatives for systems, networks, databases, and applications that
support modelling of the expected outcomes
 Generation of the data required to submit a report on SLAs and
provide input to service Improvement plans.
Application and Service Performanc e Monitoring
There has always been a challenge related to understanding the true user
experience related to service provision. Recognizing this need, many
vendors provide tools that monitor the end -to-end delivery of essential
services , using either activ e or passive technologies, to fully instrument
and probe the many components of the service delivery chain. The
software provides key metrics such as availability, transaction throughput,
transaction response time, network latency, server efficiency, datab ase I/O
and SQL effectiveness. Usage trending data is vital for the Availability
and Capacity Management processes providing the information required to
assess current performance and plan for future growth.
Statistical Analysis Tools
Most of the tools t hat are available to support the service management and
systems management environments provide reporting capabilities, but this
is typically not enough to support robust Availability and Capacity
Management capabilities. Raw data from many of the above to ols needs to
be captured into a single repository for collective analysis. This is the data
that will provide input to the Availability and Capacity processes and
support the analysis of MTRS, MTBFs, SFA, Demand Management,
workload analysis, service model ling, application sizing and their related
opportunities for improvement. This type of software offers functionality
to logically group data, model current services and enable predictive
models to support future service growth by using a wide array of anal ysis
techniques.
Software Version Control/Software Configuration Management
These tools support the control of all mainframes, open systems, network,
and applications software providing a Definitive Media Library type munotes.in

Page 190

IT Service
Management
190 repository for the development envir onment. Information about the
version must connect seamlessly with the CMS and Release Management.
Software Test Management
These tools support the testing activities of Release Management and
deployment activities providing development, regression test ing, user
acceptance testing and pre -production QA testing environments. These
tools should integrate with Managing Incidents to capture testing -related
incidents that may affect the production version of the same software.
Security Management
These tool s support and protect the integrity of the network, systems and
applications, guarding against intrusion and inappropriate access and
usage. As in the systems and network management area, all security -
related equipment and software solutions should generat e alerts that will
trigger the auto -generation of incidents for management through the
normal processes.
Project and Portfolio Management
These tools support the registration, decision support, costing, resource
management, portfolio visibility and proje ct management of new business
functionality and the services and systems that underpin them. Integration
points include task assignments in development activities , change and
release build information based on the agreed portfolio, capture of
resource data from ITSM, TCO of portfolio and resource utilization data
to Financial Management, request management linkage to ITSM etc. This
tool is often used to underpin the Management Board approval process
related to strategic or major change projects.
Financial Management
Financial Management is a critical component of the IT services mission
to ensure that there are enough financial resources to maintain and develop
the IT infrastructure and professional capabilities in support of the current
and future needs o f the business. Financial Management tools collect raw
metering data from a variety of sources including operating systems,
databases, middleware, and software applications associating this usage to
users of services from specific departments. These tools will typically
federate with the organization’s Financial Management applications and
ERP system to acquire and share aggregate costs.
Business Intelligence/Reporting
In addition to a statistical analysis on the environment that requires a
toolset to sup port technical data, there is also a need for a common
repository of all service information and business -related data. Often these
tools are provided by the same vendors who support the statistical analysis
software but the focus in this instance is on pr oviding business -related
data from all the above toolsets representing a guide to guide the activities
of IT as a whole in support of the business customer. munotes.in

Page 191

Organising for CSI,
Technology Considerations
and Implementing CSI
191 10.2 CRITICAL CONSIDERATION FOR
IMPLEMENTING CSI
Before implementing CSI, it's important to hav e identified and filled the
critical roles that have been identified. This would include a CSI Manager,
Service Owner, and reporting analyst. A Service Level Manager is really
required to be the liaison between the business and IT. Monitoring and
reporting on technology metrics, process metrics and service metrics need
to be in place. These internal review meetings should take place before
any external review meeting with the business.
Where do I start?
Service Approach
An organization can choose to impl ement CSI activities in diverse ways .
One way is to identify a certain service pain point such as a service that is
not consistently achieving the desired results. Work with the Service
Owner to validate the desired results and the trend results over the p ast
few months. Review any monitoring was carried out . Even if there has not
been any component monitoring are conducted , review your Incident
tickets, and see if you can find some trends and consistent CIs that are
failing more than others that impact the service.
Lifecycle Approach
Another approach is to start looking at the handoff of output from the
different lifecycle domains. Service Design needs to monitor and report on
their activities and through trend evaluation and analysis, identify
improvemen t opportunities to implement. Need to do this by every part of
the lifecycle especially Service Design, Service Transition and Service
Operation. Until the service is realized , we may not know if the right
strategy was identified, so we may not have input until later for Service
Strategy improvement. CSI can be effective well before a service is
implemented into the production environment.
Functional Group Approach
Your organization is experiencing plenty of failures or issues with servers.
If this is the case, one could argue a good case to focus CSI activities
within the functional group responsible for the servers, as server failures
have a direct impact on service availability. This could be a pilot of CSI
activities before a full rollout across the or ganization.
10.3 GOVERNANCE
No matter if you are implementing CSI around service management or
services it is critical that governance will be targeted from a strategic
view. Organizations are facing the need to expand their IT service
management strateg ies from an operational level to tactical and strategic
levels to address business process automation, market globalization and
the increasing dependency on IT for the efficient and reliable management munotes.in

Page 192

IT Service
Management
192 and delivery of core business services. Most internal IT departments are
system/technology -management -based organizations which are reactive in
nature. Transforming to a service -management -based organization is more
initiative -taking in nature and is a step to aligning IT with business.
Implementing an ITSM p rocess governance organization will support the
development of and transformation to a process - and service -based
organization and provide the organizational infrastructure to manage
process improvement initiatives.
Implementing CSI will affect several pa rts of the IT organization.
Processes, people, technology, and management will undergo change. If
you only focus on changing a process or technology CSI will not be
effective. Figure 10 .1 identifies certain changes that may have to be
addressed . Process re -engineering chan ges everything.

Figure 10.1 Process re -engineering changes everything
10.4 CSI AND ORGANIZATIONAL CHANG E
Project management structures and frameworks fail to consider the softer
aspects involved in organizational change such as resistance to change,
gaining commitment, empowering, motivating, involving, and
communicating. Experience reveals that precisely these aspects that
prevent many CSI programmes from realizing their intended aims.
The first five steps in Table 10.1 identify the basic leadership actions
required. Those responsible for managing and steering the CSI programme
should consciously address these softer issues. Using an approach as John
P. Kotter’s Eight Steps to Transforming your organization , coupled with
formalized project management skills and practices, increase the chance of
success.
munotes.in

Page 193

Organising for CSI,
Technology Considerations
and Implementing CSI
193

Table 10.1 Eight steps that need to be implemente d, and the main
reasons why transformation efforts fail (from Kotter, 1996)
Half of all transformations fail to realize their goals due to the lack of
adequate attention on this step. Not enough people buy into a fact that the
change is necessary. Creating a sense of urgency is concerned with
answering the question ‘What if we do nothing?’ Answer to this question
for all organizational levels will help gain commitment and to provide
input to a business justification for investing in CSI. Power means more
than simply official power but also experience, matter , trust and
credibility. This team is the guiding coalition for the CSI.
The guiding coalition should be responsible for making sure that a flash -
forward is produced describing the aim and purpose of CSI . A good vision
statement can serve four important purposes:
 Clarify the direction of the program in the
 Motivate people to act in the proper direction
 Coordinating the actions of many different people
 Outline the aims of senior management.
The sense of urgency (‘What if we do nothing?’) and the vision (‘What’s
in it for me?’) should form the basis of all communication to the
stakeholders involved in or impacted by the CSI initiative. An important munotes.in

Page 194

IT Service
Management
194 aspect of the communication is walking the talk – expla ining by example.
In the empowering phase, two important aspects need to be stressed:
enabling and removing barriers. Empowerment means giving people the
tools, training and direction, and assurance that they will be provided to
clear and unambiguous fixed goals. Once people are competent , they are
accountable.
In CSI it is important to recognize short -, medium - and long -term wins.
Changes should sink deeply into the new culture, or the innovative
approaches will be fragile and subject to regression:
 Shor t-term wins have the characteristics of compelling , motivating
and showing immediate benefits and gains.
 Medium -term wins have the characteristics of confidence and
capability and having a set of working processes in place.
 Long -term wins have the charac teristics of self -learning and
expertise, and fully integrated processes that are self-learning and
improvement built into them; reaching this stage requires a baseline of
confident, capable delivery and real understanding.
Change needs to be established within the organization. Lot modifications
fail as they are not combined into everyday practice. This is akin to buying
a membership to a gym and not going.
Organizational culture is the whole of the ideas, corporate values, beliefs,
practices and expecta tions about behavior and daily customs that are
shared by the employees in an organization – the normal way of doing
things. Component parts of the culture include:
 The way power is exercised , and people rewarded
 Methods of communication
 The degrees of formality required in working hours and dress and the
extent to which procedures and regulations are imposed .
One could say culture is the significant part or a key issue in implementing
CSI. Culture could support an implementation, or it could be the bea rer of
resistance.
10.5 COMMUNICATION AND STRATEGY PLAN
Timely and effective communication is a significant part of any service
improvement project. The goal of the communications plan is to build and
maintain awareness, understanding, enthusiasm and tec hnical support
among key influential stakeholders for the CSI programme. When
developing a communication plan, it is important to understand that the
effective communication is not just based on a one -way flow of
information, and it is more than just meeti ngs. A communication plan
must incorporate the ability to deal with responses and feedback from the
targeted audiences. The plan should include a role to: munotes.in

Page 195

Organising for CSI,
Technology Considerations
and Implementing CSI
195  Design and deliver communications to the different CSI roles,
stakeholders such as other ITSM proced ure roles and identified target
audiences
 Identify forums for customers and user feedback
 Receive and deliver responses and feedback to the project manager
and/or process group members . Key activities for the communications
plan include:
 Identifying sta keholders and the target audiences
 Developing communications strategy and tactics on
 Identifying communication techniques and methods that
 Identifying the project milestones and other related communications
requirements.
An effective communication stra tegy and plan will focus on creating
awareness as to why the organization is going down to the path of
implementing service management, why we want to formalize a CSI
process, why ITIL was chosen as the best -practice framework. The plan
will also need to a ddress providing service management education through
formal training programmes or internal discussions , delivering formal
training on the new processes and tool that establishes new expectations as
well as providing updates as to progress and accomplishm ents.
A) Defining a communication plan: -
Defining your plan needs to take into consideration the following items:
 Who is the messenger? – This is often ignored about the importance
of aligning the messenger with the message. There are times when it is
appropriate for the CIO to deliver a communication. Another time it
may be a Service Owner or Process Owner who should be doing the
communicating.
 What is the message? – Define the purpose and objective of the
message. This needs to be adapted for the targe t audience. Keep in
mind the importance of communicating the benefits of the CSI
programme. The WIIFM (what’s -in-it-for-me) approach is still valid
and must be addressed . Reporting can be a message that was provided .
 Who is the target audience? – The targ et audience for CSI could be
senior management, mid -level managers or the staff that are going to
be tasked with performing CSI activities.
 Timing and frequency of communication – Be sure to plan and
execute your communication in a timely manner. The one constant
about managing change is that for communication is effective it will
take more than a one -time communication.
 Method of communication – The old standby of sending e -mails and
putting something on the web can work for some forms of
communication, but in order to effectively manage change it is munotes.in