Service Operation
Service Operation
ITIL® is a registered trade mark of the Cabinet Office. The Swirl logo™ is a trade mark of the Cabinet Office.
IT Infrastructure Library® is a registered trade mark of the Cabinet Office. 1
Lesson Objectives
Scope
ITIL Service Operation describes the processes, functions, organizations and tools
used to underpin the on-going activities required to deliver and support services.
• Technology
• People
Value to business
• Reduce unplanned labour and costs for both the business and IT.
Good communication is needed with other 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.
Communication types:
An event can be defined as any change of state that has significance for the
management of a configuration item (CI) or IT service.
Event Management provides the ability to detect events, make sense of them and
determine the appropriate action. This is the entry point for many processes and can
be used as the basis for automating routine operations.
Scope
Event management can be applied to any aspect of service management that needs
to be controlled and which can be automated.
Basic Concepts:
Event
An event is a change of state which has significance in the management of a
Configuration Item or IT service.
Alert
An alert is a warning that a threshold has been reached, something has changed, or
a failure has occurred.
Types of events
• Informational
• Warning
• Exception
• Ensure that standardized methods and procedures are used for efficient and
prompt response, analysis, documentation, on-going management and reporting
of incidents.
• Increased visibility and communication of incidents to business and IT support
staff.
• Maintain user satisfaction with the quality of IT services.
Scope
Incident management includes any event which disrupts or which could disrupt a
service. Incidents can also be reported and/or logged by technical staff. Although
both incidents and service requests are reported to the service desk, they are not the
same.
Timescales
Incident models
Major incidents
Incident status tracking
Prioritization can normally be determined by taking into account both the urgency of
the incident and the level of business impact it is causing.
In all cases, clear guidance with practical example should be provided for all support
staff during service level negotiations to enable them to determine the correct
urgency and impact levels, so the correct priority is allocated.
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. For each request, these activities should be documented into a request
model and stored in the SKMS.
Service Request
• A Service Request is a request from a user for information, advice, for standard
change or for access to an IT service.
• Most service requests are low-cost, low-risk and frequently performed changes.
Objectives
• Prevent problems and resulting incidents from happening.
• Eliminate recurring incidents.
• Minimize the impact of incidents that cannot be prevented.
Scope
Problem management includes the activities required to diagnose the root cause of
incidents and to determine the resolution to those problems. It is also responsible for
ensuring that the resolution is implemented through the appropriate control
procedures; especially change management and release and deployment
management.
The problem management process has both reactive and proactive aspects.
Problem models
Many problems will be unique and will require handling in an individual way, but it is
conceivable that some incidents may recur because of dormant or underlying
problems.
The problem management process flow for handling a recognized problem includes
the following steps:
• Problem detection
• Problem logging
• Problem categorization
• Problem prioritization
• Problem investigation and diagnosis
• Workarounds
• Raising a known error record
• Problem resolution
• Problem closure
• Major problem review
Basic Concepts:
Problem: A Problem is the cause of one or more incidents. The cause is not usually
known at the time a problem record is created, and the Problem Management
process is responsible for further investigation.
Known Error: A Known Error is a problem that has a documented root cause and a
workaround.
Known Error Database (KEDB): KEDB is a database that contains all Known Error
Records. It is created by Problem Management and used by Incident and Problem
Management.
Scope
Access management is effectively the execution of the policies in information security
management, in that it enables the organization to manage the confidentiality,
availability and integrity of the organization’s data and intellectual property.
Functions:
A function is a logical concept that refers to the people and automated measures that
execute a defined process, an activity or a combination of processes or activities.
Reference: Figure 6.2 Local Service Desk, page 159 (ITIL® SO) is reproduced
under license from The Cabinet Office.
Reference: Figure 6.3 Centralized Service Desk, page 160 (ITIL® SO) is reproduced
under license from The Cabinet Office.
Virtual Service Desk: Through the use of technology, particularly the internet, and the use of
corporate support tools, it is possible to give the impression of a single, centralized service desk
when in fact the personnel may be spread or located in any number or type of geographical or
structural locations.
Reference: Figure 6.4 Virtual Service Desk, page 161 (ITIL® SO) is reproduced under
license from The Cabinet Office.
Building functionality for their customer What the functionality is as well as how to deliver it
Manageability aspects of the application, i.e. how to
What the application does is more important than how it is ensure stability and performance of the application
operated
Management mode Most development work is done in projects where the focus is on Most of work is done as part of repeatable, on-going
delivering specific units of work to specification, on time and processes. A relatively small number of people work in
within budget projects
This means that it is often difficult for developers to understand & This means that it is very difficult for operational staff to
build for on-going operations, especially because they are not get involved in development projects, as that takes them
available for support of the application once they have moved on away from their on-going operational responsibilities
to the next project
Measurement Staff are typically rewarded for creativity and for completing one Staff are typically rewarded for consistency and for
project so that they can move on to the next project preventing unexpected events and unauthorized
functionality (e.g. ‘bells and whistles’ added by
developers)
Cost Development projects are relatively easy to quantify because the On-going management costs are often mixed in with the
resources are known and it is easy to link their expenses to a costs of other IT services because resources are often
specific application or IT service shred across multiple IT services and applications
Lifecycles Development staff focus on software development lifecycles, Staff involved in on-going management typically only
which highlight the dependencies for successful operation, but control one or two stages of these lifecycles- operation &
do not assign accountability for these improvement