Escolar Documentos
Profissional Documentos
Cultura Documentos
Prepared for the Information Technology Standards Council (ITSC) under the delegated
authority of the Management Board of Cabinet
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
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
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
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).
Queen's Printer for Ontario, 2007
GO-ITS 37
Status: Approved
Version 1.2
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.4: Common Process Metrics remains suggested only at this time.
The following is in scope of Incident Management process:
Event monitoring
GO-ITS 37
Status: Approved
Version 1.2
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
GO-ITS 37
Status: Approved
Version 1.2
Information Technology Standards Council (ITSC) and the Architecture Review Board (ARB)
for approval and publication.
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.
Queen's Printer for Ontario, 2007
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)
12
GO-ITS 37
Status: Approved
Version 1.2
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:
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
End-users across the enterprise will have access information about incidents,
problems and changes
Implications:
The IT organization must learn to communicate to its customers and partners in simple
and common language
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:
Process must include the final contact with the end user
Customers agreement to the resolution must be confirmed prior to closing the incident
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:
Clear escalation triggers and escalation points must be defined for both functional and
hierarchical escalation
All parties have to comply with incident logging, this includes external service
providers
Ensures consistency
15
GO-ITS 37
Status: Approved
Version 1.2
Implications:
Contracts with service providers must reflect the Incident Management activities, tasks
and linkages associated with their role
Sub-Process
Service
Desk
Analyst
User
Second to Escalation
nth Level Manager
Support
AR
Incident
Manager
16
GO-ITS 37
Status: Approved
Version 1.2
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
17
GO-ITS 37
Status: Approved
Version 1.2
Responsibilities
Monitors service delivered by the team for all customers being served
18
GO-ITS 37
Status: Approved
Version 1.2
Creates an Incident record for new incidents into the incident control system
Updates the case for existing incidents into the incident control system
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
to
IM
process
(e.g.
Management of any knowledge updates driven by the partner, which may result in
updated knowledge being passed to the OPS ITSD
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
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
2.0
SubProcess
Contact
Service
Desk
Input /
Trigger
Request
from User
Description
Output /
Completi
on criteria
Common
Incident
record
status
New
Log
Incident
Trigger:
Automated
incident
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
Input:
Registered
Incident
Perform
Second
(nth)
Level
Diagnosi
s&
Resoluti
on
Input:
Incident
assigned
by Service
Desk
Analyst
Incident
record
status
2.3
Common
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
Assign to Assigned
second or
nth level. In
Progress
Incident
Pending
2.6
Manages
Diagnosi
s and
Resoluti
on for
Exceptio
nal
Incidents
Input:
Incidents
assigned
by Incident
Manager
Incident
In
resolution Progress
Close
Incident
Input:
Resolve
Incident
Escalated
Incidents
Incident
closure
Pending
Restored
/ Fulfilled
Restored
/ Fulfilled
User
Closed
Feedback
/
satisfacti
on,
Process
improvement
planning
23
GO-ITS 37
Status: Approved
Version 1.2
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)
The following common metrics are suggested for the OPS Incident Management process:
24
GO-ITS 37
Status: Approved
Version 1.2
% reduction in referrals
3. Related Standards
3.1 Impacts to Existing Standards
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
Organization:
Ministry of Government
Services
Ministry of Government
Services
Division:
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
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
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
X
X
X
X
X
5.1
5.1
5.2
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
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
Explanation
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.
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
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
GO-ITS 37
Status: Approved
Version 1.2
33
GO-ITS 37
Status: Approved
Version 1.2
o Urgency
o Priority
o Closure Code (Reason Category)
Description of symptoms
Incident status
Related CI
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)
Change Advisory
Board Emergency
Committee (CAB/EC)
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
Continuity
Management
Crises Management
Customer
Customer
Management
Definitive Hardware
Store (DHS)
Definitive Software
Library (DSL)
Disaster recovery
planning
Forward Change
Schedule
36
GO-ITS 37
Status: Approved
Term
Version 1.2
Description
Incident
Incident Management
IT Service Delivery
ITSD
IT Service Desk
KDB
Known Error
Maintainability
Metric
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
Operations
Management
Post Implementation
Review
Priority
Problem
Problem Management
Procedure
Process
Process Owner
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
Release
Release to Production
Reliability
Resilience
Security Incidents
Security Management
Service achievement
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.
Queen's Printer for Ontario, 2007
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
Service Improvement
Program
Service Level
Agreement (SLA)
Service Level
Management
Service Level
Objective (SLO)
Service Management
Service Planning
Service provider
Service Request
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
Underpinning contract
Urgency
User
Workaround
Workgroup
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