lesson-12-service-operation-processes.pdf

ITIL Foundation Certicate in IT Service Management

Lesson 12 Study Guide Service Operation Processes

The ITIL Foundation Certificate in IT Service Management

www.itiltrainingzone.com

Page 1 of 28

2011 IT Training Zone LTD www.ITILTrainingZone.com

ITIL is a registered trademark of the Office of Government Commerce in the United Kingdom and other countries

Welcome to the twelfth chapter of your Study Guide. This document is

supplementary to the information available to you online, and should be used in

conjunction with the videos, quizzes and exercises.

After your subscription to the course has finished online, you will still have the Study Guide to

help you prepare for your exam - if youve not taken the exam by the time your subscription

expires.

Youll download a Study Guide at the end of most Lessons as you progress through the course.

This Chapter contains the Study Guide information for Lesson 12 Service Operation

Processes.

Use this Study Guide in conjunction with your own notes that you make as you progress

through the course. You may prefer to print the Study Guides out, or use them on-screen.

After each Lesson, you can consolidate what you have learnt whilst watching the videos and

taking the quizzes by reading through the chapter of the Study Guide.

If you progress on to the formal exam, your Study Guide will provide you with vital revision

information.

Remember, your Study Guide is yours to keep, even after your subscription to the course has

finished.

Service Operation Processes



Page 2 of 28



Study Guide Icons 3

Lesson Contents 4

Key Concept Communication 5

Exercise Communication 6

Incident Management 7

Event Management 15

Request Fulfillment 18

Access Management 19

Problem Management 20

Exercise Incident and Problem Management 27

Table of Contents



Page 3 of 28



Watch out for these icons as you use your Study Guide. Each icon highlights an important piece of information.

Tip this will remind you of something you need to take note of, or give

you some exam guidance.

Definition key concept or term that you need to understand and

remember.

Role a job title or responsibility associated with a process or function.

Exercise Solution suggested solution to one of the exercises you will

complete throughout the course.

Goal or Objective for a particular process or core volume.

Study Guide Icons



Page 4 of 28



This Lesson moved into the fourth stage of the service lifecycle Service

Operation. We started by looking at the Service Operation processes.

We studied:

Incident Management

Event Management

Request Fulfillment

Access Management

Problem Management

Text in "italics and quotation marks" is drawn from the ITIL core volumes Quoted ITIL text is from Service Strategy, Service Design, Service Transition, Service Operation and Continual Service Improvement

Crown copyright 2011 Reproduced under license from OGC.

Lesson Contents



Page 5 of 28



Service Operation is often made up of a number of different functions and roles.

Service Operation also often covers long service hours, usually providing out of hours support

and managing backups, batch jobs and overnight print runs.

Because of this, Service Operation has to ensure that communication between functional areas

and different shifts is well managed. Good communication between functions and roles will

help Service Operation to maintain service levels and meet the requirements of the business.

Communication within Service Operation can take the form of handover reports, logs,

timesheets, work flows, incident updates and a variety of different reports.

When a team is split geographically, communication is even more important, as staff may never

get the chance to talk face to face with one another.

Service Operation is also the lifecycle phase that has most contact with customers and end

users. For example, when a service is down, the communication issued to the business must be

useful.

Its important to always consider the audience when communicating what do they need to

know? All communication should be reviewed to make sure that the message is being

understood and the communication is useful.

Key Concept - Communication



Page 6 of 28



Exercise Communication

This Lesson included an Exercise to look at communication during a major incident. If you

didnt have time to complete the exercise during the Lesson, why not attempt it now?

Exercise

A major incident has occurred and your email system is unavailable. Prepare a communication

plan.

Who do you need to communicate with?

What do they need to know?

How will you communicate with them?

Exercise Solution

Who to communicate with

You will need to communicate with many different audiences, including:

Users and customers internal and external

Support teams

Management

Suppliers where relevant

Service owner

What do they need to know

Information needs to be tailored for each audience.

Users and customers will want to know when the service will be back,

and possibly why the outage has happened and what will be done to

prevent recurrence

Support teams need information to help coordinate the restoration

effort, along with guidance on priority and changes to impact or urgency

Management need to know what happened, why, and also the cost and

resolution information

Suppliers may be involved in the recovery effort or may be affected by

the outage

The service owner will need to be kept up to date all the way through the



Page 7 of 28



incident and also involved with the review

How will you communicate with them

Email wont be an option for obvious reasons! Again you will need to use

different media for your audiences.

Users and customers could be given information via the intranet, or

information could be shared with super users or pre-defined business

contacts

Support teams might use chat tools, or verbal communication

Management should get verbal updates along with documented

summaries of the situation if there is time

Suppliers will need to be kept up to date verbally, with information

documented if there is any contractual issue

The service owner will also get verbal updates

Remember, if you found this exercise challenging or have any questions, you can

email a tutor at [email protected].

The key points about communication are:

Interfaces must be defined

Communication channels, types and frequencies must be agreed

The efficiency of communication needs to be regularly reviewed



Page 8 of 28



The purpose of Incident Management is to restore normal Service as quickly as

possible - minimizing the downtime and impact on the business.

Incident

An unplanned interruption to an IT service or a

reduction in the quality of an IT service. The failure of a

configuration item that has not yet had any effect on a

service is also an incident.

Incident management objectives include:

Making sure that standard methods and procedures are used to optimize the handling

of incidents

Improving communication about incidents to IT and business staff

Improving the reputation of IT by managing incidents professionally

Prioritizing incidents according to business priorities

Maintaining user satisfaction with IT service quality

Incidents can be reported by users, technical staff or third parties. They may also be detected

by automated monitoring tools.

Incidents may also be identified by other processes such as Event Management, and then

passed onto Incident Management for resolution.

Incident Management exists to make sure that incidents are resolved as quickly as possible,

ensuring end users can be productive and have access to the IT services that they need.

Incident Management



Page 9 of 28



Service Operation fig. 4.3 Incident Management Process Flow

Crown copyright 2011. Reproduced under license from OGC



Page 10 of 28



Process

Step Explanation

Triggers

users and

technical

staff, other

ITIL processes

Triggers can be received either by web, monitoring tool, phone call,

email or face to face visit.

Incident

Identification

Once the Incident has been identified, the Service Desk will raise an

Incident record.

Is it an

Incident?

A Service Request is something that the Service Desk is asked to do

that is not triggered by an Incident. For example, resetting a password

or installing an approved piece of software.

Service Requests will be handled by the Request Fulfillment process,

and will have different SLA targets associated with them.

Incident

Logging

Every single incident must be recorded. These incident records are vital

for trend analysis and reporting.

Some organizations also allow users to log their own Incidents via a

web front end.

Incident

Categorization

Categorization is a high level way of splitting up Incidents, for example

into hardware and software, or individual services.

The correct categorization is really important for assigning the incident

to the correct support team and also for producing accurate incident

reports.

Many tools support multi level categorization, for example clicking on

hardware displays all hardware, which contains printers, clicking on

printers then displays all the makes and models.

Incident

Prioritization

Priority is worked out within ITIL by looking at two factors impact and

urgency.

Impact can be calculated by looking at information like the number of



Page 11 of 28



users affected, or the criticality of the service.

Urgency is a measure of how quickly the business needs the resolution.

By multiplying impact and urgency, the incident is given a priority.

Prioritizing Incidents enables the various support teams to work out

which incidents need to be addressed first.

Major

Incident?

Major incidents have severe levels of impact and urgency and will need

to involve additional management resources to ensure they are

resolved quickly.

Functional/

Hierarchical

Escalation

Functional and Hierarchical escalation can be invoked at any point.

Functional Escalation refers to progressing the Incident from Function

to Function (e.g. 2nd line support to 3rd line support).

Hierarchical Escalation is escalation up the management chain, possibly

to get more resources or visibility.

Investigation

and Diagnosis

This is normally started while the user is still on the phone, and this is

where the Service Desk will attempt a first time fix.

If no first time fix is possible, the Incident is passed to the appropriate

resolver group.

Resolution

and Recovery

Resolution and Recovery involves the restoration of service to the user.

The Incident status is typically set to resolved, and returns to the

Service Desk for closure.

Incident

Closure

It is important to note that the only functional area that closes

incidents is the Service Desk, with permission from the user affected.

Second line support teams will pass the Incident back to the Service

Desk after resolution - so that they can call the user and confirm the

user is happy for the Incident to be closed.

This final contact makes the Incident lifecycle a closed loop process and

ensures the users are satisfied.

The Service Desk will also take this opportunity to check if the initial

categorization of the Incident was indeed correct. If the categorization

was not correct, it may have been sent to the wrong team initially,



Page 12 of 28



losing valuable time during resolution.

If there are lots of incidents with incorrect categories, this may

highlight a training requirement for the Service Desk staff.

Example Priority Coding System

This table shows an example of a priority coding system.

Impact

Urgency High Medium Low

High 1 2 3

Medium 2 3 4

Low 3 4 5

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

Service Operation fig. 4.1 Simple priority coding system




Page 13 of 28



Incident Models

Incident Management uses Incident Models to allow it to deal with similar Incidents more

efficiently.

We looked at Change Models in the Service Transition Lesson a model is defined as a

repeatable way of doing something.

Incident Models work in the same way as Change Models. If we see the same Incident

frequently, we can develop a model to allow it to be dealt with in the most efficient way.

The Incident Model will include:

The steps that should be taken to handle the incident

The chronological order these steps should be taken in

Responsibilities

Timescales and thresholds

Escalation procedures

Any necessary evidence-preservation activities

The more we can apply models our Incidents, the faster we can carry out the required

resolution activities using the appropriate level of resources, at the right time.

All incidents must be managed according to business priorities and business criticality.

Timescales will be agreed for every stage of the incident lifecycle, based on the overall Service

Level Agreement. These will be documented in contracts or OLAs, and will ideally be

monitored automatically by the service management tool.



Page 14 of 28



Incident Management Interfaces

Incident Management needs to develop interfaces across the service lifecycle.

Service Design interfaces include:

Service Level Management the Service Level Agreements will help with incident

prioritization, and Incident Management can provide an early warning of any potential

SLA breaches

Capacity or Availability Management incidents may be related to a lack of Capacity or

indicate loss of availability and so supporting information is provided

Information Security Management security related incidents need to be managed and

fed back into Service Design for future improvement

Service Transition interfaces include:

Configuration Management the CMS is used to aid incident investigation and

resolution. The Service Desk can also help Configuration Management identify poorly

performing configuration items

Change management changes may be needed to resolve incidents, and incidents may

be linked to failed changes

Service Operation interfaces include:

Problem Management this process uses incident records for trend analysis

Access Management incidents may be related to unauthorized access or security

breaches. Incident history can be used to support security investigations

Remember: interfaces could mean incident management provides information to a process, or

receives information from a process.



Page 15 of 28



The purpose of Event Management is to be able to detect, analyze and take

appropriate action in relation to events, as well as to communicate event

information as required.

Successful Event Management means action can be taken to resolve events before Service

Levels are affected.

Event Management allows events to be identified before they cause incidents, allowing service

operation to take proactive action.

Event

An event is any change of state that has significance

for the management of a configuration item or service.

Events are managed by Alerts: ways of notifying people

who need to take action.

Events can trigger off many operational processes and activities, and they need to be managed

and prioritized in a similar way to incidents.

Event Management forms the basis of operational monitoring and control. The process will:

Detect changes of state

Determine the appropriate control action

Provide the trigger for many service management processes

Provide information to compare service performance against Service Level Agreements

Provide a basis for service reporting and improvement

Events happen all over our infrastructure, every day. Examples include:

A monitoring tool detecting a user has logged in

A read receipt confirming an email has arrived

A backup is confirmed as complete

A print job fails

Event Management



Page 16 of 28



Some events require action to be taken. Others will not.

Event management applies to any aspect of service management that needs to be controlled

and can be automated. This could include:

Configuration items

Environmental conditions such as air conditioning

Software license monitoring

Security

Normal activity

Event Categorization

Events are divided into three broad categories: informational, warning and exception.

Informational Informational events require no action but are stored for future reference. Examples of informational events would include a backup completing successfully, or a user logging into an application.

Warning Warning events signify unusual operation. Examples of this type of event could be a print job taking longer than normal to complete, or disk space reaching a pre-defined percentage. Warning events need to be assessed to see if action is required.

Exception Exception events often mean an SLA or OLA has been breached, and a service is not working as it should. Examples here could include a backup job failing, or a network link not responding. Exception events will require action, and many are escalated immediately to Incident, Problem or Change Management.

The diagram below shows the Event Management process. Notice how events may be passed

to the Incident, Problem or Change Management processes.



Page 17 of 28



Service Operation fig. 4.2 The Event Management process




Page 18 of 28



A service request is a generic description for all the services needed by users

that arent actual incidents or failures.

Service requests are often very small (or standard) changes they are also low risk and very

common. Examples include:

Password changes

Access to printers

Desk changes or moves

The Request Fulfillment process allows each service request to be effectively managed without

causing unnecessary strain or even bottlenecks in the incident and change management

processes.

Process Purpose and Objectives

The purpose of Request Fulfillment is to manage the lifecycle of each service request.

Request Fulfillment needs to manage any third party suppliers or procurement resources

involved in fulfilling the request.

The objectives of Request Fulfillment are to:

Maintain customer and user satisfaction through efficient and professional handling of

service requests

Provide a channel for users to request and receive standard services

Provide information to users and customers and services available and how to order

them

Source and deliver services

Assist with general information, complaints and comments

Within the ITIL model, Service Requests are usually received by the Service Desk staff. Many

teams can be involved in fulfilling a service request, including procurement teams, facilities and

even teams within the business areas.

The Service Desk team will follow the Incident Management and Request Fulfillment processes

handling each incident or request in the best possible way.

Request Fulfilment



Page 19 of 28



The purpose of Access Management is to provide the rights for users to access

services, executing policies as defined by Information Security Management.

Its important to remember that Access Management isnt setting the policy this is done by

Information Security Management during the Service Design phase.

The objectives of Access Management include:

Managing access to services based on policies and actions defined by Information

Security Management

Efficiently responding to requests for access

Changing or restricting access as required

Monitoring access to make sure it is not being abused

Access Management deals with Identity, Rights, Services, Directory Services and Access.

Access means the level of data or functionality that a user is entitled to use.

Identity refers to the information that identifies a specific user, for example a user ID and

password.

Services or Service Groups are created so that changes to users who access a specific

application, can be easily coordinated. Service Groups make access management for particular

service much simpler.

Directory Services are a specific type of tool used to manage access, for example Active

Directory.

Rights are the actual settings used to provide access within a service or application.

Access Management will be a major concern for many organizations. Its usually easy to

manage new users as and when they need their accounts setting up. When users leave the

organization, IT is not always informed and the accounts dont necessarily get closed or

deleted.

Access Management



Page 20 of 28



The objectives of problem Management are to:

Prevent problems and the resulting incidents from happening

Eliminate recurring incidents

Minimize the impact of incidents that cannot be prevented

Remember

Its important to distinguish between incident and problem

management.

Incident Management aims to restore service to the business as quickly

as possible.

This can often mean using temporary fixes for example if a PC

crashes, then the end user will often be told to reboot it.

Problem Management looks more deeply at the root cause of incidents.

For example - if the same PC crashed every day for seven days, incident

management would keep telling the user to restart.

Problem Management might also get involved at this point, to try and

work out why that PC kept crashing, and how the issue could be

permanently fixed.

The purpose of Problem Management is to identify and eliminate the

underlying root cause of one of more incidents.

Problem Management



Page 21 of 28



Problem Management Terminology

Problem

A problem is the unknown cause of one or more

incidents

It may also be referred to as the underlying or root cause.

The first time we know about most problems is when we have done some trend analysis from

our incident logs and we realize that we have a repeat or recurring incident.

Problem Management investigates the situation.

Problem Management exists to help Incident Management and maintain a quality service for

the business. To do this, it produces three main outputs workarounds, known errors and

requests for change.

Workaround

A workaround is a temporary fix produced by problem

management.

It is made available to the service desk to allow them to

resolve the incident more quickly for example,

restarting a PC.

Known Error

A known error is typically raised when the workaround

and root cause have been identified.

Known errors might be identified by development teams

or suppliers, as well as Problem Management.

Once the root cause of a problem has been identified,

the known error record can be created and stored in a

repository called the Known Error Database.



Page 22 of 28



Known Error

Database

(KEDB)

The KEDB is a source of information for Service Asset and

Configuration Management, as well as the Service Desk

who will use it to access workarounds.

Remember, a Known Error can be raised whenever it is

useful. This might even be before a workaround is

complete.

The third output from Problem Management is a request for change to permanently remove

the Known Error and stop the incidents happening again. A request for change may also be

raised for the workaround if necessary.

Problem Management can create Problem Models in order to provide a clearly defined

approach to a particular type of Problem.

Problem Management Activities

Problem Management has reactive and proactive activities. Reactive Problem Management

works to identify the root causes of incidents and remove them.

Proactive Problem Management tries to prevent incidents before they happen leading to an

improved service for the business. Proactive Problem Management techniques work to identify

weak spots within the infrastructure, or perhaps try to stop problems in one area happening

again in another area. It has strong links to Continual Service Improvement.



Page 23 of 28





Page 24 of 28



Service Operation fig. 4.7 Problem Management Process Flow




Page 25 of 28



Process

Step

Explanation

Problem

Detected

This can come from a number of different sources including the Service

Desk, suppliers or a trend analysis produced from Incident Records.

Problem

Logged

All the relevant details are recorded including who is affected, when it

happened and where it happened. The record will be date and time

stamped for reporting purposes.

Categorization Problem categories are likely to be the same as Incident categories, for

easy cross referencing.

Prioritization The priority is still based on Impact and Urgency, and the number of

Incidents related to this particular problem will factor into the impact

calculation.

Investigation

and Diagnosis

Investigation and diagnosis is carried out by the relevant technical

teams, with supervision from the Problem Manager. Different

analytical techniques are used to try and determine the actual root

cause of the problem.

Workaround? If a Workaround is established at this stage then this will be

documented and shared with the Service Desk who can begin to use

this information.

Create Known

Error Record

As soon as the Workaround is in place, a Known Error record is also

opened for informational purposes.



Page 26 of 28



A Known Error is typically not opened until a Workaround is in place

and the root cause has been established, but it can in theory, be

opened at any time.

Change

Needed?

Once the resolution has been found, an RFC will be raised if necessary.

Resolution The resolution is then implemented, and monitored to make sure the

problem really is resolved and has been truly eliminated.

Closure The Problem is closed with all relevant updates.

Major

Problem

Review

A review is held if needed to document any lessons learnt or ongoing

actions.

Problem Management delivers value to organizations by increasing the quality of IT services. If

long-standing problems are eliminated, then the number of Incidents decreases this means

that users are more productive. IT staff also become more productive, as their valuable time is

freed from fixing the same Incidents over and over again.

This can significantly reduce the cost of IT support.



Page 27 of 28



Problem Management Interfaces

Problem Management process interfaces include:

Financial Management: helps Problem Management to calculate the pain value of a

problem by assessing the cost of the related incidents

Change Management: will approve requests for change for any permanent solutions or

workarounds

Incident Management: provides incident records for trend analysis

Service Asset and Configuration Management: provides the CMS for problem

investigation identifying configuration items which may be causing problems

Exercise Incident and Problem Management

This Lesson included an Exercise to look at the roles of Incident and Problem Management. If

you didnt have time to complete the exercise during the Lesson, why not attempt it now?

Exercise

A PC is crashing repeatedly. It is interrupting the users access to the services they need to

carry out their role. A reboot of the PC typically provides an hour of service before the next

crash occurs. The user is frustrated and calls the service desk

Document the steps that incident management and problem management need to take to

achieve their process goals. Use the process flows to help you.



Page 28 of 28



Exercise Solution

The exercises ask about what steps Incident and Problem Management might

take in this situation.

Incident Management will want to resolve the situation as quickly as possible.

They will be asking questions to:

Establish the users identity

Find out if the incident has happened before

Understand when and how the incident happened

Try some fixes such as rebooting the PC

Ensure that no changes have occurred that might have affected the PC

Check the incident doesnt relate to an existing problem or Known Error

Problem Management will want to investigate to find the permanent resolution.

They will be asking questions to:

Establish if the incident occurred for this user before, or other users

Looking for existing problems and known errors

Try to find the root cause

Make sure a workaround is available

Raise an RFC is required for resolution

Report on the priority and affect of the problem

Hopefully you will have considered these questions and you may have come up

with additional ones.

Remember, if you found this exercise challenging or have any questions, you can

email a tutor at [email protected].

lesson-12-service-operation-processes.pdf

Documents

Transcript of lesson-12-service-operation-processes.pdf