Incident Mgt OPS Guide

Government of Ontario IT Standard (GO-ITS)

Incident Management – OPS Process Guide

Document Number: 37

Version Number: 1.2

Status: Approved

Prepared for the Information Technology Standards Council (ITSC) under the delegated authority of the Management Board of Cabinet

© Queen's Printer for Ontario, 2007

Last Review Date: 2007-07-26 Next Review Date: 2008-06

GO-ITS 37 Status: Approved Version 1.2

Foreword Government of Ontario Information & Technology Standards are the official publications on the standards, guidelines, technical reports and preferred practices adopted by the Information Technology Standards Council under delegated authority of the Management Board of Cabinet. These publications support the Management Board Secretariat's responsibilities for coordinating standardization of Information and Technology in the Government of Ontario. Publications that set new or revised standards provide policy guidance and administrative information for their implementation. In particular, they describe where the application of a standard is mandatory and specify any qualifications governing its implementation.

© Queen's Printer for Ontario, 2007 2 Last Review Date: 2007-07-26 Next Review Date: 2008-06


Table Of Contents 1. INTRODUCTION ............................................................................................................ 4

1.1 Background and Purpose............................................................................................... 4 1.2 Scope............................................................................................................................. 8

1.1.1 In Scope: ............................................................................................................ 8 1.3 Applicability Statements ................................................................................................. 8 1.4 Requirements Levels ..................................................................................................... 9 1.5 Recommended Versioning and/or Change Management .............................................. 9 1.6 Publication Details........................................................................................................ 10

2. INCIDENT MANAGEMENT............................................................................................... 11 2.1 Common Process Principles ........................................................................................ 12 2.2 Process Roles.............................................................................................................. 16 2.3 Process Flow ............................................................................................................... 21 2.4 Common Process Metrics ............................................................................................ 24 2.5 Standard Process Parameters ..................................................................................... 25

3. RELATED STANDARDS .................................................................................................. 25 3.1 Impacts to Existing Standards...................................................................................... 25 3.2 Impacts to Existing Environment .................................................................................. 25

4. CONTACT INFORMATION............................................................................................... 26 5. ACKNOWLEDGEMENTS ................................................................................................. 27

5.1 Editors.......................................................................................................................... 27 5.2 Contributors ................................................................................................................. 27 5.3 (ITSD Contextual Model Core Team)........................................................................... 28

6. DOCUMENT HISTORY..................................................................................................... 28 7. COPYRIGHT INFORMATION ........................................................................................... 28 APPENDIX ............................................................................................................................ 29

A. Process Variances from OPS V1.4 Process Guides...................................................... 29 B. Standard Parameter Allowable Values .......................................................................... 33 C. Process Localization Guidelines.................................................................................... 33 D. Process Variances from ITIL ......................................................................................... 33 E. Data Requirements for Incident Recording.................................................................... 33

GLOSSARY .......................................................................................................................... 34 References......................................................................................................................... 42



1. Introduction

1.1 Background and Purpose Introduction to the Portable Process Guides

This standard process guide is part of a portable set of ITSM process documentation intended for use as a reference across the OPS. This documentation establishes the required OPS baseline for ITSM process adoption and describes what needs to be done.

A Key objective identified during OPS ITSM Planning workshops held in December 2003 was to “Define Standard Portable Elements for All ITSM Processes”. Hence, the guides were designed to be portable across all IT Clusters and Service Partners in the end-to-end OPS supply chain and were only designed to include the necessary process components that were required to be common across the OPS. Additional granularity and detail was to be developed at the local level as required.

The GO ITS 37 VERSION 1.1 used the OPS Standard Incident and Problem Management Process Guide version 1.4 (last updated in March, 2001) as its starting point. Changes were made for three reasons:

• Principles, Roles, Responsibilities and Processes that do not need to be specified OPS-wide were removed or streamlined.

• The guides were updated to reflect a maturing of the OPS in its implementation of the Incident Management Process.

• The guide was updated to reflect the evolution of ITIL best practices.

Appendix A outlines the key variances between the Standard ITSM Process Guide V1.4 and GO ITS 37 VERSION 1.1 OPS Portable Process Guide.

Version 1.2 of the GO ITS 37 builds upon this with the addition of two new Process Roles. They are directly related to the mandate provided to the Office of the Corporate Chief-Service Delivery by ITELC in October 2005 to establish a Single Point of Contact (SPOC) IT Service Desk function for the OPS.

These roles are the Partner Incident Management Liaison and Partner Knowledge Management and Support Model Liaison.

GO-ITS 44 ITSM Terminology Reference Model Portable Guide provides a common information model for key process parameters that require standardization across the OPS to ensure consistency, reliable business intelligence and to support end-to-end cross-jurisdictional service management. Please refer to this link for full text:

http://www.gov.on.ca/MGS/graphics/STEL02_047445.pdf


http://www.gov.on.ca/MGS/graphics/STEL02_047445.pdf


Rationale for Update:

In August 2005, Cabinet approved e-Ontario as the government’s I&IT strategy. The e-Ontario program has identified a number of transformational initiatives for the OPS. A number of these initiatives are focused on the consolidation and delivery of infrastructure technology services to the OPS. One such initiative is the Service Management project. Within the boundaries if this initiative, the Office of the Corporate Chief-Service Delivery (OCCSD) has been commissioned to implement the OPS IT Service Desk (ITSD) and to undertake the role of Incident Manager for service delivered through these consolidation initiatives:

This mandate is not limited to but will initially include: • Providing a single tier 1 OPS IT Service Desk for all users of OPS Technology • Consolidating existing tier 1 IT service desks (Cluster and business) (process,

hardware, and software) for users of OPS technology • Creating a single entity for consolidated infrastructure service provisioning (Service

Order Management) • Use of a common OPS-wide suite of technology / tools suite supporting ITSM

processes for the Service Desk and all tier 2+ support staff, for OCCSD-delivered services

In conjunction with this update, the ‘portable’ aspect of the Incident Management standard will be removed based on the ITELC-provided mandate to provide a single focal point within the Office of the Corporate Chief-Service Delivery (OCCSD) for OPS I Incident Management for I&IT enabled services.

This document is organized as follows:

Mandatory Sections of Standard:

Section 2.1 presents the Common Process Principles, which represent founding principles meant to guide the design and delivery of services to customers or users. The principles are meant to provide direction and guidance to areas of the process that may be ambiguous, unclear or contentious.

Section 2.2 presents the Process Roles, which should be viewed as a minimum required set of roles and responsibilities needed for the smooth functioning of the associated process. Two new roles of ‘Partner Incident Management Liaison’ and ‘Partner Knowledge Management and Support Model Liaison’ have been added to this section.

Section 2.3 presents the Process Flow as a high-level view of how the various sub-processes are expected to flow into and depend on one another. The sub-processes are also described in brief along with their expected output and/or completion criteria.

Section 2.5 refers to Standard Process Parameters, which are important for aiding in classification, categorization and prioritization of process objects, states and procedures. The Standard Process Parameters are described in detail in the GO-ITS 44 ITSM Terminology Reference Model Portable Guide. © Queen's Printer for Ontario, 2007 5 Last Review Date: 2007-07-26 Next Review Date: 2008-06


Appendix B refers to Standard Parameter Allowable Values, which are described in detail in the GO-ITS 44 ITSM Terminology Reference Model Portable Guide.

Suggested Only Sections of Standard

Section 2.4 presents an updated suite of suggested Common Process Metrics, which are intended to provide useful measurement of process effectiveness and efficiency, as well as aid in strategic decision support.

Appendices

Appendix A outlines the Process Variances from the original OPS Standard Process Guides (2001) and version 1.1 of the Incident Management Portable Process Guide (2004).

Appendix C originally offered some guidelines for Process Localization in the use of this particular standard. With the revised mandate provided to the OPS ITSD in 2005, there is no longer a need for localized versions of this Guide to be maintained by I&IT Clusters and partners in the OPS service chain. Specific additional standards regarding Incident Management have been captured in a separate / companion standard GO ITS 55.

Appendix D clarifies the OPS position on inter-relationship of Incident Management to Problem Management.

Appendix E suggests a minimum level of information that should be captured during the Incident Management life cycle.

Purpose of the Standard

With the government's increased priority on horizontality and inter-jurisdictional service delivery, organizations need to be quicker and more agile. Ensuring repeatable, consistent processes for end-to-end service delivery and support is an essential goal for I & IT contributing to the overall goals of innovation, effectiveness and efficiency. The continued expansion of common infrastructure services as well as service partners in the supply chain reinforces the need for consistency. The degree of adoption as well as localization of the existing incident management processes across the OPS has been varied as determined by readiness assessments conducted through the Service Desk initiative in 2003 and 2004. There was a recognition that the level at which the processes need to be consistent is not necessarily at the level of detail offered in the 2001 guides, but at a higher, "portable" level, thus the creation of the Portable Guide in 2004. Further evolution has resulted in the ITELC direction to establish a single Service Desk for the OPS within the OCCSD to create a focal point for Incident Management in the OPS.

Process Definition

The Incident Management process manages the day-to-day support interface between end users and service providers as well as minimizes service disruption to end users by the resolution of incidents that occur in the IT environment. Service Request and efficient first-level support are encompassed in this process.

The term “Incident” will be used throughout this guide to refer to all classes of incidents including “Service Requests” (such as requesting information or moving equipment).



Process Focus & Goals

The primary purpose of the Incident Management process is to manage incidents, provide support for business operations and produce management information.

The goals of this process are to restore normal service operation as quickly as possible, minimize the adverse impact on business operations and ensure that the best possible levels of service quality and availability are maintained according to SLAs.

Incident Management also serves as the information basis for an effective Problem Management process.

This process is triggered by service requests from end users and alarms, events or warnings from Operations Management.

Value to Organization

Benefits

Risk Reduction

Effective & timely functional and hierarchical escalations ensure the proper level of resources is brought to bear and bring the situation under control. Proper tracking and monitoring of incidents and effective linkage to Problem Management help provide early warning for potential service exposures.

Cost Reduction

Better utilization and increased productivity of skilled staff as well as decreased user downtime.

Service Agility Improvement

Better responsiveness to customers and faster incident resolution.

Service Quality Improvement

The provision of increased levels of service, additional customer focus and effective support for business applications will result in overall service quality improvement.



1.2 Scope

1.1.1 In Scope: The mandatory sections of this standard are as follows:

• Section 2.1: Common Process Principles

• Section 2.2: Process Roles

• Section 2.3: Process Flow

• Section 2.5: Standard Process Parameters

• Appendix B: Standard Parameter Allowable Values

Section 2.4: Common Process Metrics remains suggested only at this time.

The following is in scope of Incident Management process:

• Incident identification and recording

• Classification and initial support to the customers for the incident

• Investigation and diagnosis of Incidents

• Incident resolution and restoring service to its normal operation

• Communicating with the customer and closing the incident

1.2.2 Out of Scope: Any Information related to tools that support or implement the standard is considered outside the scope of this standard.

The following is out of scope of Incident Management Process:

• Event monitoring

• To always include a root cause analysis

• To always include a permanent / structural solution. A workaround may be sufficient

1.3 Applicability Statements Government of Ontario IT Standards and Enterprise Solutions and Services apply (are mandatory) for use by all ministries/clusters and to all former Schedule I and IV provincial government agencies under their present classification (Advisory, Regulatory, Adjudicative, Operational Service, Operational Enterprise, Trust or Crown Foundation) according to the current agency classification system.



Kindly refer to http://intra.pmed.mbs.gov.on.ca/mbc/pdf/Agency_Establishment&Accountability-Dir.pdf for a list of provincial government agencies with their classification under the current classification system, as well as their previous Schedule under the former Schedule system.

Additionally, this applies to any other new or existing agencies designated by Management Board of Cabinet as being subject to such publications, i.e. the GO-ITS publications and enterprise solutions and services - and particularly applies to Advisory, Regulatory, and Adjudicative Agencies (see also procurement link, OPS paragraph). Further included is any agency which, under the terms of its Memorandum of Understanding with its responsible Minister, is required to satisfy the mandatory requirements set out in any of the Management Board of Cabinet Directives (cf. Operational Service, Operational Enterprise, Trust, or Crown Foundation Agencies).

As new GO-IT standards are approved, they are deemed mandatory on a go-forward basis (Go-forward basis means at the next available project development or procurement opportunity).

When implementing or adopting any Government of Ontario IT standards or IT standards updates, ministries and I&IT Cluster must follow their organization's pre-approved policies and practices for ensuring that adequate change control, change management and risk mitigation mechanisms are in place and employed.

For the purposes of this document, any reference to ministries or the Government includes applicable agencies.

1.4 Requirements Levels Within this document, certain wording conventions are followed. There are precise requirements and obligations associated with the following terms:

Must This word, or the terms "REQUIRED" or "SHALL", means that the statement is an absolute requirement.

Should

This word, or the adjective "RECOMMENDED", means that there may exist valid reasons in particular circumstances to ignore the recommendation, but the full implications (e.g., business functionality, security, cost) must be understood and carefully weighed before

1.5 Recommended Versioning and/or Change Management Modifications during the life of the standard must be approved by the organizational owners of the document.

The organizational owners of this standard are:

Office of the Corporate Chief Technology Officer (OCCTO), Technology Adoption Branch

Ministry of Government Services will follow the Gating Process (approval process) as described in the Government of Ontario I&IT Directive, and submit proposed revisions to the


http://intra.pmed.mbs.gov.on.ca/mbc/pdf/Agency_Establishment&Accountability-Dir.pdf

http://www.ppitpb.gov.on.ca/mbs/psb/psb.nsf/english/agency_class.html

http://www.ppitpb.gov.on.ca/mbs/psb/psb.nsf/english/agency_class.html

http://www.itstandards.gov.on.ca/

http://www.ppitpb.gov.on.ca/mbs/psb/psb.nsf/english/vorlist-e.html

http://www.ppitpb.gov.on.ca/mbs/psb/psb.nsf/english/vorlist-e.html

http://www.ppitpb.gov.on.ca/mbs/psb/psb.nsf/english/bpsdef.html


Information Technology Standards Council (ITSC) and the Architecture Review Board (ARB) for approval and publication.

1.6 Publication Details All approved Government of Ontario IT Standards (GO-ITS) are published on the ITSC Intranet web site. Please indicate with a checkmark below if this standard is also to be published on the public, GO-ITS Internet Site.

Standard to be published on both the OPS Intranet and the GO-ITS Internet web site (available to the public, vendors etc.)



2. Incident Management Basic Concepts and Definitions:

Incident Management process is focused on restoring service availability by handling incidents occurring in the infrastructure or reported by users. This process seeks to minimize disruption to the users and manages the day-to-day support interface between users and service providers. Incident Management is focused on restoring services as quickly as possible to comply with SLAs or SLOs.

The priority of an Incident is primarily determined by the impact on the business and the urgency with which a resolution or work-around is needed. Targets for resolving Incidents or handling requests are generally defined in SLAs.

Incidents that cannot be resolved immediately by the Service Desk may be assigned to specialist groups. A resolution or work-around should be established as quickly as possible to restore the service to Users with minimum disruption to their work. After resolution of the cause of the Incident and restoration of the agreed service, the Incident is closed.

To allow any member of the IT support staff to provide a Customer with an up-to-date progress report, it is important that the Incident record be maintained throughout an Incident life-cycle. An audit history is also maintained since it is important when resolving issues of SLA breaches.

First, second-level and nth-level Support

The OPS IT Service Desk within OCCSD is referred to as the first level support. Subsequent assignments are referred to second-level or third-level support groups that have more specialist skills, time or other resources to solve Incidents. Third- and / or nth -level support may eventually include external suppliers.

Escalation (Functional versus Hierarchical)

Escalation is the mechanism that assists timely resolution of an Incident. It can take place during each activity in the Incident Management process.

Functional Escalation

Transferring an Incident from first-level to second-level support groups or further is called “Functional escalation” and primarily takes place due to lack of knowledge, expertise or required resources. Preferably, functional escalation also takes place before agreed time intervals elapse. The automatic functional escalation based on time intervals should be planned carefully and should not exceed the SLA resolution times.

Hierarchical Escalation

Bringing incidents to management attention for their action is called “Hierarchical Escalation”.



“Hierarchical escalation” can take place at any moment during the resolution process when it is likely that resolution of an Incident will not comply with service level objectives.

Automatic hierarchical escalation can be considered after a pre-specified time threshold is reached. Preferably, this takes place long enough before the SLA resolution time is exceeded so that corrective actions by authorized line management can be carried out (e.g. involving third-party specialists).

Inputs to the Incident Management process include: • CI data from Configuration Management • Service data from Service Level Management • Problem & Resolution data from Problem Management • RFC data from Change Management

Outputs from this process include:

• RFC for Incident resolution • Updated Incident record (including resolution and/or Work-around) • Resolved and closed Incidents • Communication to Customers • Management information (reports)

2.1 Common Process Principles IT organizations define principles to guide the design and delivery of services to customers or users. Principles can be common – that is they apply to all functions and groups - or local and apply specifically to a specific function or group.

The absence of well-defined common principles may result in processes that are neither aligned with customer expectations nor with the standards set for delivery of service.

Common principles for the OPS are listed below.

Principle 1:

A standard Incident Management Process is defined to provide support to all users.

Rationale:

• Decreased support costs & Improved support consistency

• Increased productivity of IT staff and Customers

• Increased Customer satisfaction

Implications:

• Existing Incident Management related processes, procedures and work instructions must be integrated



• Incident Management must be supported by an integrated IT support system with a common database for logging all incident & resolution information

Principle 2:

The Service Desk provides customers with a single point of contact for requesting technical support services.

Rationale:

• Improved clarity to Customer about where to get help

• Assistance and incident status information is always available through the entire incident lifecycle

• IT Specialists are protected from interruptions and can become more productive

Implications:

• End users need to perceive a single point of contact that has the ability to resolve incidents

• The Service Desk and technical staff may have to manage user expectations and may have to adjust their own behavior

• There will likely be cost implications as additional infrastructure & resources may be required to address increased support requests through a single point

Principle 3:

The Service Desk manages, tracks, escalates, closes and communicates status of all incident records and is responsible for all incident assignments

Rationale:

• Empowerment of first-level of support

• Better customer service

• Status information becomes available to end users

• Single point of accountability

Implications:

• Service Desk must be aware of any assignment of incidents among the different workgroups and levels of support

• The Service Desk is responsible for all open incidents and the incident manager becomes the ultimate owner of all incidents

• The Service Desk must play a key role in enforcing, and ensuring compliance with, the incident management process



• The Incident Manager has ultimate responsibility as manager of the Service Desk

• There may be resource implications

Principle 4:

The Incident Management Process is the conduit of communication of any degradation of service, to the affected users and IT personnel.

Rationale:

• End user expectations will be set appropriately and met consistently

• Reduced calls for help since end-users know what is happening

• End-users across the enterprise will have access information about incidents, problems and changes

Implications:

• The communication procedures, technology, and responsibilities will have to be defined and implemented

• The IT organization must learn to communicate to its customers and partners in simple and common language

• Additional training might be required for first-level support

• If Incidents are not classified clearly based on impact and urgency, it will be difficult to assess when notification is required

• Service level objectives need to be clearly defined, linked to incident classification and used to identify notification thresholds

Principle 5:

Closure of incidents is dependent on validating that the incident has been resolved and service is restored.

Rationale:

• End user is actively engaged and customer satisfaction is increased

• Process enhances the image of the IT organization

Implications:

• Process must include the final contact with the end user

• Customer’s agreement to the resolution must be confirmed prior to closing the incident

• Resolution and closure of an incident require separate statuses



Principle 6:

There is a defined escalation process that ensures timely resolution of Incidents in compliance with Service Level Agreements and Objectives (SLAs/SLOs).

Rationale:

• Timely closure of incidents

• Increased Customer satisfaction

• IT staff more effective due to a clear understanding of roles and responsibilities

Implications:

• Clear escalation triggers and escalation points must be defined for both functional and hierarchical escalation

• Links to the SLAs/SLOs need to be considered

• Status and priorities for incidents need to be determined

• Escalation points need to be accessible

Principle 7:

All incidents, as well as their solutions, are logged in an accessible Incident Management repository.

Rationale:

• Enables incident tracking

• Provides a knowledge base

• Provides an audit trail

Implications:

• All parties have to comply with incident logging, this includes external service providers

• A technology solution will be required

Principle 8:

All Service Providers will fulfill their roles in compliance with the OPS Incident Management process.

Rationale:

• Ensures consistency

• Service providers can play key roles in the process © Queen's Printer for Ontario, 2007 15 Last Review Date: 2007-07-26 Next Review Date: 2008-06


Implications:

• Process provisions will apply to internal and external service providers

• Contracts with service providers must reflect the Incident Management activities, tasks and linkages associated with their role

• Linkages to service provider Incident Management process must be defined

2.2 Process Roles Each process has specific roles with defined responsibilities for process design, development, execution and management. In an organization, one person can take on multiple roles as per the requirements specific to the organization. This person may choose to delegate these responsibilities to those lower in the hierarchy. Additionally, responsibilities of one role could be mapped to multiple individuals.

Regardless of specific organizational mapping, specific “portable” roles are necessary for the proper operation & management of the process. This section lists these roles and their responsibilities.

In addition to process roles, service-specific roles may be defined as part of the management and governance structure for a specific service. Other roles will also be involved in the Incident Management process activities, including operations, and service providers.

One role is accountable for each process activity. The role may assign one or more people who are responsible to carry out the task. However, it is ultimately the job of the person who is accountable to ensure that the “job gets done”.

Legend: Responsible, Accountable, Consulted before

Sub-Process

User Service Desk

Analyst

Second to nth Level Support

Escalation Manager

Incident Manager

2.0 - Contact Service Desk R

2.1 - Log Incident C R A

2.2 - Perform First Level Diagnosis & Resolution

R A

2.3 - Perform Second (nth) Level Diagnosis & Resolution

R A

2.4 - Manage Escalation AR

2.5 - Perform Diagnosis & Resolution for Exceptional Incidents

R A

2.6 - Close Incident C R A



2.2.1 Incident Management Process Owner The Process Owner owns the process and the supporting documentation for the process. The Process Owner provides process leadership to the IT organization by overseeing the process and ensuring that the process is followed by the organization. When the process isn't being followed or isn't working well, the Process Owner is responsible for identifying why and ensuring that required actions are taken to correct the situation. In addition, the Process Owner is responsible for the approval of all proposed changes to the process, and development of process improvement plans.

If the organization does not require the separation of roles (Process Owner and Process Manager), responsibilities listed below should be merged with that of the Incident manager role that follows.

Responsibilities

• Ensures that the process is defined, documented, maintained & communicated at a Enterprise and local level

• Reviews effectiveness and efficiency of the Incident Management process and Identifies opportunities for process improvement

• Is responsible for the success or failure of the process and has the authority to represent management on common process definition decisions

• Defines and develops Incident Management process common metrics and reporting requirements

• Ensures Incident Management processes and tools integrate with other ITSM processes and tools

• Is responsible for the requirement and guidelines of the Incident Management tool usage

• Ensures organizational adherence to the process

• Ensures adequate process training is available for the organization

• Manages changes to the process within a defined governance framework. This includes reviewing and approving all proposed changes and communicating changes to all the participants and affected areas

2.2.2 Incident Manager The Incident Manager executes the Incident Management process and coordinates all activities required to respond to incidents in compliance with SLAs and SLOs. The Incident manager is the ultimate owner of all incidents and is the normal incident management escalation point.



Responsibilities

• Ensures IT support staff have adequate skill levels

• Manages IT support staff performance of the Incident Management process, creates and executes action plans when necessary to ensure continuous improvement

• Manages incident resource allocation and workload distribution

• Monitors service delivered by the team for all customers being served

• Provides management information on IT service quality and customer satisfaction

• Requests the assignment of an Incident Escalation Manager when required

• Engages upper levels of management as appropriate

• Identifies potential Problems and informs the Problem Management team

• Identifies Process improvements

2.2.3 Escalation Manager (Situation Manager) The Escalation Manager is called upon by the Incident Manager to manage escalations of exceptional incidents meeting pre-specified criteria.

Responsibilities

• Owns, and is empowered to resolve, the escalated incident

• Performs escalation evaluations

• Coordinates the creation of resolution teams

• Provides Point-of-Contact for resolution teams

• Manages further escalations

• Manages all communications regarding escalated incident and ensures involvement of appropriate resources

• Invokes the disaster recovery process if required

• Conducts escalation post mortem reviews

2.2.4 Second to nth Level Support These levels of Support bring specialized and expert technical expertise to bear upon resolving Incidents.

Responsibilities

• Diagnoses and resolves complex incidents © Queen's Printer for Ontario, 2007 18 Last Review Date: 2007-07-26 Next Review Date: 2008-06


• Executes according to service levels

• Functionally escalates to higher-levels of support in accordance with applicable resolution thresholds

• Provides technical communication to customers & end users if required

• Detects potential problems and informs the incident manager

• Provides knowledge and training to first level support

• If required, interfaces with third party vendors for incident resolution

• Keeps first-level support informed at all times

2.2.5 Service Desk Analyst The Service Desk Analyst role is the first role that the customer will interface with on an initial entry into the process.

Responsibilities

• Welcomes authorized callers, as entry point into Incident Management process, by phone, web, mail, or other authorized means

• Authenticates the caller (User)

• Creates an Incident record for new incidents into the incident control system

• Updates the case for existing incidents into the incident control system

• Classifies and categorizes the incident

• Applies procedures applicable to the customer / Authorized caller / categories

o Qualifies Incident as covered by SLA

o Prioritizes incident

o Assigns and transfers (route) incident to relevant area of support

• Attempts Incident resolution

• Understands the service level and executes accordingly

• Provides technical communication to User about quick fixes

• Obtains User agreement that the resolution provided addressed their needs prior to Incident closure

• Closes incidents



2.2.6 Partner Incident Management Liaison The Partner Liaison is responsible to provide point of contact within partner organizations (e.g. Clusters, OCCSD, CCAS etc.) to enable effective and efficient execution of the IM process.

Responsibilities

• Collect IM process improvement recommendations / requirements and take part in Service Improvement Project (SIP) activities

• VIP list management

• Partner organization information management relative to IM process (e.g. Location details, organization structure/changes etc.)

• Provide key cluster contact information to Incident Coordinator

• Provide specific persons names to be granted VIP services

• Perform internal provider organization notifications/escalations that extend beyond Incident Management defined notifications

• Address process exceptions and deviations with the Incident Manager

• Recommend process improvements to the Incident Manager

2.2.7 Partner Knowledge Management and Support Model Liaison The Knowledge Management and Support Model Liaison is the OPS ITSD’s primary contact within the partner organization for the identification, documentation and maintenance of partner solution/service knowledge and Tier 2/3 Support Model management.

Responsibilities

• Coordination of knowledge required by the OPS ITSD Incident Agents such as service/solution descriptions, diagnostic content, mandatory information capture (i.e. Templated information Tier 1 must capture) and First Point of Contact (FPOC) resolution steps

• Management of any knowledge updates driven by the partner, which may result in updated knowledge being passed to the OPS ITSD

• Documentation of partner service/solution support model information identifying incident routing (where FPOC resolution not possible), support group and partner incident analyst coordination (and administration where appropriate)

• Management of any support model updates driven by the partner, which may result in updating routing details being passed to the OPS ITSD (or administrated directly where appropriate)



2.3 Process Flow 2.3.1 Incident Management Generic Process Flow

Incident Managementt Process Overview

2.1Log Incident

2.6Close Incident2.2

Perform FirstLevel

Diagnosis &Resolution

2.4Manage

Escalation

2.3Perform Second

(nth) LevelDiagnosis &Resolution

ServiceDesk

Analyst

Second(nth)Level

Support

IncidentManager

EscalationManager

2.5Manages

Diagnosis &Resolution forExceptional

Incidents

User2.0

Contact ServiceDesk

ExceptionalIncident

Figure: 1 Incident Process Overview

No.

Sub-Process

Input / Trigger

Description Output / Completion criteria

Common

Incident record status

2.0 Contact Service Desk

Request from User

User initiates process by contacting Service Desk through appropriate channel (e.g. email, phone)

An Incident may also be a service request, e.g., a request for memory upgrade.

Incident New

2.1 Log Incident

Trigger: Automated incident

Incident is received by the Service Desk Analyst and reviewed to assess whether this

Incident registration

New



No. Sub- Input / Description Output / Common

Process Trigger Completi

Incident on criteria record status

received from an event management system, Service call by phone, email, web interface, entered directly into Service Desk

is a new incident, a duplicate incident or an incident that is related to an incident, which is currently open.

Service Desk Analyst authenticates Caller; call information is reviewed to make sure it is complete. The incident is classified and is prioritized based on urgency and impact

2.2 Perform First Level Diagnosis & Resolution

Input: Registered Incident

The support area will review the details, analyze to diagnose, and identify the required course of action to resolve the incident as quickly as possible.

Incidents that cannot be resolved at this level and /or need management intervention will be escalated

Exceptional incidents will be escalated to the Incident Manager to determine whether Escalation Manager is required.

Incident resolution

Unresolved incident escalation to next level support and document reasons for escalation

Assigned

In Progress

Pending

Restored / Fulfilled

2.3 Perform Second (nth) Level Diagnosis & Resolution

Input: Incident assigned by Service Desk Analyst

The assigned support area will review the details, analyze to diagnose, and identify the required course of action to resolve the incident as quickly as possible.

Incidents that cannot be resolved at these levels and /or need management intervention will be escalated to the Incident

Incident resolution

Unresolved incident escalation to next level support and document reasons

Assigned

In Progress

Pending




No. Sub- Input / Description Output / Common

Process Trigger Completi

Incident on criteria record status

Manager. for escalation

2.4

Manage Escalation

Input: Escalation Criteria

Escalation raises the visibility of the Incident to the Incident Manager who decides whether an escalation manager is required.

Escalated incidents are still “owned”, tracked and managed within the Incident Management process, but ownership of the Incident transfers to the Escalation Manager.

Assign to second or nth level.

Incident

Assigned

In Progress

Pending

2.5 Manages Diagnosis and Resolution for Exceptional Incidents

Input: Incidents assigned by Incident Manager

The Escalation Manager reviews the incident details, and build a team of experts to analyze diagnose, and identify the required course of action to resolve the incident as quickly as possible.

Incident resolution

In Progress

Pending


2.6 Close Incident

Input: Resolve Incident Escalated Incidents

Once the incident has been resolved and /or service has been delivered, the support level that performed the work transfers the Incident to the Service Desk Analyst for closure. The Service Desk Analyst will review the details of the case and communicates with the User to gauge satisfactory level before closing the incident record

Incident closure

User Feedback / satisfaction, Process improve-ment planning


Closed

It is important to note ongoing Incident monitoring as a parallel process activity. The responsibility for monitoring is assigned at the Incident Manager and/or the Analyst level.

These periodic activities allow Incident Management personnel to keep track of Incidents, to identify any exceptions and to answer any questions that may come from Clients.



2.3.2 Incident Management Process Quality Control In parallel to the execution of the Incident Management process, there are activities related to the management of the process to control quality as well as to ensure that the process is both effective and efficient.

Monitoring of the service delivered by the Incident Management team is performed regularly by the Incident Manager. This allows the Incident Manager to answer any questions about service quality and customer satisfaction as well as ensure that the Incident Management process is not running into resource or ownership issues. The Incident Manager is responsible to take corrective actions if bottlenecks are identified in the process.

Reporting involves measuring the process via metrics and recording how well it behaves with respect to its metrics. It provides the Incident Management personnel with feedback on the process. It provides the Incident Management Process Owner with the necessary information to review the process performance and initiate required improvements.

Evaluating the process involves regular reviews of the performance of the process and identification of possible improvements or actions to address performance gaps. Every process is only as good as its last improvement; hence, the feedback loop of continuous improvement is inherent in every process.

2.4 Common Process Metrics Metrics are intended to provide a useful measurement of a process effectiveness and efficiency. Metrics are also required for strategic decision support. The following need careful consideration:

• Reporting metrics should be readily measurable (preferably automated collection and presentation of data)

• Metrics need to be chosen to reflect process activity (how much work is done?), process quality (how well was it done?) and process operation (to review and plan job on hand). Depending upon the needs of the organization, metrics can be classified as “hard (must have)” or “soft (desirable)”

• Hard metrics will be common across an organization

The following common metrics are suggested for the OPS Incident Management process: • Total number of Incidents • % reduction in MTTR (mean time to

resolve)

• Number and percentage of Incidents by priority

• % reduction in the # of tickets that were not created by the Service Desk

• Number of incidents processed per Service Desk Analyst

• % of Incidents resolved by 1st line support

• Number and percentage of Incidents by product category

• Average time for 2nd level support to respond

• Top 5 incident types by frequency • % of incidents handled within agreed response time (Incident response-time



targets may be specified in SLAs, for example, by impact code)

• % increase in the incidents resolved by the Service Desk

• Average cost per Incident

• % increase in the incidents resolved by the Service Desk on first response

• % of incidents logged and resolved by Tier 2, without being assigned to Tier 1

• % reduction in referrals • # of incidents by incident type (based on OPS TRM)

• % reduction in incidents that require re-classification based on Service Category

• Customer Satisfaction

• % reduction in incidents that require re-classification based on Component category

2.5 Standard Process Parameters Parameters used for the classification, categorization, prioritization and closure of Incidents require a certain level of standardization across OPS. Special attention needs to be given to parameters related to consistency of reporting. This is particularly important for the provision of reliable business intelligence. Please refer to the Classification Model section of the GO-ITS 44 ITSM Terminology Reference Model Portable Guide for standard process parameters and allowable values for Incident Management. Please refer to the State Model section of the GO-ITS 44 ITSM Terminology Reference Model Portable Guide for standard status/state parameters and their definitions for Incident Management. See Appendix E for Data Requirements for Incident Recording.

3. Related Standards

3.1 Impacts to Existing Standards No Impact.

3.2 Impacts to Existing Environment No Impact.



4. Contact Information Contact 1 Contact 2

Full Name: Doretta Ojeda Norm Watt

Job Title: Standards Program Coordinator

Lead Enterprise ITSM Program

Organization: Ministry of Government Services

Ministry of Government Services

Division: Office of the Corporate Chief Technology Officer (OCCTO)

Office of the Corporate Chief Technology Officer (OCCTO)

Branch: Technology Adoption Branch (TAB)

Technology Adoption Branch (TAB)

Office Phone: 416-327-2094 416-327-3542

E-mail Address: [email protected] [email protected]



5. Acknowledgements List this document’s editors, contributors and reviewers below including general location information. This includes individuals and/or groups of individuals that provided subject expertise and contacts designated to receive comments, feedback, questions or suggestions.

5.1 Editors Name Cluster/Ministry Branch

Norm Watt OCCTO Technology Adoption Branch

Asim Masoodi OCCTO Technology Adoption Branch

5.2 Contributors Name Cluster/Ministry Branch


Rick Guyatt OCCTO Technology Adoption Branch

Eion Gomes OCCTO Technology Adoption Branch

John Hand CAC

Stephane Vertefeuille Corporate Security

Brian Savard CSC

Kathy Beaton CYSSC

Jim McPherson CYSSC

Lucille Gauthier ETC

Jack Tao ETC

Tim Bondett ETC

Kevin Griffin GSDC

Ryan Rossman GSDC

Hope Knox HSC

Glen Babcock HSC

Irene McGlashan JC

Charles Talbot JC

Mary Horbatuk LRC



Colleen Martin LRC

Gideon Chiang FFS Consultant On Assignment to OCCSD

5.3 (ITSD Contextual Model Core Team) Name Cluster/Ministry Branch


Rick Guyatt OCCTO Technology Adoption Branch

Eion Gomes OCCTO Technology Adoption Branch

Wynnann Rose OCCSD Service Management

Christian Gingras OCCSD Service Management

Maxwell Keeping OCCSD Service Management

Michael Oas FFS Consultant On Assignment to OCCSD

Scott Gow OCCS E-Government Branch

6. Document History Created: Original GO ITS 37 Version 1.1 Date 2004-04-01

Updated: 2007-04-27 • Additional Background regarding e-Ontario Mandate in Section 1.1 • Addition of 2 new Process Roles in Sections 2.2.6 and 2.2.7 • Revised list of suggested Incident Management metrics in Section 2.4 • Deletion of Appendix C – Elimination of concept of Local Process Guides for Cluster

Incident Management as the ITSD Contextual Model proposed as part of GO ITS 55 will over-ride the requirement for creation of documentation of this type.

Updated: 2007-07-26

• Approved by the Architecture Review Board (ARB)

7. Copyright Information © Queen's Printer for Ontario 2007.



Appendix

A. Process Variances from OPS V1.4 Process Guides The following tables provide the detail of the specific variances from the previous OPS guides with respect to principles, roles and responsibilities, and process flow. As noted in the introduction, the purpose of these new guides is to provide the portable elements needed to be common across the OPS. As such, some principles, responsibilities, and aspects of the process flow were too specific to apply across the OPS.

Table 1 - Incident Management Principles

Portable

Process

Guide (2004)

OPS Standard Process Guide (2001)

Principle No.

Section No.

Policy No.

Sam

e M

odifi

ed

New

R

emov

ed Explanation

1 5.1 1 X 2 5.1 2 X

3 5.1 5 X

In the OPS standard Process Guide, the person who opens an incident is the owner of the incident, while in the Portable Process Guide, the entire Service Desk has the ownership of the incidents.

3 5.1 8 X 4 5.1 6 X 5 5.1 9 X 6 5.1 10 X 7 5.1 4 X

8 X Added to reflect increased involvement of service providers in Incident Management.

5.1 3

X

Not required: “The Incident Management Process acts as an agent for recording and resolving all I.T. (including Voice & Data Services) support requests including requests to other support agencies.”

5.1 7 XProcedural: “There will be clear linkage between Incident records, Problem records, known Errors and Request for Change”

5.2 1 X

Not required: “A team or Group will be identified which will ensure compliance with standards. They will work closely with the teams who establish standards.



Portab

le OPS Standard Proce Process

ss Guide Guide (2001) (2004)

All Policies and Standards will be enforced. Incident Management Process will only be responsible to support standard applications / hardware.”

5.2 2 X Not required: “The organization will define the core Desktop Environment for the Client.”

5.2 3 XNot required: “All SLA’s will include the level and scope of support provided by the Incident Management process for all Clients.”

5.2 4 X

Not required: “Metrics will be collected to measure the effectiveness and efficiency of key IT services, support processes, and improvement projects to ensure SLAs are met.”

5.2 6 X

Procedural: “The Incident Management process will provide services for products currently on the Incident Management process Supported Products List in the CMDB”

PLEASE NOTE: In the OPS Standard Process Guides (2001), policies were not originally numbered. To identify them for comparison, they have been assigned numbers here according to the order in which they appear in their section of the Guide.

Table 2 - Incident Management Roles Portable Process Guide (2004)

OPS Standard Process Guide

(2001)

Role Secti

on No.

Role

Sam

e M

odifi

ed

New

R

emov

ed

Explanation

Incident Management

Process Owner

2.1.4 Proces

s Owner

X

Added to reflect clearly the responsibilities around process definition support and evolution



Portable OPS Standard Process Process Guide Guide (2001) (2004)

Incident Manager 4.1

Incident Proces

s Manag

er

X

Additional responsibilities: - Request the assignment of an Incident Escalation Manager when required Removed responsibilities: - Responsibilities related to an Incident Management tool - Responsible for retrieving accurate and complete data for the Problem Analysis - The Incident Management process is the primary contact point for the I.T. organization to disseminate operational information to the Client.

Escalation Manager 4.8

Situation

Manager

X

- Additional responsibilities invoke the disaster recovery process if required.

Second to nth Level Support

4.5 4.6

Senior Incident Support Analyst

/ Service Provide

r

X

Support responsibilities of Support Analyst and Service Provider now covered under nth level support. Removed responsibilities: - Identify Major Incidents - Create requests for change to CIs if known error is clear - Accept ownership of all incidents dispatched to them unless they are further dispatched.

Service Desk Analyst 4.3

Incident Support Agent

X

Previously, the ownership and consequently the responsibility for the incident closure was transferred, when an incident was dispatched to a Senior Support Analyst. Now, this role is responsible for closure of all Incidents.

4.8

On-site Support Resour

ce

X

- Removed as not required in a Portable guide

4.9 Operations X

- Removed as not required in a Portable guide.



Table 3 - Incident Management Process

Portable Process Guide (2004)

OPS Standard Process Guide

(2001)

Process Section No. Process

Sam

e M

odifi

ed

New

R

emov

ed

Explanation

(2.0) Contact Service Desk 5.2.1

Contact Incident

ManagementX

5.2.2 Receive Incident

Notification (2.1) Log Incident

5.2.3 Log Incident and Assign

Severity

X

5.2.4 Resolve Incident

(2.2) Perform First Level

Diagnosis & Resolution 5.2.5 Incident

Dispatch

X

Modified: - Exceptional Incidents are now escalated to Incident Manager rather than Escalation Manager.

5.2.5 Incident Dispatch

5.2.6 Service

Restoral or Fulfillment

(2.3) Perform Second (nth)

Level Diagnosis & Resolution 5.2.7 Monitor

Action

X

Modified: - Exceptional Incidents are now escalated to Incident Manager rather than Escalation Manager.

(2.4) Manage Escalation

(2.5) Perform Diagnosis &

Resolution for Exceptional

Incidents

5.2.8 Manage Situation X

Modified: - Incident Manager assigns an Escalation Manager to deal with an exceptional (Major) incident.

(2.6) Close Incident 5.2.9 Close

Incident X

5.2.10 Report Metrics X - Removed as not required to

specify for portable guide

5.2.11

Evaluate Process for Continuous

Improvement

X

- Removed as not required to specify for portable guide



B. Standard Parameter Allowable Values Please refer to the Classification Model section of the GO-ITS 44 ITSM Terminology Reference Model Portable Guide for standard process parameters and allowable values for Incident Management. Please refer to the State Model section of the GO-ITS 44 ITSM Terminology Reference Model Portable Guide for standard status/state parameters and their definitions for Incident Management.

C. Process Localization Guidelines Portable guide content typically applies to all organizations and groups within the OPS. Localization involves adding group-specific information that applies to a particular organization or group. For every group, local content will focus on what’s important for the particular environment.

In the case of Incident Management, the mandate provided through ITELC to the OCCSD has directed the OPS ITSD to manage and maintain the Incident Management process for the OPS. Detailed specific standard, procedures and roles are available through GO ITS 55.

D. Process Variances from ITIL Problem Management has been separated in the OPS as a process requiring proactive effort and involvement as compared to the reactive nature of Incident Management process.

The Incident Management process in the OPS also covers Service Request handling.

Incidents of high impact are not currently escalated to the Problem Management process as prescribed in ITIL / ITSM documentation.

This is a conscious deviation to ensure that the OPS Problem Management process will focus on ‘proactive’ service improvement initiatives rather than ‘reactive’ firefighting.

E. Data Requirements for Incident Recording The following data should be recorded during the Incident life cycle

• Unique reference number

• Incident Classification parameters:

o Component Category

o Service Category

o Type

o Impact



o Urgency

o Priority

o Closure Code (Reason Category)

• Date and time recorded

• Name, employee ID of the person and / or group recording the Incident

• Name department phone location of Users calling

• Call-back method (telephone, mail etc)

• Description of symptoms

• Incident status

• Related CI

• Support group or person to which the Incident is assigned

• Resolution and closure date, time, and by whom

Glossary

A glossary of terms used in this guide is provided below:

Term Description Asset Management A standard accounting process concerned with

maintaining the details of assets above a specified value, including depreciation, lease agreement information, expected life, etc. Asset management does not track the relationship between assets and may not track each individual item purchased or leased as part of a “bundle” purchase. (For example, asset management would track the fact that 100 personal computers were purchased, but would not track the individual units.) Configuration Management would typically track the individual PCs.

Availability Ability of a component or service to perform its required function at a stated instant or over a stated period of time. Generally, availability is expressed as the availability ratio, which is the proportion of time that the service is actually available for use by the Customers within the agreed service hours.



Term Description Availability Management

A process that focuses on understanding and managing availability requirement of the business.

Change Advisory Board (CAB)

An advisory committee that provides expert advice to the change manager on change issues

Change Advisory Board Emergency Committee (CAB/EC)

A subset of the CAB that is always available to be called upon to address urgent change issues

Capacity Management A process that aims at ensuring that the capacity of the IT infrastructure matches current and future requirements of the business.

Category Classification - possibly based on nature of event.

Change Any modification – addition or removal of approved, supported or base lined hardware, network, software, application, environment, system, desktop build or associated documentation.

Change Management Process of implementing Changes to the infrastructure or any aspect of services, in a controlled manner, enabling approved Changes with minimum disruption to service.

CI (Configuration Item) Component of IT infrastructure or a related item under the control of Configuration Management.

Configuration Baseline A snapshot of the IT Infrastructure as recorded in the CMDB. Although the snapshot may be updated later, as changes are applied to CIs, the baseline remains unchanged and available as a reference of the original state and as a comparison against the current state.

Configuration Management

A process for identifying, recording, auditing and reporting on the CIs for accuracy and completeness.

Configuration Management Database (CMDB)

A database containing the relevant details of each CI and details of the important relationships between CIs.



Term Description Configuration Management Plan

Document describing the organization and procedures for the Configuration Management of a specific project, product, system, support group or service.

Contingency Planning The preparation to address unwanted occurrences that may happen at a later time. Usually, the term has been used to refer to planning for the recovery of IT systems rather than entire business processes.

Continuity Management

A process that supports the Business Continuity process to ensure that IT Services are recovered within agreed time scale.

Crises Management An occurrence and / or perception that threatens the operations, staff, shareholder value, stakeholders, brand, reputation, trust and / or strategic / business goals of an organization.

Customer Recipient of a service, responsible for funding the service against business requirements.

Customer Management

Customer Management process establishes and maintains links between executive business managers and the IT services organization.

Definitive Hardware Store (DHS)

Definitive Hardware Store. An area that is aside for the secure storage of definitive hardware spares.

Definitive Software Library (DSL)

Definitive Software Library. A secure software library where all versions of accepted software configuration items (CIs) are held in their definitive, quality-controlled form.

Disaster recovery planning

Set of processes that focus only on the recovery processes, mainly in response to the physical disasters, which are contained within BCM.

End User (or User) The individual who uses the service on a day-to-day basis.

Forward Change Schedule

A schedule of all approved changes and their planned implementation dates for a pre-specified period.

Impact (For Incident) Measure of scope and criticality to business. © Queen's Printer for Ontario, 2007 36 Last Review Date: 2007-07-26 Next Review Date: 2008-06


Term Description Incident An event that negatively impacts the standard

delivery of a service, or a service request Incident Management A process that is committed to restoring normal

service operations as documented in Service Level Agreements as well as processing service requests.

IT Service Delivery IT Service Delivery processes (Availability Management, Capacity Management, Continuity Management, Financial Management and Service Level Management) address from a design and management perspective the service that business requires of the provider.

ITSD IT Service Desk KDB Knowledge database. A database of solutions

and workarounds that is used by front level support staff to restore normal Service operation.

Known Error An incident or Problem for which the root cause is known and for which a temporary Work-around or a permanent alternative has been identified. If a business case exists, an RFC will be raised, but, in any event, it remains a known error unless it is permanently fixed by a change.

Maintainability Describes the ability of the Internal IT groups to maintain the services via the management of IT infrastructure components or services. Managed through OLAs.

Mean Time Between Failures (MTBF)

Expected future performance based on the actual past performance of a population of units. Calculated as: (MTBF = total actual operating time / total number of failures).

Mean Time To Repair (MTTR)

Average amount of time it takes to repair a component. MTTR typically includes time from when the unit failed until replaced, thus including hardware unavailability, response time, travel time, and on-site repair time.

Metric A measurable element of the service process or function.



Term Description Operational Level Agreement

An internal agreement covering the delivery of services, which support the IT organization in their delivery of services.

Operational Test Environment

A test environment that is directly used by customers or end-users as part of the IT services they receive.

Operations Management

A process that consists of all activities and measures necessary to enable and maintain the intended use of IT services and production environment.

Post Implementation Review

A review for verification of correct implementation of change by authorized personnel.

Priority Relative order in which a given event needs to be addressed. This usually depends on Impact and Urgency.

Problem An unknown underlying cause which could or has caused disruption of service.

Problem Management A process that minimizes the effect of errors in infrastructure / services and external events on the customers. It is a process focused on diagnosing and rectifying faults in the IT infrastructure to obtain the highest possible IT service stability.

Procedure A set of specific steps that describe how an activity should be carried out, and by whom. Procedures may be supported by more detailed Work Instructions. A Process defines what is to be achieved; Procedures define how the objectives are to be achieved.

Process A series of related activities aimed at achieving a set of objectives (or Principles) in a measurable, usually repeatable, manner. It will have defined information inputs and outputs, will consume resources and will be subject to Management controls over time, cost and quality. It will also balance benefits against risks.

Process Owner The Process Owner is the person involved in the project with regard to process design and / or re-engineering efforts.



Term Description Production environment

A subset of IT infrastructure that participates in delivery of Service.

RACI Matrix RACI diagrams are tools used to map activities to roles and define how roles contribute to an activity.

Release A collection of new or changed CIs. Release to Production The HP ITSM process, which controls the

release of changes in the production IT Infrastructure. It is a component of the ITIL Release Management Process.

Reliability The service or IT infrastructure Configuration Item (CI) is available when expected / as defined in the SLA. It can also be described as freedom from failure. It is expressed in terms of MTBF - average uptime.

Request for Change (RFC)

Form, or screen, used to record details of a request for a change to any CI within an infrastructure or to procedures and items associated with the infrastructure.

Resilience Degree redundancy of a CI with the intent of eliminating single points of failure in the infrastructure.

Security Incidents Security incidents are those events that cause damage to confidentiality, integrity or availability of information or information processing and materialize as accidents or deliberate acts.

Security Management Security Management is the process of managing a defined level of security on information and IT services, in addition to managing the response and effect of security incidents.

Service achievement The actual service levels delivered by the IT organization to a customer within a defined life span.

Service Build and Test Service Build & Test process develops, tests and documents new Services and enhancements & fixes to an existing Service.

Service Catalogue Written statement of IT services, default levels and options.



Term Description Service Delivery Processes that address Service Management

from a design and management perspective. Service Desk Single point of contact between Service

Provider and the users of the Service. Service Improvement Program

A formal project undertaken within an organization to identify and introduce measurable improvements within a specified work area or work process.

Service Level Agreement (SLA)

Written agreement between a service provider and the Customer(s), that documents agreed Service Levels for a Service. The scope of an SLA covers the target environment to be serviced, specific IT service deliverables, service functionality, service coverage (e.g., level, hours, availability, responsiveness, restrictions, authorizations, etc.), security policies, and cost of the services being provided.

Service Level Management

A process that defines Service levels agreed with customer and subsequently manages at an acceptable cost.

Service Level Objective (SLO)

A defined target for a service metric, usually specified in an SLA.

Service Management Management of Services to meet the Customer's requirements.

Service Planning The Service Planning process designs, develops and controls Service Plan required for service development. This plan will describe scope, functional requirements and required components for service implementation that aids in determination of service ROI along with decisions like “Buy Vs Build”.

Service provider Third-party organization supplying services or products to customers.

Service quality plan The written plan and specification of internal targets designed to guarantee the agreed service levels.

Service Request Every Incident not being a failure in the IT Infrastructure, such as requesting information or moving equipment.



Term Description Serviceability Describes the external contracts or

Underpinning Contracts (UCs) that exist with suppliers that are required to deliver service.

Services The deliverables of the IT Services organization as perceived by the Customers; the services do not consist merely of making computer resources available for customers to use.

Underpinning contract A contract with an external supplier covering delivery of services that support the IT organization in their delivery of services.

Urgency Measures how quickly an event needs to be addressed.

User Person who uses services on a day-to-day basis.

Workaround Restoring service by application of temporary fix or routing service to the customer via another channel.

Workgroup An organizational or logical unit of individuals with similar specialization and responsibilities



References OPS Standard ITSM Process Guide Version 1.4 (last updated in March, 2001).

OPS GO IT Standard # 55 – OPS ITSD Interaction Model and Incident Support Patterns (May 2007)


Incident Mgt OPS Guide

Documents

revised standards

existing standards

related standards

review date

process roles

process flow

standard process parameters

administrative information