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.

GO-ITS 37
Status: Approved
Version 1.2
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

GO-ITS 37
1.
Status: Approved
Version 1.2
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 crossjurisdictional service management. Please refer to this link for full text:
http://www.gov.on.ca/MGS/graphics/STEL02_047445.pdf

GO-ITS 37
Status: Approved
Version 1.2
Rationale for Update:

In August 2005, Cabinet approved e-Ontario as the governments I&IT strategy. The eOntario 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.

GO-ITS 37
Status: Approved
Version 1.2
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 firstlevel 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).

GO-ITS 37
Status: Approved
Version 1.2
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.

GO-ITS 37
Status: Approved
Version 1.2
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.

GO-ITS 37
Status: Approved
Version 1.2
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.
This word, or the adjective "RECOMMENDED", means that there may exist valid
reasons in particular circumstances to ignore the recommendation, but the full
Should
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

GO-ITS 37
Status: Approved
Version 1.2
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.)
10

GO-ITS 37
Status: Approved
Version 1.2
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.
11

GO-ITS 37
Status: Approved
Version 1.2
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
12

GO-ITS 37
Status: Approved
Version 1.2
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
13

GO-ITS 37
Status: Approved
Version 1.2
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
Customers agreement to the resolution must be confirmed prior to closing the incident
Resolution and closure of an incident require separate statuses
14

GO-ITS 37
Status: Approved
Version 1.2
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
15

GO-ITS 37
Status: Approved
Version 1.2
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
Service
Desk
Analyst
User
2.0 - Contact Service Desk
2.1 - Log Incident
2.2 - Perform First Level

Diagnosis & Resolution
Second to Escalation
nth Level Manager
Support
2.3 - Perform Second (nth) Level

Diagnosis & Resolution
2.4 - Manage Escalation
AR
2.5 - Perform Diagnosis &

Resolution for Exceptional
Incidents
2.6 - Close Incident
Incident
Manager
16

GO-ITS 37
Status: Approved
Version 1.2
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.
17

GO-ITS 37
Status: Approved
Version 1.2
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
18

GO-ITS 37
Status: Approved
Version 1.2
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
19

GO-ITS 37
Status: Approved
Version 1.2
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

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
to
IM
process
(e.g.
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 ITSDs 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)
20

GO-ITS 37
Status: Approved
Version 1.2
2.3 Process Flow

2.3.1 Incident Management Generic Process Flow
Incident Managementt Process Overview
User
Service
Desk
Analyst
2.0
Contact Service
Desk
2.6
Close Incident
2.2
Perform First
Level
Diagnosis &
Resolution
2.1
Log Incident
2.3
Perform Second
(nth) Level
Diagnosis &
Resolution
Second
(nth)
Level
Support
Exceptional
Incident
2.4
Manage
Escalation
Incident
Manager
2.5
Manages
Diagnosis &
Resolution for
Exceptional
Incidents
Escalation
Manager
Figure: 1 Incident Process Overview

No.
2.0
SubProcess
Contact
Service
Desk
Input /
Trigger
Request
from User
Description
Output /
Completi
on criteria
User initiates process by

Incident
contacting Service Desk through
appropriate channel (e.g. email,
phone)
Common
Incident
record
status
New
An Incident may also be a

service request, e.g., a request
for memory upgrade.
2.1
Log
Incident
Trigger:
Automated
incident
Incident is received by the

Service Desk Analyst and
reviewed to assess whether this
21
Incident
New
registratio
n

GO-ITS 37
No.
2.2
SubProcess
Perform
First
Level
Diagnosi
s&
Resoluti
on
Status: Approved
Input /
Trigger
Version 1.2
Description
Output /
Completi
on criteria
received
from an
event
manageme
nt 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.
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.
Perform
Second
(nth)
Level
Diagnosi
s&
Resoluti
on
Incidents that cannot be

resolved at this level and /or
need management intervention
will be escalated
Input:
Incident
assigned
by Service
Desk
Analyst
Incident
record
status
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
Exceptional incidents will be

escalated to the Incident
Manager to determine whether
Escalation Manager is required.
2.3
Common
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
22
Incident
Assigned
resolution
In
Unresolv Progress
ed
Pending
incident
escalatio
Restored
n to next
/ Fulfilled
level
support
and
document
reasons
for
escalatio
n
Incident
Assigned
resolution
In
Unresolve Progress
d incident
escalation Pending
to next
Restored
level
/ Fulfilled
support
and
document
reasons

GO-ITS 37
No.
2.4
SubProcess
Status: Approved
Input /
Trigger
Manage Input:
Escalatio Escalation
n
Criteria
Version 1.2
Description
Output /
Completi
on criteria
Common
Incident
record
status
Manager.
for
escalation
Escalation raises the visibility of

the Incident to the Incident
Manager who decides whether
an escalation manager is
required.
Assign to Assigned
second or
nth level. In
Progress
Incident
Pending
Escalated incidents are still

owned, tracked and managed
within the Incident Management
process, but ownership of the
Incident transfers to the
Escalation Manager.
2.5
2.6
Manages
Diagnosi
s and
Resoluti
on for
Exceptio
nal
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
In
resolution Progress
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
Pending
Restored
/ Fulfilled
Restored
/ Fulfilled
User
Closed
Feedback
/
satisfacti
on,
Process
improvement
planning
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.
23

GO-ITS 37
Status: Approved
Version 1.2
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
Number and percentage of Incidents

by priority
Number of incidents processed per
Service Desk Analyst
Number and percentage of Incidents
by product category
Top 5 incident types by frequency
24
% reduction in MTTR (mean time to

resolve)
% reduction in the # of tickets that
were not created by the Service Desk
% of Incidents resolved by 1st line
support
Average time for 2nd level support to
respond
% of incidents handled within agreed
response time (Incident response-time
GO-ITS 37
Status: Approved
% increase in the incidents resolved

by the Service Desk
% increase in the incidents resolved
by the Service Desk on first response
Version 1.2
% reduction in referrals
% reduction in incidents that require

re-classification based on Service
Category
% reduction in incidents that require
re-classification based on Component
category
targets may be specified in SLAs, for

example, by impact code)
Average cost per Incident
% of incidents logged and resolved by
Tier 2, without being assigned to Tier
1
# of incidents by incident type (based
on OPS TRM)
Customer Satisfaction
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.
25

GO-ITS 37
Status: Approved
Version 1.2
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:
Doretta.Ojeda@ontario.ca
Norm.watt@ontario.ca
26

GO-ITS 37
Status: Approved
Version 1.2
5. Acknowledgements
List this documents 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
Norm Watt
OCCTO
Asim Masoodi
OCCTO
Branch
Technology Adoption
Branch
Technology Adoption
Branch
5.2 Contributors
Name
Cluster/Ministry
Norm Watt
OCCTO
Rick Guyatt
OCCTO
Eion Gomes
OCCTO
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
Branch
Technology Adoption
Branch
Technology Adoption
Branch
Technology Adoption
Branch
27

GO-ITS 37
Status: Approved
Colleen Martin
LRC
Gideon Chiang
FFS Consultant
Version 1.2
On Assignment to OCCSD
5.3 (ITSD Contextual Model Core Team)

Name
Cluster/Ministry
Branch
Norm Watt
OCCTO
Rick Guyatt
OCCTO
Eion Gomes
OCCTO
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
Technology Adoption
Branch
Technology Adoption
Branch
Technology Adoption
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.
28

GO-ITS 37
Status: Approved
Version 1.2
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
OPS Standard
Process
Guide
(2001)
Polic
y No.
5.1
5.1
1
2
X
X
5.1
3
4
5
6
7
5.1
5.1
5.1
5.1
5.1
8
6
9
10
4
New
Removed
Sectio
n No.
Modified
Explanation
Same
Portab
le
Proce
ss
Guide
(2004)
Princi
ple
No.
1
2
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.
X
X
X
X
X
5.1
5.1
5.2
Added to reflect increased involvement of

service providers in Incident Management.
Not required: The Incident Management
Process acts as an agent for recording and
X resolving all I.T. (including Voice & Data
Services) support requests including requests to
other support agencies.
Procedural: There will be clear linkage between
X Incident records, Problem records, known Errors
and Request for Change
Not required: A team or Group will be identified
which will ensure compliance with standards.
X
They will work closely with the teams who
establish standards.
29

GO-ITS 37
Portab
le
Proce
ss
Guide
(2004)
Status: Approved
Version 1.2
OPS Standard
Process
Guide
(2001)
5.2
5.2
5.2
5.2
All Policies and Standards will be enforced.

Incident Management Process will only be
responsible to support standard applications /
hardware.
Not required: The organization will define the
core Desktop Environment for the Client.
Not required: All SLAs will include the level and
scope of support provided by the Incident
Management process for all Clients.
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.
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.
Portable
Process
Guide
(2004)
Role
Incident
Management
Process
Owner
OPS Standard
Process Guide
(2001)
Secti
on
No.
Role
2.1.4
Proces
s
Owner
Same
Modified
New
Removed
Table 2 - Incident Management Roles
Explanation
Added to reflect clearly the responsibilities

around process definition support and
evolution
30

GO-ITS 37
Portable
Process
Guide
(2004)
Status: Approved
Version 1.2
OPS Standard
Process Guide
(2001)
Additional responsibilities:
- Request the assignment of an Incident
Escalation Manager when required
4.1
Incident
Proces
s
Manag
er
4.8
Situatio
n
Manag
er
Second to nth
Level Support
4.5
4.6
Senior
Incident
Support
Analyst
/
Service
Provide
r
Service Desk
Analyst
4.3
Incident
Support
Agent
4.8
On-site
Support
Resour
ce
4.9
Operati
ons
Incident
Manager
Escalation
Manager
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.
- Additional responsibilities invoke the
disaster recovery process if required.
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.
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.
- Removed as not required in a Portable
guide
- Removed as not required in a Portable

X guide.
31

GO-ITS 37
Status: Approved
Version 1.2
Portable
Process
Guide
(2004)
OPS Standard
Process Guide
(2001)
Process
Sectio
n No.
(2.0) Contact
Service Desk
5.2.1
5.2.2
5.2.3
Log Incident
and Assign
Severity
5.2.4
Resolve
Incident
(2.3) Perform
Second (nth)
Level
Diagnosis &
Resolution
(2.4) Manage
Escalation
(2.5) Perform
Diagnosis &
Resolution for
Exceptional
Incidents
(2.6) Close
Incident
5.2.5
5.2.5
5.2.6
5.2.7
5.2.8
5.2.9
5.2.10
5.2.11
Explanation
Contact
Incident
X
Management
Receive
Incident
Notification
(2.1) Log
Incident
(2.2) Perform
First Level
Diagnosis &
Resolution
Process
Same
Modified
New
Removed
Table 3 - Incident Management Process
Incident
Dispatch
Incident
Dispatch
Service
Restoral or
Fulfillment
Monitor
Action
Manage
Situation
Modified:
- Exceptional Incidents are now
escalated to Incident Manager
rather than Escalation Manager.
Modified:
- Incident Manager assigns an
Escalation Manager to deal with
an exceptional (Major) incident.
Close
X
Incident
Report
Metrics
Evaluate
Process for
Continuous
Improvement
Modified:
- Exceptional Incidents are now
escalated to Incident Manager
rather than Escalation Manager.
32
- Removed as not required to

specify for portable guide
- Removed as not required to
specify for portable guide

GO-ITS 37
Status: Approved
Version 1.2
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 whats 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
33

GO-ITS 37
Status: Approved
Version 1.2
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
Asset Management
Availability
Description
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.
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.
34

GO-ITS 37
Term
Availability
Management
Status: Approved
Version 1.2
Description
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
A process for identifying, recording, auditing
Management
and reporting on the CIs for accuracy and
completeness.
Configuration
A database containing the relevant details of
Management
each CI and details of the important
Database (CMDB)
relationships between CIs.
35

GO-ITS 37
Term
Configuration
Management Plan
Status: Approved
Version 1.2
Description
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 dayto-day basis.
Forward Change
Schedule
A schedule of all approved changes and their

planned implementation dates for a prespecified period.
Impact (For Incident)
Measure of scope and criticality to business.
36

GO-ITS 37
Status: Approved
Term
Version 1.2
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 Workaround 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.
37

GO-ITS 37
Term
Operational Level
Agreement
Status: Approved
Version 1.2
Description
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.
38

GO-ITS 37
Term
Production
environment
Status: Approved
Version 1.2
Description
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.
39

GO-ITS 37
Term
Service Delivery
Status: Approved
Version 1.2
Description
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.
40

GO-ITS 37
Term
Serviceability
Status: Approved
Version 1.2
Description
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
41

GO-ITS 37
Status: Approved
Version 1.2
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)
42


Incident MGT OPS Guide

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Incident MGT OPS Guide

Uploaded by

Copyright:

Available Formats

Government of Ontario IT Standard (GO-ITS)

Incident Management OPS Process Guide

Queen's Printer for Ontario, 2007

Queen's Printer for Ontario, 2007

Last Review Date: 2007-07-26

Queen's Printer for Ontario, 2007

Last Review Date: 2007-07-26

1.1 Background and Purpose

Principles, Roles, Responsibilities and Processes that do not need to be specified

Queen's Printer for Ontario, 2007

Last Review Date: 2007-07-26

Rationale for Update:

Last Review Date: 2007-07-26

Last Review Date: 2007-07-26

Process Focus & Goals

Queen's Printer for Ontario, 2007

Last Review Date: 2007-07-26

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

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:

To always include a root cause analysis

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

1.3 Applicability Statements

Last Review Date: 2007-07-26

Kindly refer to http://intra.pmed.mbs.gov.on.ca/mbc/pdf/Agency_Establishment&Accountability-Dir.pdf for a list of

1.4 Requirements Levels

1.5 Recommended Versioning and/or Change Management

Last Review Date: 2007-07-26

1.6 Publication Details

Queen's Printer for Ontario, 2007

Last Review Date: 2007-07-26

Last Review Date: 2007-07-26

2.1 Common Process Principles

Decreased support costs & Improved support consistency

Increased productivity of IT staff and Customers

Increased Customer satisfaction

Existing Incident Management related processes, procedures and work instructions

Queen's Printer for Ontario, 2007

Last Review Date: 2007-07-26

Incident Management must be supported by an integrated IT support system with a

Improved clarity to Customer about where to get help

Empowerment of first-level of support

Better customer service

Status information becomes available to end users

Single point of accountability

Queen's Printer for Ontario, 2007

Last Review Date: 2007-07-26

There may be resource implications

End user expectations will be set appropriately and met consistently

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

The communication procedures, technology, and responsibilities will have to be

Additional training might be required for first-level support

End user is actively engaged and customer satisfaction is increased

Process enhances the image of the IT organization

Resolution and closure of an incident require separate statuses