Service Operation Processes

33
Processes in Service Operation Event Management

description

 

Transcript of Service Operation Processes

Page 1: Service Operation Processes

Processes in Service Operation

Event Management

Page 2: Service Operation Processes

Event Management

• GOAL– To detect Events, make sense of them, and determine

the appropriate control action to be provided by Event Management

• OBJECTIVE– To provide the entry point for the execution of many

Service Operation processes and activities

• SCOPE– Any aspect of Service Management that needs to be

controlled and which can be automated

Page 3: Service Operation Processes

Concept : Event

An event is a change of state that is significant for the management of Configuration Item or service

For example…This term is also used to mean an alert or notification.

Events typically IT Operations personnel to take action, and often lead to Incidents being logged

STATUS STATUS

STATUS STATUS

Action Needed Backup In Progress

IN MAINTENANCE UNAVAILABLE

AVAILABLEPROCESSING

UNAUTHORIZED ACCESS

SERVICE DEGRADED

Page 4: Service Operation Processes

Concept Of Alert

An Alert is a warning that…

• A threshold has been reached• Something has changed• A failure has ocurred

• Alerts are often created and managed by system management tools and are managed by the event management process

• The purpose of a alert is to ensure that the person with the skills appropriate to deal with the event is notified

CHANGE

Page 5: Service Operation Processes

Key Metrics

• No. of events by:– Category– Significance

• No. and % of events– That required human intervention and wheter this was performed– That resulted in Incidents or Changes– Caused by existing Problems or Known Errors– Compared with the number of Incidents

• No. and % of:– Repeated or duplicated events– Events indicating performance issues– Events indicating potential availability issues– Each type of events per platform or application

Page 6: Service Operation Processes

Implementation Challenges

Correct level of filtering

Rolling out necessary monitoring agents

Obtain funding

Acquiring necessary skills

Page 7: Service Operation Processes

Service Operation Processes

Incident Management

Page 8: Service Operation Processes

Incident Management

• GOAL– To restore normal service operation as quickly as possible

and minimize the adverse impact on business operations

• OBJECTIVE– To ensure that the best possible levels of service quality

and availability are maintained

• SCOPE– Incident Management includes any Events 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

Page 9: Service Operation Processes

Basic Concepts

• Timescales

• Incident model

• Major Incidents

NOTE: People sometimes use loose terminology and/or confuse a Major Incident with a Problem. In reality, an Incident remains an Incident forever – it may grow in impact or priority to become a Major Incident, but an Incident never ‘becomes a Problem’. A Problem is the unknown cause of one or more Incidents and remains a separate entity always.

Page 10: Service Operation Processes

Key Metrics

• Total numbers of Incidents– Breakdown at each stage

• Mean elapsed time to achieve Incident resolution to circumvention, broke down by impact code

• Percentage of Incidents handled within agreed response time

• Incident response-time• Average cost per Incident• Number and percentage of:

– Major incidents, backlog, incorrectly assigned or categorized– Resolved remotely, without the need for a visit

Page 11: Service Operation Processes

Implementation Challenges

• The ability to detect Incidents as early as possible

• Convincing all staff (technical teams as well as users) that all Incidents must be logged

• Availability of information about Problems and Known Errors

• Integration into the:– Configuration Management system (CMS)

– Service Level Management process (SLM)

– Service Knowledge Management System (SKMS

Page 12: Service Operation Processes

Service Operation Processes

Request Fulfillment

Page 13: Service Operation Processes

Request Fulfillment

• GOAL– To deal with Service Requests from the users/customers

• OBJECTIVE– To provide a channel for users to request and receive standard services

for which a predefined 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 services

(e.g. : licenses and software media)– To assist with general information, complaints or comments

• SCOPE– Each organization will need to decide and document which requests it

will handle through the Request Fulfillment process and which others will have to go through more formal Change Management process

Page 14: Service Operation Processes

Concept of the Service Request

The request from a user for information, advice, a standard change or access to an IT service.

– For Example :• To reset a password• To provide standard

IT services for a user

Service requests are usually handled by a Service Desk and do not require an RFC to be submitted.

Page 15: Service Operation Processes

Concept of the Request Model

The Request Model is a way of predefining the steps that should be taken to handle a process (in this case a process for dealing with a particular type of request) in an agreed way

Support tools can be used to manage the required process. This will ensure that standard requests are handled in a predefined path and within predefined timescales

Page 16: Service Operation Processes

Key Metrics

Backlog

Average Cost

Met SLA

~~~~~~~~~~~~~~~~~~~~~~~~

Did not meet SLA

~~~~~~~~~ Satisfaction Surveys

Page 17: Service Operation Processes

Implementations Challenges

Clearly defining and documenting the type of requests that will be handled within the Request Fulfillment process (and those that will either go through the

Service Desk and be handled as Incidents or those that will need to go through formal Change Management) – so that all parties are absolutely clear on the scope

Establishing self-help front-end capabilities that allow the users to interface successfully with the Request

Fulfillment process

Page 18: Service Operation Processes

Service Operation Processes

Problem Management

Page 19: Service Operation Processes

Problem Management

• GOAL– To diagnose the root cause of incidents, to determine

the resolution to those problems and to implement resolutions through appropriate control procedures

• OBJECTIVE– Primarily to prevent problems and resulting Incidents,

eliminate recurring Incidents and to minimize the impact of Incidents that cannot be prevented

• SCOPE– The Management of the lifecycle of all problems

Page 20: Service Operation Processes

Problem Management

Problem Management is the process responsible for managing the Lifecycle of all Problems

Problem Management consists of two major processes :

1. Reactive Problem Management is generally executed as part of Service Operation and is, therefore, covered in the Service Operation book

2. Proactive Problem Management is initiated in Service Operation, but is generally driven as part of Continual Service Improvement.

Page 21: Service Operation Processes

Problem

The unknown 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

Page 22: Service Operation Processes

• Chronological Analysis

• Pain Value Analysis

• Kepner and Tregoe

• Brainstorming

• Ishikawa Diagrams

• Pareto Analysis

Problem Investigation & Diagnosis

Page 23: Service Operation Processes

Workaround

• A technique which reduces or eliminates the impact of an incident or problem for which a full resolution is not yet

For Example…

• Restarting a failed Configuration Item

• Rerouting workload

• Workarounds for incidents that do not have associated problem records are documented in the incident record

Shared Data

Incident # xxxxCategory : …

Step 1 : …Step 2 : …Step 3 : …Step 4 : …

Page 24: Service Operation Processes

Known Error

A Problem that has a documented Root Cause and a Workaround

Known Errors are created and managed throughout their lifecycle by Problem Management. Known Errors may also be identified by development or suppliers

Root Cause Workaround Known Error

+ + =

Problem

Page 25: Service Operation Processes

Known Error Database ( KEDB )

• A database containing all Known Error records

• The purpose is to store previous knowledge of Incidents and Problems, and how they were overcome, to allow quicker diagnosis and resolution if they recur

• This database is created by Problem Management and used by Incident and Problem Management

• The Known Error Database is part of the Service Knowledge Management System

Known Error

Known Error

Known Error

Known Error

KEDB

Page 26: Service Operation Processes

Concept of The Problem Model

A problem model is a way of predefining the steps that should be taken to handle a process (in this case a process for dealing with a particular type of problem) in an agreed way

Support tools can then be used to manage the required process. This will ensure that ‘standard’ problems are handled in a pre-defined path and within pre-defined timescales

Page 27: Service Operation Processes

Key Metrics

• Total problem recorded

• % of problems resolved within SLA

• # or % problems that exceed resolution targets

• Aged problems

• Average cost per problem • # of Major problems

identified• # of Major problem

reviews conducted• Known Errors added to

KEDB

Page 28: Service Operation Processes

Implementation Challenges

• The establishment of an effective Incident Management process and tools

• Formal interfaces and common practices between the two processes

• Links between Incident and Problem Management tools• The ability to relate Incident and Problem Management Records• Second and third-line Staff need to have a good working

relationship with first-line staff• Business Impact is well understood by staff undertaking

investigation of problems• Problem Management is able to use all Knowledge and

Configuration Management resources available

Page 29: Service Operation Processes

Service Operation Processes

Access Management

Page 30: Service Operation Processes

• GOAL– To execute the policies and actions defined in

Security and Availability Management.

• OBJECTIVE– To provide the entry rights for users to be able to use

service or group of services

• SCOPE– Access Management ensures that users are given the

rights to use the service, but it does not ensure this access is available at all agreed times

Management

Page 31: Service Operation Processes

Concepts

• Access

• Identity

• Rights ( also called privileges )

• Services or service groups

• Directory services

Page 32: Service Operation Processes

Key Metrics

Number of …

– Requests for access ( Service Request, RFC, etc.)– Incidents requiring a reset of access rights– Incidents caused by incorrect access settings

Instances of access granted : By service, user , department, etc.

Page 33: Service Operation Processes

Implementation Challenges

Provision of a database of all users and the rights that they have been granted the

ability to…– Verify the identity of a user

– Verify the identity of the approving person of body

– Verify that a user qualifies for access to a specific service

– Link multiple access rights to an individual user

– Being able to determine the status of the user at any time

– Manage changes to a user’s access requirements

– Restrict access rights to unauthorized user’s