Document history

DateSummary
2004-11Review draft version - "Portable Process Guide": Corporate Architecture Branch (CAB Architects), OCCTO
2004-11-12Review draft version - "Portable Process Guide": Infrastructure Development Branch & iSERV, OCCSD
2004-12Review draft version - "Portable Process Guide": Corporate Security Branch, OCCS
2005-02Version .99: Final draft circulated internally
2005-02Version 1.0: Published externally
2015-11Draft of updated TRM begun
2016-09SACM, Release, Problem, and SLM added
2016-10Updated parameter values across all processes
Release Management added
Service Level Management added
Business Service Management Model conceptual foundation added
2016-11Recommendations for Future Direction authored
2017-05IT Service Management Leads Forum endorsement
2017-09-13Architecture Review Board endorsement
2018-01Minor updates to reflect most recent updates through the governance process
2018-01-25IT Executive Leadership Council approval - Approved version number set to 2.0

Foreword

Government of Ontario Information Technology Standards (GO ITS) are the official publications on the IT standards adopted for use across the government's IT infrastructure.

These publications support the responsibilities of the Treasury Board Secretariat (TBS) for coordinating standardization of Information & Information Technology (I&IT ) in the Government of Ontario.

In particular, GO ITS describe where the application of a standard is mandatory and specify any qualifications governing the implementation of standards.

Copies of cited GO-ITS standards may be obtained as follows:

Introduction

3.1. Background

Portable guide

This process guide was part of a "portable" set of Information Technology Service Management (ITSM) process documentation intended for use as a reference across the OPS. This documentation established the required baseline models specific to process-based terminology to foster and promote ITSM process adoption across the OPS.

A key objective identified during an OPS ITSM Planning workshop, held in December 2003, was to "Define Standard Portable Elements for All ITSM Processes". A set of standard guides was designed to be portable across all I&IT Clusters as well as any parties in the end-to-end service chain. Those standard guides were to include only the necessary process components that should be common across the OPS, exclusive of terminology. The high-level set of recommendations for common ITSM terminology, specific to each process, was therefore replaced with the current document, the Terminology Reference Model (TRM).

The TRM (version1.0, published in 2005-02) replaced the recommendations for suggested terminology values put forth within the process guides for Incident, Problem and Change Management (GO-ITS 37, 38, and 35, respectively). The intention in replacing those recommendations was to establish the minimum, mandatory information elements required for all partners in the end-to-end service chain.

Additional information elements were to be defined at the local level as required.

Infrastructure technology services

A new organization within the OPS was mandated in 2005 to deliver all infrastructure service and support to the OPS. The Infrastructure Technology Services (ITS) division was created in 2006 to achieve this goal. Subsequently, an update of the requirements for the GO-IT Standards for ITSM processes was necessitated. The creation of additional, new process standards was also needed. The process standards affected at the time included:

Table 1 GO-IT Standards Impacted by the establishment of ITS

DocumentImpact at the time
GO-ITS #37 - Incident managementUpdate
GO-ITS #35 - Enterprise change management (eCM)Update
GO-ITS #36 - Enterprise Service Asset Configuration Management (eSACM)Update
GO-ITS #38 - Problem ManagementUpdate
GO-ITS #55 - Service DeskNew

In the years following the establishment of ITS, considerable progress has been made in evolving and implementing enterprise-wide ITSM processes. Process adoption and adherence has increased steadily. The GO-IT Standards listed above have provided a solid foundation for such progress.

In addition, new processes have been established and GO-IT Standards have been, or are being authored currently (Fiscal 2016-17). Specifically, these are Release Management and Service Level Management.

Tool enablement

In May 2015, the enterprise IT Service Management (ITSM) toolset was upgraded. That upgrade to the ITSM toolset required further updates to related GO-IT Standards in order to accommodate changes in terminology. The Terminology Reference Model was identified as a document substantially impacted by the upgrade to the ITSM toolset and in need of review.

Initial consultations with ITSM process owners from September 2015 through to March 2016 confirmed the relevance of the TRM in supporting best practices and effective IT service management. In March 2016, the proposal to establish a new, formal terminology reference model standard was accepted by the ITS Standards Review Committee and by the Process Standards Sub-committee.

Relationship of ITSM guides

Each of the GO-IT Standards listed in Table 1, above, refers to this Terminology Reference Model as the locus of a common information model for key process parameters that require standardization across the OPS. The agreed, stated purpose of the TRM includes ensuring consistency, ensuring reliable business intelligence, and supporting end-to-end, cross-jurisdictional IT service management.

The following points summarize the rationale for and benefits of maintaining a single terminology reference model that is external to each process-specific guide:

  • Process guides should provide the details, unique to each process, which relate to Process, Principles, and Roles and Responsibilities. A terminology reference guide complements these process guides.
  • The evolution and maturation of ITSM terminology progress at a greater pace than the underlying processes themselves. Therefore, the separation of detail relating to terminology allows for a more efficient management of its evolution and maturation.
  • Key terminology overlaps multiple processes (e.g., service configuration item) and modification of this terminology would require updating multiple process guides simultaneously. As noted above, the separation of terminology details into a stand-alone guide facilitates more efficient management of changes.
  • A thorough consultation with OPS stakeholders for terminology can be conducted in a coordinated fashion that is more fitting to the nature of the unified "Business Service Management" model enabled in the ITSM toolset.
  • This document establishes common ITSM terminology for use across the OPS. The TRM provides a frame of reference for additions or localization by service providers (e.g., Clusters) in the end-to-end service chain. Common terminology also facilitates more efficient and consistent performance management through OPS-wide monitoring and reporting using common data and metrics.

It is expected that each stakeholder will leverage or expand on this Terminology Reference Model to address specific requirements for adopting and enabling processes within that stakeholder's specific service or operational context. This context-specific application of the TRM will identify informational requirements, organizational mapping considerations, or other considerations that may not be address in the current document version.

This guide, ultimately, addresses the need for a common terminology model specific to key process parameters that require standardization across the OPS. State and classification footnote 1 values and definitions in the TRM can and should be used in data models, class models, and XML schemas for IT service management support and delivery. This could include a future 'Common Data Elements' subject area.

3.2. Purpose

The OPS has successfully implemented a number of enterprise-wide ITSM processes. For several years, each process implementation defined its own process states and classifications, based on a variety of criteria (e.g., local needs, definitions embedded in an off-the-shelf tool, operational demands). In an environment of distinct I&IT jurisdictions, these differences in terminology did not cause major issues. As the OPS evolves to a more "horizontal" delivery of government services using enterprise-wide ITSM processes, there is a need for common language and common terminology for the exchange of process information among IT service chain partners.

The purpose of the TRM is to define a standard, common terminology that forms part of ITSM process adoption across the OPS. Currently, the following enterprise processes are implicated:

  • Incident Management
  • Problem Management
  • Change Management
  • Release Management
  • Service Level Management
  • Service Asset and Configuration Management (SACM)

The TRM defines mandatory informational elements and definitions for ITSM processes. These definitions will provide a consistent glossary for key ITSM informational elements. Specifically, these elements can be broken down into the following dimensions:

  1. The classification of process information
  2. The states that a given process can traverse

The TRM focuses on the classification and state parameters for enterprise Incident, Problem, and Change Management processes. For enterprise Release, Service Level, and Service Asset and Configuration Management, this TRM document introduces parameters and values pertinent to those processes. It is anticipated that the TRM will be updated in parallel as these ITSM processes progress toward greater standardization and adoption and as additional enterprise ITSM processes are introduced and adopted.

There may be instances in which process owners and service providers will require additional or more detailed terminology elements. The TRM does not restrict the creation of localized terminology nor limit the evolution of terminology. Wherever possible, a framework will be described to support the creation new terminology elements in a consistent, manageable manner.

Where more detailed terminology elements are defined, service providers will need to be able to roll up their local values into the TRM model prior to communicating with partners across the service chain. This should be done through the appropriate process governance and interest communities or bodies.

3.3. Approach

The approach used for the creation of this standard was as follows:

  1. Through the project and implementation phases of the Enterprise Service Management Tool (eSMT), process owners and practice leads underwent extensive review and development cycles with their stakeholders to gain consensus on the information elements related to each process.
  2. The results of those efforts by process owners and practice leads were documented in this version of the TRM, essentially capturing the current terminology in use, specifically for the following processes:
    1. Incident Management
    2. Problem Management
    3. Change Management
    4. Release Management
    5. Service Asset and Configuration Management
  3. For Service Level Management, elements of the terminology model were developed through an assessment of the existing process elements and their alignment with or enablement through the new SLM module that was implemented as part of the ITSM toolset launched in 2015. These SLM terminology elements were then presented to the Enterprise Service Level Management working group and the SLM Community of Interest; the resulting feedback was incorporated until consensus was reached.
  4. Input from Defined a set of guidelines for the definition of state and classification models for each process (see Appendix A for state and categorization model definition guidelines) and created proposed models.
  5. A Practice Leads forum was established to provide a regularly scheduled opportunity to discuss the TRM and issues that arose.
  6. A TRM Working Group was established to ensure focused discussions and reviews of the contents begin drafted for the TRM, including draft versions posted for review at least weekly.
  7. Each process area presented the content and scope of the TRM version for F2016-17 to the relevant community of interest or user community to obtain feedback
  8. For more complex issues or proposals that implied potentially extensive changes, direct presentations and discussions with key stakeholders were held. In most cases, the Future Opportunities section (Appendix A) reflects the results of such discussions.

3.4. Audience

The TRM is intended for use by ITSM process owners, process managers and leads, and IT service providers involved in the delivery of OPS IT services, whether horizontal, inter-jurisdictional, or within a single ministry or cluster.

By extension, the TRM is also intended to form part of the technical dialogue between an OPS IT service provider and any external service supplier that may be engaged to provide IT services as part of an IT service delivery chain.

3.5. Value to the business

The value of the Terminology Reference Model includes:

  • The ability to provide meaningful performance reporting across jurisdictional boundaries that demonstrates the effectiveness of the entire, end-to-end IT service delivery chain
  • The ability to identify points of weakness and strength in the end-to-end IT service delivery chain
  • The ability to analyze process interactions and their impacts to business
  • The ability to identify opportunities for service improvement (input to Continual Service Improvement initiatives)
  • The ability to execute IT Service Management processes in an efficient, effective manner in support of IT Business Service delivery
  • The ability to generate meaningful management information to support evidence-based decision making and strategic investment in IT

3.6. Vision and scope

3.6.1. Vision

The vision for the TRM is that the model be adopted by all internal and external service providers represented in the OPS IT service delivery chain. In adopting a common terminology, information exchange among service providers can be done in a consistent manner, requiring little or no translation among partners. This, in turn, results in a highly agile and adaptive enterprise, allowing providers to be integrated in a service delivery chain faster and with less complexity. The cost to the OPS for activating a vendor's integration may also be reduced, as a result.

The TRM is projected to evolve further through two key initiatives:

1. Creation or modification of GO-IT Standards for IT Service Management

The establishment of new processes (e.g., Service Level Management, Release Management) will require that common terminology be defined to ensure continued benefit to the OPS through enterprise process adoption. Existing GO-ITS documents for ITSM processes may require updates as more thorough adoption of the ITSM tool-enabled Business Service Management model proceeds.

Further, as corporate operational requirements evolve, ITSM standards and terminology may need to be modified to support new directions or expectations. For example, if a government initiative requires that existing process activities be more broadly consistent to achieve OPS objectives, then the process guides may need to be updated accordingly. This may also require that the existing TRM-specific definitions be modified or expanded.

2. Evolution of corporate performance measurement requirements

Corporate performance measurement and reporting criteria will require additional process definitions in order to achieve consistent information outcomes. For example, if a performance measure is defined to reflect the impact of an incident to a business service affecting a customer (versus impacts to IT), then the TRM may need to include additional informational elements specific to the service; these new elements would need to be imbedded in applicable process terminology (e.g., SACM, Incident, Problem, Change, and Service Level Management).Without adoption of a consistent TRM, corporate performance measures will be difficult, if not impossible, if information elements available to report on differ depending on jurisdiction or if the information elements required for a given measure are not captured within a process.

3. Integration and maturation of ITSM processes

As ITSM processes are executed through the new enabling toolset, based on the Business Service Management model, identification of process interactions becomes more readily doable. Through analyses of such process interactions, changes to information elements may be identified that will help clarify process interactions further and illuminate their relationship to IT business service delivery.

The continual refinement of the information elements that highlight the interplay of process execution and IT's support of business will become a powerful driver of the maturity of ITSM processes.

3.6.2. Scope

The scope of this edition of the Terminology Reference Model will be limited to updating the foundational model to reflect advances in ITSM practices, as enabled by contemporary toolsets. In the OPS I&IT organization, the toolset recently (2015) adopted enables a Business Service Management model. This model has broad implications for existing process frameworks and process interactions.

Additionally, adoption of ITSM processes as enterprise standards and the introduction (or pending introduction) of new enterprise process standards require additional reference models to be introduced in this document.

The objective of this first significant update in nearly a decade will be to focus on the scope outlined above. This leaves a range of opportunities out of scope for the TRM in the short-term. Opportunities exist to clarify the definitions and usage of business impact criticality, currently reflected in the inconsistent usage of three values to rate applications and solutions, namely:

  1. Mission Critical
  2. Business Critical
  3. Business Support

Further opportunities exist to evolve or identify values within a well-considered framework for use in the operational categorization elements of Service Transition and Service Operation processes.

A full treatment of operational categorization is out of scope for this TRM version but a general guide and broad outline of practices for these information elements will be put forth in Appendix A: Future Opportunities. This is intended to foster and promote focused discussions and consultations over the months following publication of this TRM version.

3.7. Applicability statements

3.7.1. Organization

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.

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. Specifically, in the case of the revised version of GO-ITS 37 V2.0, the effective date has been established as July 1, 2010. Future versions will become mandatory on the effective date established for that version.

When implementing or adopting any Government of Ontario IT standards or IT standards updates, ministries and I&IT Clusters 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.

3.7.2. 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 mandatory requirement.

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

3.7.3. Compliance requirements

Execution of enterprise ITSM processes at the operational level requires use of procedures, work instructions, and enabling technology to automate certain workflow aspects. These elements will be produced by the organization selected by the Information Technology Executive Leadership Council (ITELC) as the Operational Process Manager. Pending formalization of an ITSM Process Lifecycle Management protocol, the following statements are presented to ensure that these elements are fully compliant with this standard:

  • Procedures must be developed by decomposing each process step in the workflows defined as part of ITSM process standards. These procedures must be submitted to the Enterprise Process Owner for certification that they comply with the spirit and intent of the process standard, including the interaction with the terminology models defined in this TRM standard.
  • Work Instructions must be developed by decomposing all procedural sub-tasks into further sub-tasks. The data outputs from these sub-tasks must be identified where identified as mandatory in this TRM. These work instructions must be then submitted to the Enterprise Process Owner for certification that they comply with the certified process and procedures.
  • Functional requirements must be developed for enabling technology that will be used to automate aspects of the work instructions and procedures and provide the ability to select from values that comply with the TRM. Functional requirements must also be submitted to the Enterprise Process Owner for certification that they align with the certified procedures.
  • Any subsequent modifications to the procedures or work instructions agreed through the community of interest will be recommended by the Enterprise Practice Lead to the Enterprise Process Owner for implementation.
  • Changes to the enabling technology must be managed via Enterprise Change Management (eCM).
  • Changes to a Process and Procedures Guide for an enterprise process will be managed through an agreed governance process involving, but not limited to, the following prior to seeking formal endorsement and approval:
    • Practice Leads Forum
    • Community of Interest
    • Process and Standards Sub-Committee
    • IT Service Management Leads
  • Changes to this standard will be managed in the manner outlined above with the additional requirement to manage document version control via an advisory change through the eCM process after endorsement and approval by ITSML, ARB, and ITELC.

Standards lifecycle management

4.1. Contact information

Accountable role (Standard owner) definition

The individual or committee ultimately accountable for the process of developing this standard.

Where a committee owns the standard, the committee Chair is accountable for developing the standard including future updates. There must be exactly one accountable role identified. The accountable person also signs off as the initial approver of the proposed standard before it is submitted for formal endorsement to Architecture Review Board (ARB) and approval by ITELC. (Note: in the OPS this role is normally at the IT executive or manager level.)

Accountable role: Chair of IT Service Management Leads (itSML)

Responsible role definition

The organization(s) responsible for the development of this standard.

There may be more than one responsible organization identified if it is a partnership/joint effort. (Note: the responsible organization(s) provides the resource(s) to develop the standard.)

Responsible organization(s): Enterprise Service Management Division, MGCS

Support role definition

The support role is the individual(s) to whom the responsibility for actually completing the work and developing the standard has been assigned. If there is more than one support role, the first role identified should be that of the editor - the individual responsible for coordinating the overall effort.

Support role (Editor):

Ministry: Ministry of Government and Consumer Services (MGCS)
Division: Infrastructure Technology Services
Branch: Service Management Process & Operations
Section: ITSM Processes

Job Title: Senior Manager
Name: Arpad Martonosi
Phone: (519) 830-6431
Email: Arpad.Martonosi@ontario.ca

Job Title: Delegate:
Name: Tim LeBlanc (Practice Lead)
Phone: (519) 820-9162
Email: tim.leblanc@ontario.ca

The above individual will be contacted by the Standards Section once a year, or as required, to discuss and determine potential changes and/or updates to the standard (including version upgrades and/or whether the standard is still relevant and current).

4.1.1. Consulted

Please indicate who was consulted as part of the development of this standard. Include individuals (by role and organization) and committees, councils and/or working groups.

(Note: consulted means those whose opinions are sought, generally characterized by two-way communications such as workshops):

Terminology reference model standard
Organization consulted (ministry/cluster)DivisionBranchDate
TBSEnterprise Service Management (project phase working group)Service Planning, Design, and Transition (Enterprise Service Level Management working group)Weekly meetings 2015-12-17 to 2016-12-15
VariousVarious (Enterprise Service Management project phase design review)Various - Project phase: Service Planning, Design, and Transition; Process and OperationsAugust 17, 2016
TBSITSService Management (Practice Leads Forum)Bi-weekly meetings 2016-03 04 to 2016-12-09
Incident management classification
Review authorityPresentation date
Data Governance and Issues Working Group (ITS SM)November 5, 2015
Service Level Management Community of InterestNovember 18, 2015
Data Governance and Issues Working Group (ITS SM)November 19, 2015
Enterprise Incident Management (Rafal Sura, Practice Lead)November 20, 2015
ITSM Tools (Just Stiles, Manager)November 20, 2015
Senior Manager, Best Practices Office (Aldo Muzzi)November 27, 2015
Enterprise Incident Management (Amanda McCabe, Practice Lead Arpad Martonosi, Manager)July 13, 2016
Committee/working group consultedDate
Partner Incident Management LiaisonsProject Phase of eSMT implementation: August 27th, September 2nd, September 4th, 2015
Incident Management User Community (IMUC)Project Phase of eSMT implementation: November 13th, 2015 September 9th, 2016
Partner Change Management LiaisonsProject Phase of eSMT implementation:
TRM Final Review: November 8, 2016
Partner Release Management LiaisonsProject Phase of eSMT implementation: August 20th, 2015 TRM Final Review: November 16th, 2016
Partner Service Level Management LiaisonsVarious discussions between Nov. 2015 to Nov. 2016 (see SLM CoI agendas)
Partner Service Asset and Configuration ManagementTRM Final Review: October 28, 2016
Practice Leads Forum (enterprise process Practice Leads)Bi-weekly meetings 2016-03 04 to 2016-12-09
TRM Working GroupBi-weekly meetings 2016-10 15 to 2016-12-08
Management Team - Service Order Management, TBSNovember 23rd, 2016

4.1.2. Informed

Please indicate who was informed during the development of this standard. Include individuals (by role and organization) and committees, councils and/or working groups.

(Note: informed means those who are kept up-to-date on progress, generally characterized by one-way communication such as presentations):

Organization informed (Ministry/Cluster)DivisionBranchDate
N/AN/AN/AN/A
Committee/working group informedDate
ITSMLDecember 15, 2016

4.2. Recommended versioning and/or Change management

Changes (i.e., all revisions, updates, versioning) to the standard require authorization from the "responsible" organization.

Once a determination has been made by the responsible organization to proceed with changes, the Best Practice Office, Service Management Branch, Enterprise Service Management Division, will coordinate and provide assistance with respect to the approvals process.

The approval process for changes to standards will be determined based on the degree and impact of the change. The degree and impact of changes fall into one of two categories:

Minor changes - requiring communication to stakeholders. No presentations required. Changes are noted in the "Document History" section of the standard;

Major changes - requiring ARB endorsement and ITELC approval.

Below are guidelines for differentiating between minor and major changes:

Major:

  • represents a change to one or more of Scope, Principles, Roles or high-level Process Flow
  • responds to legislative changes

Minor:

  • does not impact other standards (e.g., updated Glossary information or updated Informative or Normative reference documentation)

4.3. Publication details

All approved Government of Ontario IT Standards (GO-ITS) are available via the intranet site. Please indicate 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.)
  • Yes

4.4. Support for performance measurement and reporting

Classification of transaction records (request tickets) allow performance measurement analysis, filtering, and aggregation. Each classification value represents a key informational element that can be filtered either during the lifespan of the process (e.g., all current high impact incidents) or following process completion (e.g., all rejected changes).

By combining classification with states, it is possible to derive meaningful performance measures (e.g., filter all problems classified as a known error for the last month where the associated incidents are low impact and high urgency). Reporting could, for example, highlight the tactical and/or operational requirement to re-align resources in support of OPS-wide incidents, problems, or changes.

In the same manner as the State Models, the TRM will identify a core set of classifications that will be used across all providers in the service chain. This will allow Business Intelligence analysts and architects to develop reporting to support effective IT service management, decision making, and continual service improvement, among other outcomes.

The extent to which corporate performance measurement can provide in-depth, detailed reporting on for service support and delivery activities will depend on the level of adoption of and/or compliance with the TRM and associated process GO-IT Standards.

Conceptual foundations

5.1. Principles

Principles are established to ensure that the standard identifies the desired outcomes or behaviours related to adoption at an enterprise level. They also serve to provide direction for the development of procedures and (as necessary) work instructions that will ensure consistent execution of the process or processes to which the standard relates. The absence of well-defined and well-understood principles may result in process execution that is not aligned with the process standard.

Principles for the Terminology Reference Model are listed below.

Principle 1:

A single Terminology Reference Model (TRM) shall be used across the OPS in support of I & IT process execution in the delivery of IT services.

Rationale:
  • A single TRM eliminates the costs and inefficiencies of multiple models in use across different processes and/or jurisdictions.
  • A single TRM helps ensure the value of the TRM in generating meaningful and useful management information to support evidence-based decision making and in demonstrating IT's value to the OPS.
  • The establishment of a Single Point of Contact (SPOC) OPS IT Service Desk (ITSD) in FY 2006/2007 implied a strategic direction for OPS I&IT based on enterprise service management processes
Implications:
  • Legacy models and guides for process terminology integrated and aligned to OPS TRM
  • Infrastructure as well as application support groups must adapt existing procedures and work instructions to comply with the OPS TRM

Principle 2:

Process classifications must identify the Service(s) that is (are) impacted and the actions requested of IT (from the Customer's perspective).

Rationale:
  • Supports OPS Service Directive
  • Supports OEIP business architecture principle to establish a service focus for ITSM processes
  • Enable implementation of the Enterprise Service Agreement Model (eSAM)
  • Enable the adoption of the Business Service Management Model
Implications:
  • Staff must adopt an end-to-end service perspective for all incidents
  • Service classification requirements must be defined and included in enabling technology
  • Cluster Service Owners must identify the end-to-end services (IT Business Services) offered to clients and the service models (decomposition) of IT Business Services
  • A service model must exist in order to identify service impacts, from a customer's perspective, in service incidents, changes, and releases, as well as in service level management reporting
  • Staff must be trained in new classification techniques
  • Service Support Models must be updated to reflect new classification techniques
  • Incident messaging with user/customer must communicate the business impact
  • Change and Release messaging with customers communicate the Service to which the process activity is related at risk of impacts
  • Internal assignment routing, currently component-based, may have to be modified
  • Accountabilities for the quality of service delivery may need to be identified and/or confirmed
  • Service level management agreement structures and associated reporting may need to be modified

Principle 3:

All enterprise process agents and functions shall manage each process transaction through its lifecycle to ensure a complete history of the transaction is encoded in the classification of that transaction to ensure complete and accurate management information is generated.

Rationale:
  • Supports the accountabilities and responsibility for execution of enterprise ITSM processes set forth in process-specific documentation (GO-ITS documents and Process and Procedures Guides)
  • Ability to share topical, status, and progress information within a single group and provide an enterprise perspective
  • Ability to cross-reference other process transactions and establish transaction priority from an enterprise perspective
  • Consistent management and coordination of transaction resolution or completion
  • Ability to analyse process interactions and identify meaningful patterns or trends in support of Continual Service Improvement initiatives
Implications:
  • Effective diagnostic scripts, Support Models, and service information are required to assist in triage of incidents and ensure accurate assignment to the appropriate Tier-N resources
  • Effective and accurate design of request process flows are required to ensure service requests are classified in a manner that reflects the intent of the customer and can be fulfilled, measured, and monitored accurately
  • Service Owners must support the objective assessment of reported incidents and ensure criteria for impact and urgency (used to determine priority) are established and communicated to customers through the Service Level Management process
  • Incident assignments/re-assignments to Tier-N support must occur via Service Desk only

5.2. Business service management model

Contemporary practice in IT Service Management and enabling tools involves "centering" process activities and operations on IT Business Services in a highly dynamic manner that more accurately reflects the complex service delivery environment typical of large organizations. This approach has come to be called the Business Service Management model, or BSM model.

Earlier approaches in IT Service Management toolsets used categorization models to "bucket-ize" individual transactions (tickets) in a best-fit approach. These models depended on tiered hierarchies and provided a rigid and often inadequate schema for reflecting the reality of enterprise-scale IT service delivery.

IT service delivery today usually involves IT Business Services that are composed of numerous supporting technical services, which themselves are supported by yet other technical services, plus a very large number of IT components such as hardware, software, documentation, standards, and so on.

Change in perspective

The Business Service Management (BSM) model describes the means for IT to optimize IT service delivery in such a highly complex environment. The BSM model represents the evolution of IT Service Management practices, using a framework such as ITIL, to closely align IT priorities to the priorities of the business that IT serves.

In other words, the BSM model helps move IT from a focus on technology to a focus on the users of IT. The literaturefootnote 2 frequently refers to BSM as a 'change in perspective' for IT. The model sees IT as a strategic partner with business in meeting corporate goals and objectives, yes, but additionally the model sees IT optimizing an integrated service supplier chain through a holistic management of operations, processes, and assets. This service supplier chain streamlines transactions and enables a highly effective public service that can deliver on government mandates.

The foundation of the model is the optimization of IT activities for business success. Rather than managing the processes and operations that underlie services, IT manages services that align to the needs of the business users. In the context of government service delivery, this means ensuring that the IT service delivery chain is consolidated to deliver the outcomes on which ministry programs and processes depend. These outcomes must be effective and achieved efficiently in order to maximize the return on public funds.

Centered on service

A brief discussion of BSM is relevant to an updated Terminology Reference Model because the enabling technology for IT Service Management in the OPS uses BSM architecture. This means, essentially, that the ITSM toolset places IT services at its core, with all process and procedure revolving around IT services; the execution of a service management process is always done in relation to a service.

This construct effectively meets the recommendations sanctioned by the Information Technology Executive Leadership Council (ITELC) in 2009. Those recommendations for the OPS Enterprise IT Service Management Program (OEIP) included the requirement for ITSM processes to maintain service-based focus.

What that relationship is between the process and the service must be clearly defined in order to derive any real value from the model. The relationship of process to service requires accurate mapping of IT capabilities, resources, and assets to the services IT delivers to business. Over time, this mapping exercise creates a more and more accurate model of the live IT environment as a whole. Service models, subject to continuous refinement and tuning, enable a highly effective means of operating, measuring, monitoring, and managing IT service delivery.

Figure 1, below, depicts the Business Service Management model.

Figure 1 Visualization of the Business Service Management Model

Figure 1 Visualization of the Business Service Management Modelfootnote 3

Accessible description of figure 1

The inner circle has at the centre of it "CMDB/CMS" and the heading 'Integrate and Orchestrate'.

A larger outer ring surrounds the inner circle. The outer ring is divided into four equal parts labelled, clockwise, 'Request and Support', 'Provision and Configure', 'Monitor and Operate', and 'Plan and Govern'.

Surrounding the outer ring are the names of IT Service Management processes, IT functions, and operational capabilities such as Incident Management, Identify Management, Application Automation, and several others to demonstrate the exhaustive coverage of the Business Service Management model.

Above the diagram, at the very top of the image, "Business Services" is written. Below, at the very bottom, "Infrastructure" and "Shared Resource Pools" are written in large letters. In smaller letters, contained between the larger headings, are infrastructure are listed the resource pool types "Physical", "Virtual", "Internal Cloud", and External Service Providers.

This TRM is written with the intent of allowing ITSM processes in the OPS to move toward the BSM model. With that in mind, this Standard puts forth a set of principles for unified terminology reference models. The Standard will also provide a working definition of the term "service" for use in the OPS.

Further detail regarding the attributes of Service Configuration Items (CI's), a crucial new information element being introduced with the launch of the new ITSM toolset in 2015, will be required in future. This is an opportunity noted in Appendix A: Future Opportunities.

5.3. TRM roles and responsibilities

The responsibilities involved in the ongoing maintenance and management, the adoption and compliance, and the stewardship and custodianship of the terminology defined for each ITSM process in this document require careful consideration.

Ownership of the terminology in this document aligns to the respective owners of the processes to which terminology belongs. Only the high-level ownership of data elements will be explicitly identified in this document. The more detailed roles and responsibilities relating to data and information are to be defined by each process area. Furthermore, the high-level roles and responsibilities outlined here do not preclude due diligence in undertaking consultations with key functions such as Service Order Management and the IT Service Desk.

The integrated nature of ITSM processes and terminology within the BSM model imply distinct interdependency across process areas. Thus, close cooperation among process owners helps ensure effective, ongoing process interactions can be managed effectively and measured in a meaningful manner.

The table below identifies shows the high-level roles and responsibilities related to the terminology models dealt with in this document.

Legend:

R=Responsible
A=Accountable
C=Consult before
I=Informed

IM - Incident Management
CM - Change Management
SACM - Service Asset and Configuration Management
RM - Release Management
SLM - Service Level Management
ProbM - Problem Management

Model or terminologyIMCMSACMRMSLMProbM
IM Classification ModelA,RCIICC
IM State ModelA,RIIICI
CM State ModelIA,RICCI
CM Classification ModelCA,RICCI
Location and OrganizationCCA, RCCC
Product/Component CategorizationIIA, RICI
Product/Component CI StatusIIA, RIII
RM State ModelICIA, RII
RM Classification ModelICIA, RII
SLM Service Information ModelCCCIA, RI
Service DefinitionsIIIIA, RI
ProbM State ModelCIIICA, R
ProbM Classification ModelCIIICA, R

Terminology reference models

"Sections 5 Terminology Reference Models" provides definitions for key ITSM process terminology. The relevant terminology for each process is organized by process and provided under a major heading for each process.

For processes such as Incident Management, Problem Management, Change Management, and Release Management, terminology for process "states" and for classification of process events is provided.

For the Service Level Management and Service Asset and Configuration Management Processes, definitions for essential information elements and for status values are provided.

6.1. Process state models

6.1.1. About process states models

A State Model is a standardized set of values that signify process states, along with the allowable transitions from one state to another. A State Model provides the means to readily provide information regarding the current milestone achieved in the execution of a process.

A State Model helps ensure that the information provided regarding process milestones is:

  • Predictable
  • Well understood by service partners
  • Measurable

Adherence to a State Model provides a range of benefits to the OPS. These benefits are listed below:

Operational benefits
  • Provides a detailed view of activity underway in the execution of the process. This would, for instance, benefit a change coordinator who is monitoring and tracking changes that have been assessed in order to identify stalled change activity and take action necessary to ensure process activities progress effectively.
  • Ensures that all partners in the service chain are managing their respective part of the process in the same manner. This ensures, for instance, that a restored incident is not being managed as an in-progress incident by one of the service chain partners.
  • Enables the effective operation of a service chain in delivering valued end-to-end IT Business Services.
  • Enables coordination with external partners in building a service chain and allows for effective measuring and monitoring of external service suppliers' performance on service level commitments
  • Enables effective notifications and business logic activation through coordinated state changes. A state change can be used to trigger specific email notifications to assist in preventing breaches of service level goals, or ensure that process activity is assigned to different personnel throughout the lifecycle of the process record.
Tactical benefits
  • Provides an overview of operational activities, both in real-time and for performance trending purposes. This is useful for operational managers who may need to make tactical decisions such as dynamic resource allocation changes. For example, a problem manager may choose to increase staffing for a particular Problem team (e.g., two more personnel assigned for the next two weeks) based on an increasing number of in-progress (i.e., unresolved) incidents being logged and associated to the Problem Record. This state information would also assist in prioritizing Problem activity and in coordinating with Tier 2 staff to rapidly establish a workaround.
  • Facilitates measuring and reporting time intervals between milestones (and the creation of dashboard information. This allows for calculation of key metrics such as request-based service level targets. For example, operating level agreement (OLA) and/or underpinning contract (UC) service level targets related to service restoration can be calculated by excluding paused time from the difference between an incident's stop and start date/time. Standardized performance measures are easier to achieve if they are based on consistent state models versus ad hoc status-based (i.e. localized) implementations.
Strategic benefits
  • Provides a programmatic and/or service provider view of activity through performance measurement reporting. This could be used to measure the effectiveness of a particular service program or key service provider delivering service for a horizontal or inter-jurisdictional service. Combined volumes, SLA compliance, and aging reports (i.e., improvement versus degradation trends) would provide a complete picture of service performance compared to "silo-based" reporting. This information could ultimately be used to make strategic decisions concerning the program or provider (e.g., plan future procurement criteria). Furthermore, performance information assists in providing relevant, timely, and recognizable information to service delivery chain partners and enterprise executives regardless of which service providers are involved in the delivery model.
  • Ensures consistent measurement criteria among all partners in the service chain. This minimizes ad hoc reporting implementations and representations of information, reducing the complexity in rolling up information captured at the tactical and operational levels.
  • Allows for easier and more effective vendor integration in the service delivery chain by establishing a transparent, clearly defined, and managed environment. That is, vendors may be added, swapped, or removed from the service chain while maintaining a degree of transparency from a tactical and operational perspective. By establishing a mandatory state model that vendors must comply with, vendor turnover impacts are minimized within the OPS.
Process states

In the context of process execution, a process "state" is a logical signifier that provides meaningful information regarding the current milestone(s) achieved along the defined path that a given process is to follow.

States provide information regarding the progress of service delivery in a process-oriented IT service management framework. This progress information enables process agents to quickly assess progress and communicate progress information to customers and to service partners. A set of process states enables multiple service providers to align activities among each other within the service delivery chain.

For instance, if each provider is in an In Progress state, a process agent readily understands that each provider is performing similar activities, perhaps in collaboration with one another.

Finally and crucially, a defined set of process states allows for the capture of date and time information and the measurement of time intervals between states. This provides the ability to measure, monitor, and report on process activities, central to effective service level management.

State transitions

State transition models outline allowable transitions from one state to another for each process. Key benefits in defining a state transition model include:

  • Technology implementations will have a clear construct of how and when state transitions can occur.
  • The operational management of processes across multiple service providers in the service chain will be performed consistently. This is required for accurate performance measurement and management of vendors under underpinning contracts.
  • All service chain partners will know what the allowable state transitions are in advance. For example, this will prevent a partner from transitioning a process from a pending state to closed state when other partners may not be able to make a similar transition. This could impact both operational activities (e.g., escalation procedures) as well as performance measurement accuracy (e.g., "skipping" a state may make some metrics invalid).

The state transition models in included as part of each process's State Model outline the possible transitions between each state. Deviation from these transition models may result in inaccurate performance measurement from a corporate perspective or inconsistent operational alignment between service chain partners.

The State Models also include sample activities that would drive a state transition change. These activities are included as examples of the types of activities and are not an exhaustive description of transition activities.

Glossary of state terms

Outlines of the specific State Models for Incident, Problem, Change, and Release Management are provided in the relevant sub-sections below.

The concept of Inactive versus Active states, as outlined in the relevant tables below, is provided to indicate that once a process reaches an Inactive state, all activity related to that process is completed. In general, re-activating a process that has reached an Inactive state is not allowed.

The same holds true for updating process records. An active state may be updated (e.g., record information updates) while an inactive state cannot be modified.

6.2. Classification models

6.2.1. Classification model

A classification model allows for the filtering of process information, both when the process is activated and following process completion. Classification criteria may be used for triggering notifications and escalation activities, for example, and for historical reporting purposes.

Each classification element provides a specific information element and a significant amount of effort has been made to ensure that classification elements do not overlap. Well considered and coherent classification models provide a range of benefits to the OPS from Operational, Tactical, and Strategic perspectives:

Operational benefits
  • Ensures that operational resources are able to communicate using a common language. For example, a consistent impact and urgency classification structure for Incident Management will ensure that service providers have a clear and common understanding of the true impact and urgency resulting from consistent definitions.
  • Enforces a minimum set of data capture. Reporting requirements, both tactical and strategic, need a minimum set of key information elements to be captured in a process. Without a consistent model, required information may not be collected, or may be captured in a way that is misleading when communicated between partners. This would result in an inability to filter process-specific information during or after the process has concluded.
  • Provides structure when enabling localized classification requirements. Local or service-specific procedures and reporting requirements may necessitate further definition of specific classification values. The TRM allows for such flexibility while maintaining a common, re-usable framework.
Tactical benefits
  • Ensures consistency in OPS performance and operational measurements are achieved using the consistent, well-defined classification of ITSM process information. For example, the definition of Type in Incident Management should be consistent across all service providers to minimize any transformation requirements. Otherwise, a Type classification for one provider could result in a different Type for another provider. This would make it difficult to provide volume reporting on one specific incident type across all providers as classification values would not match.
  • Defines vendor integration specifications when communicating with the OPS. This would simplify vendor activation and replacement. Vendors would map their internal processes and information schemas to a common schema to minimize any additional overhead for the OPS. Whether the vendor is contracted to provide reporting and data (i.e., raw data or informational reports) or their information is accessible electronically (i.e., exchanged via process integration or directly accessible by query tools), the TRM would ensure consistency across the service chain. This approach would also benefit electronic integration activities by minimizing the amount of data value transformation that must be managed. An example would be the transformation of vendor service components (e.g., product categories, service categories, CI categories, etc.) into OPS incident service components and vice versa. Each vendor could potentially have their own service component structure resulting in a transformation challenge both during activation and for ongoing operations.
Strategic benefits
  • Provides a program and/or horizontal service provider view of activity in the form of trend reporting. In the same manner as a unified state model, this could be used to classify similar service provider activities for various service provision types (e.g., volume reporting of password resets, by program or application support provider). This information would then be used to make decisions concerning the program or the provider (e.g., invest in a single, automated password reset service) that support overall service improvement strategies.
  • Ensures consistent measurement criteria across all partners in the service chain. This minimizes ad hoc reporting implementations and representations of information, reducing the complexity of rolling up information captured at the tactical and operational levels. Given the proliferation of information roll-up structures resulting from a growing service chain, the TRM supports consistency and minimize impact (e.g., financial, personnel, etc.).
  • In the same manner as the definition of consistent state models, vendor integration would be simplified with a classification model standard and would facilitate the implementation of an agile environment for service suppliers. Accordingly, vendor procurement would benefit from a set of information exchange policies that establish mandatory criteria for vendor selection.
Alignment with GO-ITS process guides

In the same manner as the state model, the suggested classification values outlined in the GO-ITS guides will be superseded by the TRM following approval at ITELC.

Glossary of classification terminology

Classification models for Incident, Problem, Change, and Release Management are provided in the relevant sub-sections below. Each model includes the information elements, their definitions, the field values (mandatory or optional) for the classification, as well as their individual definitions.

Further work to establish a long-term framework for classification within each process is outstanding. A discussion of such a framework is provided in Appendix A: Future Opportunities, with the intent of promoting dialogue that will contribute to establishing a classification schema and associated values to support strategic as well operational goals for OPS I&IT .

6.3. Service asset and configuration management

6.3.1. Product category classification model

This section establishes the default structure for classifying IT Components that are controlled or referenced within OPS Enterprise Service Management Toolset across all modules, including Incident, Problem, Change, Release, Service Request Management, etc.

Product categorization tier 1Description/Explanation
AccountRepresents a specific type of account that controls access permissions to a given service element/system.
Examples: Application or domain accounts.
ApplicationRepresents a piece of software, either purchased, developed, or composed (re-use of other software components) that provides business functionality of a given service element/system.
Examples: Developed or service-specific Commercial Off the Shelf (COTS) application.
DataRepresents a specific type of system, user, location or organizational data that, when represented in a structured format, represents various types of information utilized by a system.
Examples: application records, case files, data stores.
DocumentationA physical document, authored and owned, that relates to a specific system.
Examples: Build kit, service agreement, Change Management process guide.
FacilityRepresents a physical location that supports some form of IT operations, or houses other IT Components.
Examples: Remote office, data centre, call centre, test lab.
HardwareA physical technological device that supports one or more functions within a system.
Examples: Server, Workstation, Router.
NetworkA logical representation of a network component. While the devices for network are defined as specialized hardware components, there is need to reference the interfaces on network components such as ports, segments, VLANs etc.
Examples: Port 21, Switch Port 9/24, Mission Critical DMZ, Intranet zone, or data components.
ProcessRepresents a series of steps, procedures or work instructions. For example, customer-facing service request types are often represented by a unique procedure that must be followed to complete the request.
Examples: Account management, Asset procurement or change management process
SolutionA collection of capabilities including, but not limited to application software, technologies, components and documentation combined to support a specific problem, business process, or need. A solution generally includes at least one "Commercial off-the-shelf" (COTS) or custom-designed application in its capabilities.
Solutions must be rated for criticality. See "Product Categorization for Solution CI's", below.
Examples:
  • MyOPS is a solution, intra.myops.gov.on.ca is not.
  • iDashboard is a solution, Microsoft SQL Analytics is not.
  • IFIS is a solution, Oracle Financials is not.
  • iPHIS is a solution, Cognos ReportNet is not.
  • LIO Editor is a solution, ArcGIS server is not
StandardA set of enforced guidelines, policies and/or restrictions for a particular aspect of IT.
Examples: Email retention policy, network access security protocol.
Support softwareA piece of software that indirectly supports a system's function, but does not provide the core functionality of a given system.
Examples: Operating System, backup software, anti-virus software.
TrainingRepresents specify type of training that requires to enable a given service element/system.
Examples: Application, process or service training.
ViewLogical groupings of Configuration Items for a specific perspective.
Examples: Hosting Environment view, Application Portfolio View
VoiceA logical representation of a telephony component. While the devices for telephony are defined as specialized hardware components, there is need to reference the interfaces or functions on Telephony components such as T1, PRI, phone feature, etc.
Examples: T1 or SIP Trunk circuits, voice mail feature
Product categorization for solution CI's

For SACM classifications within the Configuration Management Database (CMDB), a solution is defined as follows:

A collection of capabilities including, but not limited to application software, technologies, components and documentation combined together to support a specific problem, business process, or need. A solution generally includes at least one COTS or custom-designed application in its capabilities. All Solution CI's must be rated for criticality at the 3rd tier of categorization, as shown in Table 2 Three Tiers of Solution Categorization, below.

Table 2 Three tiers of solution categorization

Tier 1Tier 2Tier 3
SolutionApplication SolutionBusiness Support
Business Critical
Mission Critical
Personal Productivity
Workgroup Support
SolutionApplication Sub-SolutionBusiness Support
Business Critical
Mission Critical
Personal Productivity
Workgroup Support
Solution criticality definitions

There are currently five criticality ratings that have been specifically defined and broadly adopted following recommendations set forth by the document "Deputy Minister's Briefing for May 12, Management Board of Cabinet", dated May 1998. The five values and their definitions are provided in Table 3 Solution Criticality Categorization at Tier 3 with Definitions, below.

Table 3 Solution criticality categorization at tier 3 with definitions

Tier 3 categoryDescription
Business supportThis category structure should be used for Business Support solutions only where solutions are critical to the operation of a business unit or department, but are not directly essential to the delivery of a public program or service. Business Support differs from Business Critical in that its scope is limited to a smaller business unit.
Business criticalThis category structure should be used for Business Critical solutions only where the solution, i) Supports the government's priorities, and/or ii) Demonstrates a direct link to mission critical systems, application, infrastructure, and/or iii) Demonstrates that failure will threaten mission critical projects, and/or iv) Supports government's stewardship role
Mission criticalThis category structure should be used for Mission Critical solutions only where failure may cause i) Harm to the health of Ontarians, and/or ii) Endanger Ontarians lives or create safety hazards and/or iii) Reduce government's revenue generating capacity and/or iv) Prevent critical payments.
Personal productivityThis category structure should be used for Personal Productivity solutions only where application does not directly support a business program, but is used for general personal productivity
Workgroup supportThis category structure should be used for Workgroup Support solutions only where applications are used to support the operation of a business unit or work group, but are not directly essential to the delivery of a public program or service. Workgroup Support differs from Business Support in that its scope is limited to a much smaller business unit.

In Appendix A, Service Asset and Configuration Management, a brief discussion is provided of future opportunities to clarify the relationship of these five solution criticality ratings to service criticality and to enterprise Incident Management standards (GO-ITS 37) surrounding the use of Impact, Urgency, and Priority.

6.3.2. SACM configuration item status terminology

A CI may go through various stages throughout its lifecycle. Table 4 CI Status and Status Reason Matrix, below, lists Configuration Item status and status reason values and their respective definitions. These status and status reasons are assigned to a CI during its lifecycle in the enterprise configuration management database (CMDB).

Table 4 CI Status and Status Reason Matrix

StatusStatus reasonDescription
OrderedPlannedA need for hardware is defined and a CI is created and includes information that is relevant at the ordered stage. A CI with an "Ordered" status should be associated with a Service Request or CRQ.
OrderedOrderedCI is ordered but not yet shipped.
OrderedShippedCI has been shipped by vendor and we have a list of items.
ReceivedReceivedCI has been shipped to an OPS site and is going to be built/installed.
ReceivedIn StorageCI is in a storage area and available for assignment.
ReservedIn TransitCI is being transferred internally within OPS.
ReservedPossible Re-UseCI is removed from production and is reusable as spare parts.
ReservedReservedCI in a storage area; reserved for a project or initiative.
ReservedSeasonalCI is in storage and indicates the CI is utilized for seasonal work schedules.
Being assembledInstalledCI is installed but not yet configured for use.
Being assembledConfiguredCI is installed and configured for use - that is, any use, including development, test or production.
Being assembledIntegrationCI is undergoing installation of the client's applications and scripts.
Being assembledRelease to Production (RTP)CI has finished going through build and integration work, and is in the process of being transitioned to production and supported by operations (i.e., greened).
Being assembledApp Under DevelopmentDevelopment of the application is underway.
A CI with this State/Status Reason should be associated with an CRQ that has been Approved for Build-Test.
Being assembledApp TestedThe application has been fully tested & certified.
System & User Acceptance testing has been successfully completed and signed-off. Desktop application software has been fully certified.
Being assembledApp Release ReadyThe application is determined to be operationally ready to be supported once it is deployed into production.
DeployedPilotCI is being actively used in production by a limited group of users.
DeployedProductionCI is in Production and is being actively used for its intended function, and all services installed on the service asset or configuration item are up and running.
DeployedApp Retirement PlannedCI is in Production but its retirement has been planned.
In RepairOut for RepairCI is being repaired and unavailable for use.
DownDecommission PendingCI is offline and in a waiting period as part of Decommission process.
DownDisposal PendingCI is offline and in a waiting period as part of Disposal process.
DownDecommissionedCI has been removed from production; disks are wiped.
DownAwaiting RMACI is removed from production due to warranty replacement or order fulfillment error. Awaiting Return Authorization document from vendor as proof of removal from OPS.
DownAwaiting Vendor Pick UpCI is removed from production as retired/refreshed and waiting for vendor pick up.
DownAwaiting Shipment to OSSCI is in vendor's warehouse waiting to ship to OSS.
DownAwaiting Return to LessorCI is in vendor's warehouse waiting to return to lessor.
DownIT-R Decom projectCI is offline and in a waiting period as part of IT-R Project's Decommission process.
DownOut of ServiceCI is not working or unavailable for a prolonged state. Activities are underway to address the problem.
DownLostAsset can no longer be located. It is lost.
DownStolenAsset can no longer be located. It is stolen.
DisposedNon-Standard Disposal SurplusCI has been sent to Asset Disposal that does not comply with standard process. This include asset which was procured by one of OPS I&IT organizations but transferred to another organization outside of OPS.
DisposedSurplusCI has been physically sent to OSS as part of the standard process to be disposed of as surplus.
End of lifeErrorCI record was confirmed to be loaded or created in error.
End of lifeRetiredIntangible asset/CI is no longer in use.
End of lifeIT-R Decom ProjectCI record is no longer used by IT-Rationalization Project.
TransferredTransferredAsset was procured by one of OPS I&IT organizations and transferred to another organization outside of OPS and does not comply with eSACM process.
End of lifeLease EndAt lease end CI has been physically removed from the OPS and CI was returned to lessor.
Return to vendorOrder/Ship ErrorCI was returned to the vendor due to order or shipping error.
Return to vendorReplaced Under WarrantyCI was returned to Vendor under warranty replacement (irreparable etc.). CI has been physically removed from the OPS.

6.3.3. SACM Environment definitions

Assets and configuration items may be deployed in a variety of environments as part of product lifecycle management. This section establishes standard definitions for terminology used to describe these various environments. These terms and their definitions establish a common, consistent terminology for asset deployment environments across the OPS, including documentation and toolsets.

Environment typeDefinition
ProductionAn environment in which hardware, software applications, and other products are put into operation to provide for their intended uses by end users.
"Hot standby"1 products and devices for high-availability purposes should also be considered part of the Production environment.
Production warm standbyA Production Warm Standby environment refers to warm-standby devices used to recover a Production environment during disaster recovery and/or high-availability purposes.
TrainingA Training environment is solely for application and products training purposes.
Pre-productionA Pre-Production environment is a close replica of the production environment and is used to stage a final version of a solution before it is accepted and moved into production. This type of environment is sometimes also known as a Staging environment.
A Pre-Production environment may also be used for User Acceptance Testing (UAT) and sign-off before release to Production. Often, business users are given access to the business application to validate the functionality and to provide business sign-off and acceptance before moving to Production.
TestA Test environment is one in which changes to software and/or applications are being evaluated or tested. A Test environment allows for:
  • Functional QA
  • Technical QA
  • System Integration Testing
  • Performance Testing
  • Sandbox
DevelopmentThe Development environment is one in which changes to software and/or applications are initially developed.

6.4. Service level management terminology

6.4.1. Defining "Service"

The particular importance of defining "service" arises from the over-use of the term and from the casual application of the term to refer to a mixed set of resources, assets, capabilities, or functions. For practical purposes within a terminology model, the term service without an accompanying definition has little value. Thus, for the purposes of this TRM, a working definition of service is put forth, below. That definition is further expanded upon in the following discussion to achieve the specificity that is required to discourage continued misuse and over-use of "service" in the context of OPS I&IT terminology.

To start, the ITIL definition of service (see "OGC - ITIL version 3") puts forth essential elements of a definition that are commonly repeated in many other definitions. The ITIL definition is as follows:

A service is a means of delivering value to Customers by facilitating outcomes Customers want to achieve without the ownership of specific costs and risk.
- Source: "OGC - ITIL Version 3 Service Design"

Another definition that is very useful for its simplicity defines a service as: An exchange of value between two entities in order to achieve specific outcomes.

Repeatedly, definitions of IT service rest on certain concepts to arrive at the desired meaning. The concepts most often repeated are outlined below:

Repeated themeRelated concepts
Outcomesenable, facilitate, deliver, benefit to customer, utility (fit for purpose)
commitment, offering, warranty (fit for use)
Valueexchange of value
delivery of value
Customerspoint-of-view
who is consuming
Ownershipaccountability & responsibility
assumption of costs and risks

For a definition of service to be usable in a practical way, without ambiguity, and with sufficient clarity, some further refinement beyond the broad definitions above will be necessary. For, using the ITIL definition as an example, one could say that an IT solution (application deployed on a system) "is a means of delivering value". Further, one could also argue that the "outcomes Customers want to achieve" include those offered by the solution: task automation, data retrieval, printing, system interoperability, and so on. Similarly, "ownership of specific costs and risks" in developing and delivering the solution rests with the solution provider.

So is a solution a service? It certainly seems to fit the definition nicely. To answer this question, we need to turn to the constructs of the Business Service Management model. Recall that BSM is a change in perspective for IT wherein IT moves from a focus on technology to a focus on the users of IT. Moreover, IT becomes a strategic partner with business by optimizing an integrated service supplier chain through a holistic management of operations, processes, and assets.

In BSM then, the value delivered by IT must have more to do with optimizing the whole service supplier chain of which the solution is only one part. The outcomes customers want to achieve must have more to do with strategic support of a ministry's priorities and mandates than a solution alone can be expected to deliver.

A single, succinct definition of service that fully encapsulates the meaning of the word while providing the possibility of practical application is unrealistic for this current document. Rather, an adequate definition of service for practical, rather than academic use within the OPS will result only from setting forth additional, descriptive characteristics as guidance.

What follows, then, is a Service Information Model that sets forth definitions, a schema, and typical characteristics that, taken together, are intended to provide guidance in the uses of the term service, especially in relation to other common terms such as solution, system, application, and offering.

The Service Information Model will include a number of definitions, illustrations, diagrams, and descriptive characteristics, including:

  • A working definition of IT Business Service and IT Technical Service
  • A Service Information Schema
  • Characteristics of an IT Business Service and an IT Technical Service

6.4.2. Service information model

In a modern, large-scale IT service environment such as that within the Ontario Public Service, it is important to distinguish between IT services that are delivered to business and those that are not directly consumed and valued by business on their own. The distinction between these types of services is captured in the terms 'IT Business Service' and 'IT Technical Service'. Each of these terms is defined, below:

Definition: IT Business service
  • A logical entity that represents the customer-valued outcomes offered/delivered by IT in direct support of a ministry process, program, service, or line of business.

Characteristics of an IT Business Service:

  • Consumed by staff typically outside the IT organization (i.e., a ministry, agency, board, or commission; "the business").
  • Not the technology itself or any tangible commodity but, rather, the combined Technical Services which fully enable business processes and business services.
  • Also known as an "IT service", or an "end-to-end service"
  • Also referred to within the OPS Service Level Management Enterprise Service Agreements Model (eSAM) as "Service for Staff" or "Service for Business"
  • In BSM, an IT Business Service represents the customer view of IT service delivery and provides a meaningful way of reporting on service performance to business leaders.
Definition: IT Technical service
  • A logical entity that represents the supporting technical capabilities offered and/or delivered by IT and valued by IT service and solution providers.

Characteristics of an IT Technical Service:

  • Not valued on its own by business customers.
  • Supports an IT Service, either Technical or Business.
  • Technical Services combine IT capabilities, assets, and resources in logical groupings.
  • Technical Service providers often combine their services with other providers' services (e.g., AD requires Hosting and Networking).
  • Also known as "supporting technical service", or "technical service", "infrastructure service".
  • Also referred to historically within OPS I&IT as "Service for Solution Provider", "or common provider service"

A schema showing the relationship among ministry Business Services, IT Business Services, IT Technical Services, and IT assets is provided in Figure 2, below.

Service information schema

Figure 2 Relationships among types of services and IT assets

Accessible description of figure 2

Image title: "Service Information Schema"

A hierarchy of connected entities divided into four main groupings and one sub-grouping: Starting with the grouping at the top and continuing downward the groupings are: Business Services, IT Business Services, IT Technical Services, IT Components and Products. Beneath this latter grouping is the sub-grouping labelled Individual CI's.

The topmost grouping shows a number of interconnected rectangular shapes to represent a variety of business services. This grouping is described as follows:

Business processes and capabilities are combined within the business to deliver services. This is out of scope for an IT Service Categorization Framework.

The IT Business Services grouping shows two rectangles connected to the Business Service shapes above. The IT Business Services grouping is described as follows:

  1. Title: "Services for Staff" or "Services for Business"

    Description: Customer-valued outcomes offered/delivered by IT. Consumed by staff typically outside the IT org. (i.e., the business). Not the technology itself but, rather, the combined Technical Services which fully enable business processes and business services.

    The IT Technical Services grouping shows three rectangles connected to the IT Business Services shapes above. The IT Technical Services grouping is described as follows:

  2. Title: "Services for Solution Providers"

    Description: Offered and/or delivered by IT. Not valued on their own by the business customers. Supports the IT Service.

Related to the Service Information Schema are the types of service agreements used to capture the warranty requirements for service delivery. In Figure 3 Relationship of Agreement Type to Services, below, a view of the type of service agreement employed to document the approved service delivery commitments and responsibilities between a customer organization and a provider organization.

Figure 3 Relationship of Agreement Type to Services

Figure 3 Relationship of Agreement Type to Services

Accessible description of figure 3

Image title: "Service Agreements Overlay"

A hierarchy of connected entities divided into four main groupings: Starting with the grouping at the top and continuing downward the groupings are: Business Services, IT Business Services, IT Technical Services, and 3rd Party Providers.

The topmost grouping shows a number of interconnected rectangular shapes to represent a variety of business services, which is connected to the IT Business Services grouping below with the following overlay:

  1. Title: "SLA"

    Description: Service Level Agreement (SLA) between I&IT and non-I&IT organizational entities. Documents commitments and responsibilities for end-to-end services as agreed by a business customer and an IT service provider.

The IT Business Services grouping shows two rectangles connected to the Business Service shapes above. The IT Business Services grouping is connected to the IT Technical Services grouping below with the following overlay:

  1. Title: "OLA"

    Description: Operating Level Agreement (OLA) between I&IT organizational entities. Documents commitments and responsibilities for a supporting service along the value chain that creates utility and warranty for IT Business Services, as agreed by the technical service provider and the IT Business Service owner.

The IT Technical Services grouping shows three rectangles connected to the IT Business Services shapes above. The IT Technical Services grouping is connected to the 3rd Party Providers grouping below with the following overlay:

  1. Title: "UC"

    Description: Underpinning Contract (UC) between internal I&IT organizational entities and external (i.e., third-parties, vendor, etc.) organizational entities.

The 3rd Party Providers grouping shows two boxes side-by-side labelled 'Vendor' and '3rd Party Support Provider'. Each of these boxes are separately connected to an IT Technical Service above.

6.4.3. Enterprise service agreement model

Enterprise Service Level Management has adopted a model for establishing and managing service agreements with the various types of provider and customer relationships that exist in the OPS. Effort had been made to simplify terminology and adopt conventional naming of such agreements in order to avoid confusion and to promote transparency and broad adoption.

The Enterprise Service Agreement Model (eSAM) updates the document set hitherto in use within the OPS - the Integrated Service Agreement Model (ISAM) - in favour of greater simplicity and conventional terminology. For an overview of the changes from ISAM to eSAM, please see Appendix B: Glossary, SLM Agreements.

The following table lists the types of formal documentation in the eSAM.

DocumentDescription
IT service agreementDescribes the value of IT in business terms and documents understanding of accountabilities of both business and IT.
Master service level agreementMaster SLA provides "executive summary-type" view of the service levels and compliance targets offered for IT Business Services (end-to-end services). Master SLA is an extension of the Business Service Catalogue that provides key information & service levels pertaining to IT services and service relationships.
Client service level agreementRecords the agreed service levels and compliance targets required by a specific client group for:
  • an IT Business Service consumed by that client group
  • agreed exceptions to the standard IT Business Service offering in order to meet that client group's requirements
Operational level agreementAn agreement between two IT Service Owners within the same organization. An OLA often describes the levels of service and the responsibilities that are required of a supporting technical service in order to meet the agreed Service Level Targets in a customer-facing Service Level Agreement.
Master operational level agreementProvides "executive summary-type" view of the available service levels and compliance targets offered by IT Technical Services in support of service delivery to ministries and end users. It is an extension to the Technical Service Catalogue that provides key information & service levels related to technical services and their service relationships.
Business Service CatalogueProvides a description of all IT services offered to the ministry service recipients. The Business Service Catalogue provides non-IT focused language and easy access to orderable selections.
Technical service catalogueThe Technical Service Catalogue provides IT service providers with the technical specifications, service levels, and compliance targets they can leverage to design, deliver, and support IT Business Services.
External: Service design packageDescribes, in detail the service from both an external view (service recipient) and an internal view (IT organization). Each service listed in Service Catalogue must be underpinned by a Service Design Package (or Service Offering Specification). Since the "Service Owner" is responsible to document the Service Design Package, it ensures agreement to the service delivery commitments.
Underpinning contractAn agreement with an external service supplier/vendor on service specifications and interactions, including the underpinning service levels, compliance targets, processes, and reporting requirements the internal technical service provider depends on to meet his or her respective service level commitments.

6.4.4. SLM performance measurement

For Service Level Management, the measurement of performance with a request-based transaction can include measuring the time elapsed between various states of a transaction. For instance, measuring the time to restore service to a customer uses the Incident Management state model to identify the start and stop times for the measurement to be taken.

To reflect the experience of the customer, the start of measurement is determined by the moment the customer reports the incident the IT Service Desk or a fully qualified (complete with business approval) service request is received. The end of measurement is determined by the restoration of the service to the customer, either through a workaround or a final resolution of the underlying cause of the incident; in the case of a service request, the end point is determined by the request being fulfilled or completed.

In some instances, the activities being undertaken by IT may not be able to progress while an input or a response required from the customer is not available. In such a case, the request record may be placed in a Pending state.

The time elapsed while in Pending will be excluded from the service level performance measurement on the request. Service Level Management usage of process States for performance measurement is summarized in Table 5, below.

Table 5 SLM use of process States for measurement of performance on requests-based transactions

Process metricStart whenExcludeStop when
Service Incident ResolutionState = NewState = PendingState = Resolved
Service Request FulfillmentState = DraftState = PendingState = Completed

When a service level target is attached to the request, unless specifically documented in a formal agreement, the only acceptable Status Reason shall be one directly related to a customer-driven condition. This framework is outline in Table 6, below.

Table 6 Accepted and Negotiated Pending Status Reasons

ProcessAcceptable pending status reasonsExceptions subject to SLA
Incident Management
  • Client Action Required
  • Client Hold
  • Infrastructure Charge
  • Local Site Action Required
  • Purchase Order Approval
  • Registration Approval
  • Supplier Delivery
  • Support Contact Hold
  • Third Party Vendor Action Reqd
  • Request
  • Future Enhancement
  • Monitoring Incident
  • Automated Resolution Reported
Service Request Fulfillment
  • Client Hold
  • Client Hold - 5 days closure notice
  • Requestor Information
  • Approval
  • Best Effort
  • Change Request
  • Date
  • External Service Provider
  • Service Request
  • Site Visit
  • Support Hold

6.5. Incident management terminology

6.5.1. Incident management state model

Incident management state values and definitions
ActiveStatesDefinitions
YesNewThe incident is in the process of being logged. In general, this state is provided to signify that the incident record is not yet complete and therefore, the incident resolution activity has not commenced.
YesAssignedThe incident has been assigned to a service provider in the service chain. The service provider may not accept the incident for action (move to In Progress) and may reassign the incident accordingly. In addition, it is possible that certain service providers (e.g., FPOC at the service desk) may close the incident directly if the customer is not entitled to service.
YesIn ProgressIncident restoration activities are progressing. This may include escalation of the incident to higher tiers of support, both internal and external to the organization.
YesPendingIncident restoration activity is suspended, pending a specific condition (e.g., awaiting customer information). This state can be used to exclude time from the measurement of time elapsed in achieving service level goals (see section 5.4.4 SLM Performance Measurement for additional information).
YesResolvedService has been restored or a request has been fulfilled, from the service provider's perspective. Additional communication is required with the customer to confirm acceptance of the restoration. Restoration does not necessarily represent resolution of the problem that is causing the incident (if appropriate). It signifies that the customer is able to proceed with business activities, potentially through a workaround.
NoClosedIncident management activity has concluded for the particular incident. No further updates are possible once an incident has been placed into this state.
NoCancelledUser requests the incident be cancelled with no further resolution attempted.
Incident management state transition model

Incident management state transition model

Accessible description of Incident management state transition model
  • State: New
  • Step 1.1 Incident is assigned.
  • State: Assigned
  • Step 1.2 Incident is accepted and moves to 'In Progress' state.
  • State: In Progress
  • Step 1.3 Service is restored and the incident is resolved.
  • State: Resolved
  • Step 1.4 Customer follow up and approval to close the incident.
  • Step 1.5 If the customer is not satisfied with the resolution, activity on the incident is resumed.
  • This leads back to the In Progress state.
  • State Pending
  • Step 1.6 Ticket activity on hold.
  • Step 1.7 Activity resumed from hold.
  • Step 1.8 the incident is reassigned.
  • State: Closed
  • Step 1.9 During the Assigned state, an incident can be cancelled.
Incident state transition example activities
State stepActivityDetails
1.1Assign IncidentThe incident is assigned to the appropriate support tier for action. To address the condition where incidents are restored and closed at First Point of Contact (from the customer's perspective), the group that restored service would, by default, be the assigned group for that particular incident.
1.2AcceptedThe service provider to whom the incident has been assigned initiates resolution activities (Service Interruption) or service fulfillment activities (Service Request).
1.3Service RestoredFor Service Interruptions, the customer is able to continue working through restoration of service or through the provision of a workaround. For Service Requests, the service fulfillment has been completed. In both cases, restoration or fulfillment is from the service provider's perspective. The customer is given the opportunity to approve or decline acceptance.
1.4Customer ApprovalThe customer has been provided with an opportunity to approve or decline restoration or fulfillment criteria. This is commonly performed through communicating restoration with an appropriate waiting period for the customer to decline acceptance. This avoids the requirement for the incident owner to have to contact customers individually for acceptance criteria.
1.5Activity ResumedUpon restoring service, the customer identifies that the service is still unavailable.
1.6Activity on HoldThe incident has been placed on hold through some prescribed process. Where possible, qualification of a hold action should be performed to ensure that incidents are not held outside of service agreements (e.g., SLA criteria).
1.7Activity Resumed from HoldThe incident has been removed from hold through some prescribed process. The time that the incident has been on hold is calculated and stored for service level calculation purposes.
1.8Re-AssignedFor many incidents, multiple providers in the service chain may be required to perform activity (SI and SR). This activity is similar to 1.1 but may be required as a separate activity to separate FPOC incidents from Tier 2/3+ dispatch. This activity is beneficial as it clearly supports operating service level (OLA) calculations. The service provider may re-assign the incident if dispatched incorrectly. Localized processes will determine the conditions and to which support group/tier the incident is re-assigned in these cases (e.g., localized requirement may be to assign to the OPS IT Service Desk/Help Desk for subsequent re-assignment).
1.9CancelledUser requests the incident be cancelled with no further resolution attempted.

6.5.2. Incident management classification model

ITIL guidance regarding handling the incident record through the lifecycle of each incident sets forth a number of key principles. These principles can be summarized as follows:

  • The incident record provides all details of an incident as documentation of the history of the Incident from registration to resolution
  • Each incident is to be fully and carefully recorded and prioritized in order to facilitate a quick and effective resolution
  • All information pertaining to the nature of the incident must be logged thoroughly so that a complete historical record exists
    • This ensures that if the incident must be referred to any other support group(s), those agents will have all relevant information available to assist them carry out quick and effective resolution
  • Where the original categorization of an incident is determined to be incorrect through subsequent problem determination activities, a separate resolution/closure categorization is to be included and the original categorization is not to be corrupted
  • Prior to incident closure, the incident record undergoes a final quality control. This helps ensure that:
    • The incident is actually resolved
    • All information required to describe the Incident's lifecycle is supplied in sufficient detail
    • The resolution activities carried out by IT for the Incident are recorded for future use

Following from these best practices, several specific elements of classification for incident records are used as part of Enterprise Incident Management in the OPS (these are in addition to Incident Criticality classifications covered in "GO-ITS #37 Enterprise Incident Management Process" and provided for reference in Appendix B: Glossary, Process Priority Matrices). These elements of classification include:

  • Incident Type
  • Operational Categorization
  • Resolution Categorization
  • Reported Source

Further, as part of the Operational Categorization of an incident record, a Product Categorization may be included. Likewise, as part of Resolution Categorization, Resolution Product Categorization may be included. In keeping with the Business Service Management model, an incident record must also be associated with a Service CI; it may additionally be associated with an asset CI.

These informational elements, taken together, provide a detailed picture, or story, regarding a specific instance of a customer's experience, along with IT's response and resolution activities related to that incident. The end result is a complete historical record of each customer-IT interaction that, in aggregate, provides the basis for generating crucial data and information. These data and information provide important inputs to a number of ITSM and operational activities, including:

  • Operational analyses by service providers
  • Problem Management analyses
  • SLM measuring, monitoring, and reporting
  • Demand management
  • Capacity management
  • Service Desk operational management
  • Knowledge management

The informational elements on the incident recorded are described and their values defined (where appropriate) in the following sub-sections, specifically:

  • Incident Type
  • Reported Source
  • Service +
  • CI +
  • Operational Categorization
  • Operational Product Categorization
  • Resolution Categorization
  • Resolution Product Categorization
Incident type

The incident type is used for categorizing the nature of the incident. The incident type can be used for reporting and query purposes. Available incident types include:

Incident typeDescription
User service restorationUser reports a service is interrupted and is not functioning, or some aspect of the service is not functioning
User service requestUser is requesting enabling, assistance with, or information about a service
Infrastructure restorationTypically reported by operations teams when some aspect of the infrastructure is interrupted and not functioning
Infrastructure eventAutomated event monitoring technology reports infrastructure disruption
Reported source

When a contact is received, the Service Desk Agent (SDA) specifies the source of the contact. The values provided below are provided here for reference purposes and copied from the "GO-ITS 55 Service Desk" document.

Available reported sources include:

Reported sourceDescription
PhoneIncoming phone, the Service Desk Agent (SDA) receives a call by phone
E-MailIncoming email, the Service Desk Agent (SDA) receives a contact by e-mail
FaxIncoming fax, the Service Desk Agent (SDA) receives a contact by fax
System managementAutomated event monitoring technology advises Service Desk Agent (SDA) of infrastructure disruption
Voice mailUser unable to contact Service Desk Agent (SDA) directly. Voice mail is provided summarizing scope of request.
Walk InService Desk Agent (SDA) engaged via a local resource walk up
WebWeb interaction, a contact is submitted by means of a web-client (i.e., Self Service)
Electronic bridgeElectronic interface between a 3rd party's Service Management tool and the OPS IT Service Desk
Direct inputeSMT user logs an incident on behalf of him/herself
Note: Not to be used; eSMT users are not permitted to log incidents independent of the Service Desk.
OtherOther source not mentioned
External escalationContact received as the result of an external escalation
BMC Impact manager eventIncident generated by BMC Impact Management
Self serviceIncidents generated by the user interacting with Service Desk Online
Service+

The "Service+" field identifies the user-reported service impacted or implicated by the incident.

For example: A client contacts the service desk to report an issue with his or her telephone. The IT Business Service impacted is the "Managed Telephone Service" (example only) and this value will be selected for entry in the Service+ field.

Note: The available Service+ values are determined by Service Catalogue Management (currently under Service Level Management control) and the Service CI attributes are part of the SACM model.

CI+

The "CI+" identifies the Configuration Item (CI) that is reported as the cause of the issue a client is experiencing or is the initial component determined by the service desk as the cause of the incident.

Because the root cause of an issue may change during the lifespan of the incident, the CI+ field must be verified and updated, if required, when the incident is resolved.

Note: The available CI+ values are determined by Service Asset and Configuration Management.

Operational categorization

The table below puts forth the current values in use by Enterprise Incident Management for Tier 1 Operational Categorization. (Refer to Appendix A for an exploration of future opportunities for evolving Operational categorization).

Classifications: Operational Categorization

Definitions: Categorizes the incident based on a customer's request and Service Desk agent's triage of the incident being registered (nature of the incident).

Field valuesDefinitions
Service Interruption - FaultA Service is interrupted and is not functioning or some aspect of the service is not functioning.
Service Interruption - DegradationThe Service is functioning at a degraded level (e.g., slow).
Service Interruption - UnavailableA Service is interrupted and is unavailable for normal use.
Service Request - GeneralA service request (e.g., move/add/change) is required for a Service (e.g., add a new user, change a profile setting). Some service request activities represent a subset of standard changes.
Service Request - Information RequestA customer has requested information on a particular Service or Service activity (e.g., process).
Service Request - How ToA customer is requesting guidance in the use of a Service (e.g., How do I change my password?).
Service Request - Password ResetA customer is requesting a password reset on a system, or requires a new password due to other circumstances (e.g., I forgot...).
Service Request - SecurityThe incident is a security-driven service request (e.g., move/add/change).
Service Interruption - SecurityThe incident is a security-driven interruption (e.g., Virus message or virus-related activity).
ClassificationsDefinitionsField values/definitions
Operational Product CategorizationThe IT Product categorization for the initial diagnosis of the incident.Product Categorization terminology is provided via the Service Asset and Configuration Management process and classification model. Please refer to the "Product Category Classification Model" section on page 35.
Resolution categorization

The table below puts forth the current values in use by Enterprise Incident Management for Tier 1 Resolution categorization.

Classifications: Resolution Categorization

Definitions: The activity required by IT to resolve the incident and restore service.

Field valuesDefinitions
Advice GivenThe customer was provided with the information they requested (e.g., How-to, Information Request, Standard etc.).
Restored/FulfilledThe service has been restored or the request has been fulfilled accordingly.
No Fault FoundUpon diagnosis, no incident was determined and the customer was able to resume normal operations.
Requester CancelledThe customer cancelled the request prior to incident resolution. (e.g., "It was my fault…")
Workaround ProvidedThe customer was able to resume activity through a workaround however the cause of the incident is still unknown and/or unresolved. The incident would be closed but may be associated to a problem.
Not EntitledThe customer is not entitled to service restoration or fulfillment activities (e.g., have not purchased a specific level of service and therefore option x is not available, or the customer is not paying for the service in question).
ClassificationsDefinitionsField values/definitions
Resolution Product CategorizationThe IT Product categorization for the component that was subject to the resolution activities of the incident (the at-fault component).Product Categorization terminology is provided via the Service Asset and Configuration Management process and classification model. Please refer to the "Product Category Classification Model" section on page 35.

6.6. Problem management terminology

6.6.1. Problem management state model

Problem management state values and definitions
ActiveStatesDefinitions
YesDraftThe Problem is in the process of being logged. In general, this state is provided to signify that the problem record is not yet complete and therefore, the problem management activity has not commenced.
YesUnder ReviewThe Problem Investigation has been submitted and is currently being reviewed by the Problem Coordinator to ensure the investigation is valid
NoRequest for Authorization 
YesAssignedThe problem has been assigned to a Problem team for active management and root cause analysis.
YesUnder InvestigationWork has commenced to solve the problem. Incidents may continue to be related to the Problem Record during this phase providing the Problem team with additional information.
YesPendingProblem Management activities are suspended and no active root cause analysis is occurring.
YesCompletedProblem Management activities have investigated the issue and implemented a fix.
YesRejectedThe Problem Investigation does not meet the criteria for Problem Management.
YesClosedProblem Management activities have investigated the issue but determined that the underlying issue will not be fixed.
YesCancelledThe requester has cancelled their request for a Problem Investigation.
Problem management state transition model

Problem management state transition model

Accessible description of problem management state transition model
  • State: Draft
  • Step 1.1 Submitted for review.
  • State: Under Review
  • Step 1.2 the ticket is assigned and the state is changed to 'assigned'.
  • State: Assigned
  • Step 1.3 the ticket is under investigation.
  • State: Under Investigation
  • Step 1.4 the ticket under investigation can be reassigned.
  • State: Pending
  • Step 1.5 a reassigned ticket can be in pending state for some time before being assigned again.
  • Step 1.6 a reassigned ticket can be in pending state for some time before being reinvestigated.
  • State: Closed
  • Step 1.7 a ticket under investigation can be closed.
  • State: Completed
  • Step 1.8 a ticket under investigation can be completed.
  • State: Cancelled
  • Step 1.9 a ticket under review can also be cancelled.
  • State: Rejected
  • Step 1.3 a ticket under review can be rejected directly.
State transition example activities
State stepActivityDetails
1.1Submitted for ReviewThe Problem Investigation has moved from a Draft State to an Under Review state. The Problem Investigation will be reviewed by the Problem Coordinator
1.2AssignedThe Problem Investigation has been assigned to the primary Service Owner for the application or service that is believed to be the root cause.
1.3Under InvestigationThe Problem Investigation is actively being investigated by the assigned team.
1.4Re-AssignedThe problem resolution team reviews the submission and determines the problem has not been assigned to the appropriate team. The problem is reassigned to a different resolution team.
Re-assignment may also be necessary if after a resolution team initially accepts the submission, but after further investigation determines the problem has not been assigned to the appropriate team.
1.5Transition to PendingAll Problem Management activity is suspended based on some prescribed process. Where possible, qualification of a hold action may be performed to ensure that problems are not held outside of service agreements (e.g., service level criteria).
1.6Transition from PendingThe problem has been removed from hold through some prescribed process. The time that the problem has been on hold may be calculated and stored for process measurement (or service level) calculation purposes.
1.7Closed Problem InvestigationThe Problem Investigation has been completed but the Service Owner has decided that the appropriate fix will not be implemented. This could be due to costs for future projects.
1.8Completed Problem InvestigationThe appropriate fix has been implemented, usually through CRQ, to resolve the Root Cause of the Problem Investigation.
1.9CancelledAt any time during a Problem Investigation it can be cancelled. This stops all problem management activity.

1.1.1. Known error state model

Known error state values
ActiveStatesDefinitions
YesAssignedThe Known Error has been identified and assigned to the Service Owner to apply a permanent fix
YesScheduled for CorrectionA scheduled patch or maintenance has been identified. This often will have an associated CRQ
NoAssigned to Vendor 
YesNo Action PlannedThe Known Error will not have corrective action taken to permanently resolve it
YesCorrectedThe Known Error has been corrected
YesClosedThe Known Error has been corrected and confirmed that it is no longer a part of the environment and no Incidents are being logged against it.
YesCancelledThe Known Error was incorrectly created and does not meet the criteria of a Known Error

Known Error State Transition Model

Accessible description for known error state transition model
  • State: Assigned
  • Step 1.1 Ticket is assigned with action planned.
  • Step 1.2 the ticket can also be assigned with no action planned.
  • State: Scheduled for correction
  • Step 1.3 Corrective action is taken.
  • State: No action planned
  • State: Corrected
  • State: Closed
  • Step 1.4 If the issue is corrected, the ticket is closed.
  • State: Cancelled
  • Step 1.5 once a ticket is assigned, it can be cancelled with no further action needed.
Known error state transition example activities
State stepActivityDetails
1.1Assigned with Action PlannedThe Known Error has been assigned and an action plan has been established to permanently resolve the Known Error.
1.2Assigned with No Action PlannedThe Known Error has been assigned to the responsible support group but No Action is currently planned to remedy the error or a permanent solution is not yet known
1.3Corrective action takenA CRQ has been completed and the problem has been corrected.
1.4ClosedThe Known Error has been corrected and it has been confirmed that it is no longer causing incidents
1.5CancelledThe Known Error was incorrectly logged or was not valid

6.6.2. Problem management classification model

Classifications: Operational Categorization

Definitions: Categorizes the incident based on a customer's request and Service Desk agent's triage of the incident being registered (nature of the incident).

Field valuesDefinitions
Service Interruption - FaultA Service is interrupted and is not functioning or some aspect of the service is not functioning.
Service Interruption - DegradationThe Service is functioning at a degraded level (e.g., slow).
Service Interruption - UnavailableA Service is interrupted and is unavailable for normal use.
Service Request - GeneralA service request (e.g., move/add/change) is required for a Service (e.g., add a new user, change a profile setting). Some service request activities represent a subset of standard changes.
Service Request - Information RequestA customer has requested information on a particular Service or Service activity (e.g., process).
Service Request - How ToA customer is requesting guidance in the use of a Service (e.g., How do I change my password?).
Service Request - Password ResetA customer is requesting a password reset on a system, or requires a new password due to other circumstances (e.g., I forgot...).
Service Request - SecurityThe incident is a security-driven service request (e.g., move/add/change).
Service Interruption - SecurityThe incident is a security-driven interruption (e.g., Virus message or virus-related activity).
ClassificationsDefinitionsField values/definitions
Operational product categorizationThe IT Product categorization for the initial root cause identification of the problem.Product Categorization terminology is provided via the Service Asset and Configuration Management process and classification model. Please refer to the "Product Category Classification Model" section on page 35.

Classifications: Impact

Definitions: Measure of scope and criticality to business. Often equal to the extent to which a problem leads, or may lead to distortion of agreed or expected service levels. Impact is often measured by the number of people, critical systems affected, or by the financial loss resulting from the service interruption. Problems may default to a pre-defined impact based upon the service category, component category and incident/problem Type

Field valuesCriteria (At least 1 criterion must be met)
1‐Extensive/ WidespreadApplication, service, or infrastructure problem resulting in major incidents that effect:
  • All sites
  • Large customer groups (e.g., multiple regions or ministries)
  • Potential to impact public safety
  • Mission critical applications
  • Citizen facing applications or services
2‐Significant/LargeApplication, service, or infrastructure problem resulting in incidents that effect a localized group (e.g., region, district) or a significant degradation in IT service affecting localized group(s):
  • Large group where work can continue
  • Small group where work cannot continue (e.g., single office)
  • Business critical applications
3‐Moderate/LimitedApplication, service, or infrastructure problem resulting in incidents that effect:
  • Small group where work can continue
  • Business support applications
4‐Minor/LocalizedApplication, service, or infrastructure problem resulting in incidents or alerts that are non‐service impacting.

Classifications: Urgency

Definitions: Measures how quickly a Problem needs to be responded to base on the business needs of the customer and how long it will be until the Problem has a significant Impact on the Business. Urgency is decided by assessment of the likelihood that problem will cause future incidents.

Field valuesCriteria (At least 1 criterion must be met)
1‐CriticalThe problem will almost certainly recur within a week. A workaround has not been identified and a degraded mode of operation is not available or not acceptable.
2‐HighThe problem will recur but not likely in the next week. A workaround has been identified or a degraded mode of operation is available and acceptable.
3‐MediumThe problem is not likely to recur. A workaround has been identified or a degraded mode of operation is available and acceptable.
4‐LowThe problem is non-service impacting and not likely to ever impact service.

6.7. Change management terminology

6.7.1. 'Change management state model

Change management state values and definitions
ActiveStatesDefinitions
YesDraftCRQ is being created and not yet submitted for approval to begin assessment
YesRequest for ChangeCRQ has been drafted and submitted for approval by the Change Manager for assessment.
YesPlanning in ProgressCRQ is approved and being assessed by impacted stakeholders. Scheduling activities take place during this phase.
YesScheduled for ApprovalCRQ is assessed, scheduled and submitted for approval by Jurisdictional Change Managers and Corporate CAB (if required) for implementation.
YesScheduledCRQ is approved for implementation and is awaiting implementation.
YesImplementation in ProgressCRQ is being implemented; implementation tasks are being performed.
YesCompletedAll implementation activities are completed for the CRQ.
YesPendingThe CRQ is on hold.
Note: A status reason is mandatory when putting a change into Pending.
YesRejectedThe CRQ has been rejected by the Change Manager.
NoClosedAll post implementation activities are completed including verification activities. The outcome of the change (successful vs. not successful) can be identified and documented. The change can be closed.
NoCancelledThe CRQ has been cancelled and there are no longer any plans to perform implementation under the CRQ.

The two separate Change State Transition Model diagrams (Section 0) are provided in order to reduce the overlapping information for each state view. The first diagram provides the basic state model. The second diagram shows conditions when changes may be pended or cancelled. Permissible state transitions are also outlined in Table 7 Change State Transitions, below.

Change management state transitions

Note: From a technology perspective, the OPS ITSM Tool may allow for additional status transitions.

Table 7 Change state transitions

"From" status"To" status
DraftRequest for Change
DraftCancelled
DraftPending
Request for ChangePlanning in Progress
Request for ChangeRejected
Cancelled
Planning in ProgressScheduled for Approval
Planning in ProgressPending
Planning in ProgressCancelled
Scheduled for ApprovalScheduled
Scheduled for ApprovalRejected
Cancelled
Scheduled for ApprovalPlanning in Progress
(If re-assessment has been initiated)
ScheduledImplementation in Progress
ScheduledPlanning in Progress
(If re-assessment has been initiated)
Implementation in ProgressCompleted
Implementation in ProgressPending
Implementation in ProgressCancelled
CompletedClosed
Pending

The following diagrams depict the current state transition model enabled in the OPS I&IT ITSM enablement toolset.

Change management state transition

Accessible description of change management state transition
  • State: Draft
  • Step 1.1 Create CRQ.
  • Step 1.2 Submit CRQ.
  • State: Request for Change
  • Step 1.3 Review by Change Manager.
  • State: Planning in Progress
  • Step 1.4 Review and Complete Assessment Tasks.
  • State: Scheduled for Approval
  • Step 1.5 Approve CRQ for implementation.
  • State: Scheduled
  • State: Implementation in Progress
  • Step 1.6 Review and Complete Implementation Tasks.
  • State: Completed
  • Step 1.7 Validate and Complete CRQ.
  • State: Closed
  • Step 1.8 Re-assessment - this can occur at both the Scheduled for Approval state or the Scheduled State. Re-assessments lead back to Planning in Progress state.
  • State: Rejected
  • Step 1.9 Restart - restart the CRQ process, starting at the Request for Change state.
  • Step 1.11 Standard CRQ - CRQ moves from Planning in Progress state to Scheduled state.
  • Step 1.12 Latent CRQ - CRQ moves from Request for Change state to Completed.

Change management state transition for pending and cancelled

Accessible description of change management state transition for pending and cancelled
  • State: Draft
  • Step 1.1 Create CRQ.
  • Step 1.2 Submit CRQ.
  • Step 1.10 Resume - CRQ has been removed from Pending state and can resume the CRQ approval process.
  • State: Request for change
  • Step 1.3 Review by change manager.
  • Step 1.9 Restart - CRQ may move to Rejected state at this point and must return to Request for Change state.
  • State: Planning in progress
  • Step 1.4 Review and complete assessment tasks.
  • Step 1.10 Resume - CRQ has been removed from Pending state and can resume the CRQ approval process.
  • State: Scheduled for approval
  • Step 1.5 Approve CRQ for implementation.
  • State: Scheduled
  • Step 1.10 Resume - CRQ has been removed from Pending state and can resume the CRQ approval process.
  • State: Implementation in progress
  • Step 1.6 Review and complete implementation tasks.
  • Step 1.10 Resume - CRQ has been removed from Pending state and can resume the CRQ approval process.
  • State: Completed
  • Step 1.7 Validate and complete CRQ.
  • Step 1.10 Resume - CRQ has been removed from Pending state and can resume the CRQ approval process.
  • State: Closed
  • State: Cancelled

At any point of the CRQ approval process before Completed state, the CRQ may be cancelled.

State transition example activities
StateStep/activityDetails
Draft1.1 Create CRQThe change requestor has created a CRQ, but has not submitted it for Change Management review and approval.
Draft1.2 Submit CRQThe change requestor has submitted the CRQ for Change Management review & approval. CRQ
Request for change1.3 Review by Change ManagerThe Change Manager reviews the CRQ for accuracy and completeness. If approved, the CRQ is advanced to Planning in Progress. If an issue is found, the Change Manager will reject the CRQ and notify the change requestor.
Planning in progress1.4 Review & Complete Assessment TasksCRQ has been approved and being assessed by impacted stakeholders. Scheduling activities take place during this phase.
Scheduled for approval1.5 Approve CRQ for ImplementationCRQ has been assessed, scheduled and submitted for approval by Jurisdictional Change Managers and Corporate CAB (if required) for implementation.
ScheduledN/ACRQ has been approved for implementation and is awaiting implementation.
Implementation in progress1.6 Review & Complete Implementation TasksCRQ is being implemented; implementation tasks are being performed.
Completed1.7 Validate & Complete CRQAll implementation activities have been completed for the CRQ.
ClosedN/AAll post implementation activities have been completed including verification activities. The outcome of the change (successful vs. not successful) can be identified and documented. The change can be closed.
Closed1.8 Re-assessment 
Rejected1.9 RestartCRQ has been Rejected by Change Management due to not meeting the necessary criteria for approval. Once the Requestor has updated the CRQ they may restart the CRQ to seek approval.
Pending1.10 ResumeCRQ has been taken off Pending, Re-assessment may be required if there has been a change in scope or Scheduled Implementation Dates.
CancelledN/ACRQ has been cancelled and there are no longer any plans to perform implementation under the CRQ.
N/A1.11 Standard CRQCRQ is approved as per Standard CRQ process. Does not require Implementation approval.
N/A1.12 Latent CRQCRQ is approved as per Latent CRQ process. Upon approval, the CRQ is advanced to Completed state.

6.7.2. Change management classification model

Change management record classification

Note: An Operational Categorization element was added to the Change Management enabling tool as part of the transition to the Enterprise Service Management Tool (eSMT). An agreed definition and set of operational categorization values has yet to be arrived at. Operational Categorization is therefore not treated in this version of the TRM. A discussion of the future opportunities and some recommendations for operational categorization are provided in Appendix A (see "Change and Release Management Classification").

The following table provides in-use change record classification elements along with their definitions and accepted values.

ClassificationsDefinitionsField vluesDefinitions
Operational CategorizationCategorizes the change record based on actions to address a root cause or on actions to introduce service components into the IT environmentTBD (for a discussion of opportunity, please see Appendix A)N/A
ClassSpecifies the relative urgency of the change, so that approvers can assess its magnitudeNormalA change that meets the required submission lead time and follows all the defined steps of the eCM process.
ClassSpecifies the relative urgency of the change, so that approvers can assess its magnitudeStandardLow risk, relatively common change that follows a repeatable procedure or set of work instructions. Standard changes are "pre-approved" and therefore bypass the Approve Change for Implementation step in the change process. In situations where a new or existing Standard Change needs to be approved or removed please refer to the eCM Process Procedures Guide
ClassSpecifies the relative urgency of the change, so that approvers can assess its magnitudeExpeditedUtilized when a change does not meet submission lead times. Follows the full change request workflow under expedited timelines.
ClassSpecifies the relative urgency of the change, so that approvers can assess its magnitudeEmergencyAuthorized by an Emergency Change Advisory Board (ECAB), the change is driven by an Incident (e.g., break-fix). Follows the full change request workflow under accelerated timelines.
ClassSpecifies the relative urgency of the change, so that approvers can assess its magnitudeAdvisoryA change to non-OPS owned or managed infrastructure or a change used to communicate information to impacted Change Management stakeholders; it does not involve an implementation of any kind. Advisory changes are "exempt" from OPS eCM Approve Change for Implementation step, but still require communication to Change Management stakeholders as well as identifying any risks, impacts and potential outages. In situations where an exception must be made, it should be discussed and approved through the eCM Community of Interest (COI).
ClassSpecifies the relative urgency of the change, so that approvers can assess its magnitudeLatentA change that has already been implemented. Latent changes must have an incident associated as the driver for implementing the change.
Risk LevelThe criterion used to determine the required approvals. Risk Assessment involves computing the overall risk based on risk related questions and derived risk factors.Risk Level 1Minor Change impacting fewer than 2 Clusters - does not require Corporate Change approval
Risk LevelThe criterion used to determine the required approvals. Risk Assessment involves computing the overall risk based on risk related questions and derived risk factors.Risk Level 2Significant Change impacting fewer than 2 Clusters - does not require Corporate Change approval
Risk LevelThe criterion used to determine the required approvals. Risk Assessment involves computing the overall risk based on risk related questions and derived risk factors.Risk Level 3Major Change impacting fewer than 2 Clusters - does not require Corporate Change approval
Risk LevelThe criterion used to determine the required approvals. Risk Assessment involves computing the overall risk based on risk related questions and derived risk factors.Risk Level 4Minor Change impacting 2 or more Clusters - requires Corporate Change approval
Risk LevelThe criterion used to determine the required approvals. Risk Assessment involves computing the overall risk based on risk related questions and derived risk factors.Risk Level 5Significant/Major Change impacting 2 or more Clusters - requires Corporate Change approval
Product CategorizationThe IT Service Product classification for the change.Product categorization terminology is provided via the Service Asset and Configuration Management process and classification model. Please refer to the Error! Reference source not found. section on page Error! Bookmark not defined..Product categorization terminology is provided via the Service Asset and Configuration Management process and classification model. Please refer to the Error! Reference source not found. section on page Error! Bookmark not defined..
Change Completion and closure classification

Classifications: Completed status reason

Definitions: The classification of the change from the change coordinator's perspective when all implementation activities have been completed.

Field valuesDefinitions
Implemented - As PlannedThe change was implemented as planned and within approved timeframes.
Implemented - Not As PlannedThe change was implemented but it was implemented with modifications such as exceeding the scheduled change window.
Partially ImplementedA portion of the change was successfully implemented, but other portions were either backed out or not implemented.
Not Implemented - Backed OutThe change was not implemented as it needed to be backed out.
Not ImplementedThe change was not implemented.

Classifications: Closed Status Reasons

Definitions:The classification of the change's success from the Change Manager's perspective

Field valuesDefinitions
SuccessfulThe change was completely successful.
Successful with IssuesThe change was implemented successfully as per implementation plan, however did not succeed in meeting the client's business need.
UnsuccessfulThe change was unsuccessful and was not backed out as it could cause greater impact to do the customer to do so or could not be backed out.
Backed OutThe change was unsuccessful but was successfully backed out.
Without ApprovalThe change was completed without Change Manager Implementation Approval

6.8. Release management terminology

The eRM process works to ensure I&IT infrastructure, solutions, and services are successfully released to production and that post-implementation support structures are in place across the end-to-end I&IT supply chain.

The purpose of eRM is to provide value to the Customers by minimizing the risk of releasing to production new or changed I&IT infrastructure, solutions, or services and ensure it meets or exceeds agreed-upon service levels.

The implementation of the eRM process enables the careful oversight of changes to IT solutions/services ensuring implementation is in accordance with other ITSM processes and aligned with business needs, in keeping with the Business Service Management model. In addition, eRM enables successful activations by ensuring effective pre-operation communications between all groups involved in IT solution/service projects.

The following sections set out the core terminology introduced with the Release Management process.

6.8.1. Release management milestone and state model

Release management milestone values and definitions
MilestoneDescription
InitiateA Release request is made and entered in the Release Repository. A Release Assessment is held with the Project Manager and impacted cluster release leads.
PlanningA Release Announcement is sent to potential Release stakeholder groups to communicate the upcoming Release.
A Release Plan is created where the stakeholder participants and release timelines are confirmed.
BuildThe Release Kick Off is held and Release team stakeholder deliverables are confirmed and communicated.
Recurring Release status meetings are scheduled to track the status of Release deliverables.
TestAny sort of End to End testing activities are completed in this Milestone. The Pre Go/No-Go and Go/No-Go meetings are held. Decision from the Go/No-Go meeting is communicated and if the decision is a "Go" or "Go with Action", we move to the Deployment Milestone.
If the decision is not a Go, we move back to the Build Milestone and resume Release meetings.
DeploymentAny post activation items from the Go/No-Go meeting are monitored and tracked to completion during the Stabilization phase which occurs in this Milestone.
Close downConfirmation that release activities have been completed and the Release can be closed.
Release management state values and definitions
StatusDefinition
DraftThis is the default status when a new release record is created. It is only available within the Initiate Milestone.
ApprovalUsed to request approval from the Release Manager to move to the next Milestone. Please note that this approval is automated by default within the current tool.
In progressUsed to indicate that the Release activities are in progress within the current Milestone.
PendingUsed if the Release is to be put on hold. A Status Reason is required when moving a Release to Pending Status.
RejectedUsed in the Initiate Milestone to indicate if the release has been cancelled before moving into the Planning Milestone.
Release management milestone transitions

Release management milestone transitions

Accessible description of release management milestone transitions

The Release Management Milestone Transition figure is split into 6 blocks that follow one after the other. The milestone blocks are each listed and described below:

  1. Title: Initiate
    Description:
    • Determine scope of a project
    • Confirm Release Type
    • Confirm Costing (if applicable)
    • Assign Release Coordinator (if required)
  2. Title: Planning
    Description:
    • Timelines
    • When/Whom
    • Collaterals & Training
    • Stakeholders
    • Communications
  3. Title: Build
    Description:
    • Build Support
    • Collaterals & Training
    • Pilot (plan)
    • Communication
    • Workshops
  4. Title: Test
    Description:
    • Pilot (executive)
    • Go/No-Go
    • Communication
  5. Title: Deployment
    Description:
    • Activation/Deployment
    • Stabilization Period
    • Maintaining issue log
    • Reporting
    • Communicate results
  6. Title: Close Down
    Description:
    • Create Scorecard
    • Lessons Learned
    • Communication
    • Close Release Record
Release management milestone/state transitions

Table ## Release state transitions

"From" milestone"To" milestone/status
Initiate
  • Draft
  • Initiation Approval
  • Pending
  • Rejected
  • Cancelled
Planning
  • Pending
  • In Progress
  • Planning Approval
  • Cancelled
Build
  • Pending
  • In Progress
  • Build Approval
  • Cancelled
Test
  • Pending
  • In Progress
  • Test Approval
  • Cancelled
Deployment
  • Pending
  • In Progress
  • Deployment Approval
  • Cancelled
Close down
  • Completed
  • Close Down Approval
  • Closed
  • Rejected
  • Cancelled

6.8.2. Release management classification model

Business justification

Predefined list of values in eSMT to indicate the driver for the Release. Business Unit Strategic

  • Corporate Strategic
  • Customer Commitment
  • Defect
  • Enhancement
  • Maintenance
  • Sarbanes-Oxley
  • Upgrade
Operational classification

Operational Categories are used to provide a snapshot of the current "Health" of a Release

Tier 1: Release Activity Healthy

Tier 2:

  • Green (On Track for Go-Live)
  • Yellow (May Not Meet Go-Live Date)
  • Red (Will Not Meet Go-Live Date)
Release management release types

Note: The Release Types are identified through the mapping of the Impact, Urgency and Priority fields in eSMT. The mapping table is provided below.

Release typeRelease criteriaLevel of work effort and estimated timelines
Minor / localized
  • Service change is seamless to operations and transparent to users
  • Small group of users affected by service change
  • Minimal to no end-user involvement
  • Minimal training requirements for staff and support levels
  • None to minimal external resource requirements
  • No Cost if assessment is completed and no formal Release activities are required
  • A "Minor / Localized" release is often one or more small corrective modifications to a specific error and/or to previously implemented solutions.
  • Requires Change Request (CRQ)
Moderate / limited
  • Service change is seamless to operations and transparent to users
  • Small group of users affected by service change
  • Minimal to no end-user involvement
  • Minimal training requirements for staff and support levels
  • None to minimal external resource requirements
  • Level of effort is estimated to be less than 30 business days
  • Requires: eRM, Change Request (CRQ) and Test/Pilot
Significant / large
  • Multi Release jurisdictions required
  • Registered Project required
  • New service for small group or specialized user/groups e.g., Lines of Business, Branch or Section
  • Service change to existing service affecting multiple businesses
  • Requires internal approvals by governing bodies e.g., ITSML, ACT/ARB
  • Multi party service chain
  • Moderate end user involvement
  • Requires training e.g., complex processing
  • Multifaceted dimensions to roll-out businesses, different functionalities within the service, dependencies with other services/technologies
  • Decommissioning or retiring services
  • Has potential to impact end user experience / productivity e.g., major technology upgrade visible to users
  • Level of effort is estimated to be between 30 and 60 business days
  • Requires: eRM, Change Request (CRQ) and Test / Pilot.
Extensive / widespread
  • Major new service introduction
  • Other Release jurisdictions impact (med-high)
  • Impacts public safety or public facing business service
  • Multiple Ministries wide business impact
  • Requires Senior Executive approval
  • Executive Office / VIP services
  • Highly sensitive e.g., legislation, privacy, political
  • Significant resource requirement
  • IT standard or legislation driven implementation end date
  • New Service Provider or Owner (e.g., network provider)
  • The Service change is core to transforming and optimizing the service
  • Includes both "Moderate / Limited" and "Significant/Large" release criteria but involves more Stakeholders, has higher visibility, impact and priority than a "Significant/Large" release
  • Level of effort is estimated to be greater than 60 business days (12 weeks)
  • An "Extensive / Widespread" release can be complex and/or typically represents a significant roll-out of hardware and software which introduces important modifications to the functionality, technical characteristics, etc.
  • For example; software releases and hardware upgrades, normally containing large amounts of new functionality, some of which may make intervening fixes to problems redundant. A major upgrade or release usually supersedes all preceding minor upgrades, releases and emergency fixes
  • Requires: Registered Project and eRM
Release type mapping table:
TypePriorityImpactUrgency
Minor/LocalizedLow (4)44
Moderate/LimitedMedium (3)33
Significant/LargeHigh (2)22
Extensive/WidespreadCritical (1)11
Release management risk levels

Risk level

Used to identify the Risk associated to the Release. Risk Level is defined by two values.

  • Risk Level 1 - Planned Release, Low Risk
  • Risk Level 5 - Unplanned / Urgent, High Risk

Adoption

7.1. Immediate adoption

Upon standardization of the TRM, the following two criteria will determine mandatory adoption:

  • The activation of a new ITSM process by an OPS stakeholder or jurisdiction.
  • The activation of any new vendors in the OPS service chain or re-negotiations (where applicable) with existing vendors.

Exceptions to these criteria shall be escalated to the sponsor of the Process Standards Subcommittee for initial review. Following this review, any further escalation will be carried out through the ITSM Leadership Forum.

7.2. Long-term adoption

Existing process implementations that do not comply with the TRM are strongly encouraged to plan for the adoption of the TRM standard, including considerations such as communications, training, and timelines.

While there is no specific timeframe for adoption, it is anticipated that as ITSM initiatives (e.g., Enterprise Service Management, horizontal service delivery initiatives, etc.) evolve, non-compliance with the TRM will have a tendency to isolate those partners and their customers from progress made toward optimized IT service management, service delivery, communications, and business intelligence reporting. This will result in added costs for OPS stakeholders arising from the need to transform or manipulate data and information in order to manage service delivery to and communications with customers.

The requirement for any transformation of information will be the responsibility of the service chain partners themselves. That is, if a partner chooses not to comply but must integrate (electronically or otherwise) with the service chain in order to support or deliver IT services, then that partner will need to communicate using the TRM terminology standards. They will need to transform their internal terminology to the TRM for both inbound and outbound communication activities.

7.3. Service supply chain and the TRM

The TRM provides the minimum, mandatory terminology requirements for ITSM processes, at the corporate level. Should a service chain partner require additional detail, then localization may expand on the TRM within the frameworks set out for each process's terminology models.

7.3.1. States

For transaction states, the content below will be most relevant to external service suppliers and vendors. Internal service providers, in the context of enterprise ITSM processes, have the benefit of using a single, central ITSM enabling toolset with state values, related terminology, and change control that is subject to approved governance processes.

For external service suppliers and vendors, the localization process should ensure that additional local status codes roll-up to a TRM standard state. The following table demonstrates how localized status codes can be rolled up:

Localized status codesTRM change states
LoggedDraft
RequestedRequest for Change
AcceptedPlanning in Progress
AssessedScheduled for Approval
ApprovedScheduled
ScheduledImplementation in Progress
CompletedCompleted
PausedPending
Closed
  • Rejected
  • Closed
  • Cancelled

In this example, local status code Closed would be mapped to the Rejected, Closed, and Cancelled TRM state/status codes given there are no equivalent status codes available to the vendor. Where naming conventions differ, the service chain partner should align definitions with the TRM standard as outlined in relevant process sub-sections within sections 5.5, 5.6, and 5.7, or transform this information when communicating with other service chain partners.

The fact that status or state codes may not be named in exactly the same manner as the TRM states is not a significant issue. This form of transformation is generally straightforward and often treated during a vendor engagement, for example, while building cross-platform connectivity ("Bridge") for ITSM toolsets. The central importance of aligning status or state code names is to allow manual operational activity (e.g., phone calls for high impact and urgency incidents) to be consistent without the need to train support staff on the subtle differences in what status codes map to what states.

State transition models, as outlined in the relevant process State Models, are to be adopted in order to achieve the benefits outlined in Section 5.1.1 About Process States Models, page 29.

7.3.2. Classifications

Classifications in use across a service supply chain should enable an exchange of key information that generates meaningful management information. The means by which this is accomplished must be agreed, documented, and subject to change control.

The TRM establishes the minimum set of information elements at the corporate level for the OPS. Providing these standards as a starting point for integration with contracted external service suppliers ensures transparency regarding the expectations and requirements for partnering with OPS I&IT .

The goal in the exchange of information between OPS I&IT and external service suppliers is to allow or enable effective measurement and management of performance against contractual obligations.

If an external service supplier cannot reasonably adopt the information elements in the TRM, an agreed and documented means of translating, transforming, or mapping TRM classification elements to service supplier classifications must be put in place.

In anticipation of updates to the TRM and ITSM process standards (for example, as discussed in Appendix A), it is highly recommended that flexibility and the ability to update classification values be clearly articulated in agreements with potential partners in the service supply chain. This flexibility allows OPS I&IT to meet the evolving needs for business intelligence and management information over the span of contracts and agreements.

Appendix A: Future opportunities

"Appendix A: Future Opportunities" is intended to explore opportunities for the evolution of certain elements of terminology within a number of process areas. The objectives of this Appendix are:

  1. Promote discussions around the opportunities that exist to enhance the value of data generated through process execution
  2. Provide a starting point for discussions that is based on research and a sample of common strategies for classification frameworks
  3. Identify information elements that may offer an effective and practical approach to addressing challenges in certain aspects of maturing IT service management
  4. Provide transparency with regard to potential future directions and changes in ITSM terminology for the benefit of external service suppliers and internal service providers

8.1. Opportunities for classifications

Significant opportunities exist to extend the classifications available for Incident, Problem, Change, and Release Management. By way of example, the vast majority of incident records use only Tier 1 of Operational Categorization. Those Tier 1 categorization values today offer essentially redundant meaning in the context of Incident Type and Criticality classifications (for a more detailed discussion please see "Incident Management Classification", below). In the case of Change and Release Management, Operational Categorization - introduced to these processes as part of the transition to eSMT - is by and large unstructured and currently of little use or value.

The current classifications of these process records produce limited management information. This in turn hinders the ability to undertake detailed analyzes of technical, operational, process, and procedural data and achieve the various benefits outlined in sub-section 5.2.1 "Classification Model" starting on page 32.

In the sub-sections that follow, a brief review of the current classification schemata and values is undertaken. A discussion of potential future directions for record classifications is put forth with the intention of promoting discussions that will produce consensus on schemata that can be implemented within a reasonable timeframe.

A number of general principles have been kept in mind for the creation of classification schemata and the values, in addition process-specific principles based on best practice guidance from ITIL documentation. The general principles are provided below.

General principles for record classificationfootnote 4

  1. Schema should be business, not IT driven.
  2. Make record capture easy without compromising measurement and analytical activities (e.g., trend analysis for Problem Management and Continual Service Improvement, for reporting and benchmarking on operations, service performance, technical component impacts to service delivery, etc.).
  3. Schema should facilitate refining incident workflows and shortening the transaction lifecycle given a variety of user experience scenarios.
  4. Schema should aim to classify facts and not symptoms.
  5. An overly complex schema or too numerous classification values impede speed of capture and encourage mis-categorization (for instance, increasing reliance on "Miscellaneous", "Other", or "Unknown" by agents)
  6. Values at Tier 1 should be as few as possible (about ten or fewer is often thought to be optimal)
  7. Schema and management of the values should minimize the use of catch-all categories such as "Miscellaneous", "Other", or "Unknown"
    1. Consider the possibility of provide only be one route to a catch-all to avoid an agent working through three tiers of classification only to log an incident as "Unknown".
  8. Avoid redundant or ambiguous values so that each value stands as a distinct entity of meaning.
  9. Ad hoc Incident categories should not be permitted but a mechanism for proposing and review new values should be provided.
  10. Resolution Categorization (where available, as with Incident Management) should be considered as part of the context for Ops Cats and these should be considered to work together when needed.
  11. Schemata and values should avoid reflecting internal politics, individual opinions, and resistance to undertake change and should focus on delivering value to service providers and service customers

The application of these principles alongside process-specific best practices is outlined for Incident, Problem, Change, and Release Management in the sections below.

8.1.1. Incident management classification

This review and discussion will focus on the current values in place for Operational Categorization for Incident Management records and the opportunities that exist to implement new values.

As alluded to above, most incident records use only Tier 1 of Operational Categorization. In the context of Incident Type and Criticality classifications, the Tier 1 categorization values in use today do not build on those elements to further detail and clarify the incident record.

For instance, consider the following incident record classification:

Data elementData value
Incident type:User Service Restoration
Criticality (Priority):1
Operational categorization:Service Interruption - Unavailable

What does this classification of the incident record inform us regarding the specific user's experience and his/her request of IT? Using the definitions set forth in the Incident Management Classification Model, the following detail regarding the incident can be derived:

Data elementData value
Incident type:User reports a service is interrupted and is not functioning, or some aspect of the service is not functioning
Criticality (Priority):A failure of an IT Business Service affecting multiple organizations and a formal SLA is in place that specifies an IT restoration of service time of < or = to 4.5 hours
Operational categorization:A Service is interrupted and is unavailable for normal use.

We can see that the Operational Categorization adds little new information to the record regarding the customer's experience. We know already from the Incident Type that service restoration and from the Criticality 1 definitions (Impact and Urgency) that a service has failed and is unavailable for normal use. The Operational Categorization value that would be used in this scenario, "Service Interruption - Unavailable" adds little. Operational Categorization Tiers 1 and 2 are seldom used at present, nor are Operational Product Categorization, Resolution Categorization, or Resolution Product Categorization.

The outline that follows puts forth one possible approach to Incident Management classification with the general principles listed above and the best practices put forth in ITIL Incident Management documentation. The outline is focused on Operational Categorization within the full context of the available informational elements on the incident record.

The aim of this outline is to promote discussion among stakeholders that is focused on building a useful, workable, and meaningful schema for Incident Management classification.

Future opportunities for incident classification

The process objective for Incident Logging and Categorization activities is summarizedfootnote 5 as follows:

"To record and prioritize the Incident with appropriate diligence, in order to facilitate a swift and effective resolution."

The central purpose of this activity is described in ITIL v3 Service Operation Book, pp. 91, as follows:

"All relevant information relating to the nature of the incident must be logged so that a full historical record is maintained - and so that if the incident has to be referred to other support group(s), they will have all relevant information to [sic] hand to assist them."

The information on the incident record helps Tier 2 - 'N':

  • Avoid duplication of work
  • Avoid asking same questions of the client
  • Carry out fast and efficient analysis/diagnosis of the incident
  • To speak knowledgably with client

The process objective for Incident Closure and Evaluation activities are summarizedfootnote 5 as follows:

"To submit the Incident Record to a final quality control before it is closed. The aim is to make sure that the Incident is actually resolved and that all information required to describe the Incident's life-cycle is supplied in sufficient detail. In addition to this, findings from the resolution of the Incident are to be recorded for future use."

ITIL guidance for Incident Closure and Evaluation makes it clear that a full historical record of the incident must be maintained and that closure categorization be separate from the initial categorization, "…so as not to corrupt the original categorization."footnote 6

The importance of maintaining the original incident categorization is based on the need to reflect the customer's perspective and experience on the incident record, along with IT's perspective. Thus, the incident record provides the ability to reflect both customer and IT experience for each incident. In the context of the broader elements of incident classification such as impacted service, Prioritization, Incident Type, and Reported Source (see Figure 5 Service, Priority, Type, and Source Incident Classification, below), Operational Categorization and Resolution Categorization offer the ability to capture the full customer experience as well as the IT experience, respectively.

Service, Priority, Type, and Source Incident Classification

Figure 4 Service, Priority, Type, and Source Incident Classification

Accessible description of figure 4

Figure 4 is a screenshot of an Incident ticket from eSMT. The screenshot can be described as follows:

Service+: Key Business Process
CI+: OND4C01057758
Target Date: Field is blank
Impact: 4-Minor/Localized
Urgency: 4-Low
Priority: Low
Incident Type: User Service Restoration
Reported Source: Phone

Client and IT points of view captured on the Incident Record

Figure 5 Client and IT points of view captured on the Incident Record

Accessible description of figure 5

Figure 5 is a screen capture of part of a blank Incident ticket from eSMT, split into two points-of-view: On the left is a Client point-of-view and on the right is an IT point-of-view.

The Client point-of-view on the left shows two sections: At the top is the 'Operational Categorization' section and below it is the 'Product Categorization' section. The 'Operational Categorization' section includes Tier 1, Tier 2, and Tier 3 drop lists for selecting categorization values (all blank in the image). This section has a call-out labelled "What I want/need".

The 'Product Categorization' section includes Tier 1, Tier 2, and Tier 3 drop lists for selecting categorization values (all blank in the image), plus drop lists for the Product Name, the Model/Version, and the Manufacturer. This section has a call-out labelled "Where I need it".

The IT point-of-view on the right shows two sections: At the top is the 'Resolution Categorization' section and below it is the 'Resolution Product Categorization' section. The 'Resolution Categorization' section includes Tier 1, Tier 2, and Tier 3 drop lists for selecting categorization values (all blank in the image). This section has a call-out labelled "What I did".

The 'Resolution Product Categorization' section includes Tier 1, Tier 2, and Tier 3 drop lists for selecting categorization values (all blank in the image), plus drop lists for the Product Name, the Model/Version, and the Manufacturer. This section has a call-out labelled "Where I did it".

Focusing in on Operational Categorization as the information that reflects the customer's experience, in addition to the impacted Service, we are left with creating a set of values that adequately and manageably provide meaningful and useful information about that experience.

Numerous approaches exist to developing Operational Categorization values, of course. In this discussion, one such compelling example is described. The approach involves using an action word for Tier 1 as a means of reflecting what the customer is requesting be done. Tier 1 action is then followed by the subjects of the action in Tiers 2 and 3. The distinction between Tier 2 and Tier 3 is based on narrowing specificity. Table 8 below summarizes the scheme:

Table 8 Scheme for Categorization Tiers 1, 2, and 3

Tier 1Tier 2Tier 3
VerbNounNoun
are used to describeare used to describeare used to describe
ActionScopeAspect

The scheme can be considered a reflection of a simple statement made by a customer: "I [the user] need you [support] to < Tier 2>'s < Tier 3>." For instance, a user may call the Service Desk about an issue he's experiencing with the browser application on his laptop. Based on discussion and diagnosis with the Service Desk, the categorization may produce a simplified statement like, "I need IT to < Restore> < Software>'s < Settings>"

For even greater specificity, the Operational Product Categorization helps to identify the specific software from the CMDB, as in: < Application> < Software> < Desktop> < Firefox>. These classification elements are shown together below, in Figure 6 Operational and Product Categorization Working Together.

Operational and Product Categorization Working Together

Figure 6 Operational and Product Categorization Working Together

Accessible description of figure 6

Figure 6 is a screenshot of an Incident ticket from eSMT of two sections: Operational Categorization and Product Categorization. The screenshot can be described as follows:

Operational categorization:

  • Tier 1+: Restore
  • Tier 2: Software
  • Tier 3: Settings
  • Product Categorization:
  • Tier 1: Application
  • Tier 2: Software
  • Tier 3: Desktop
  • Product Name+: Firefox
  • Model/Version: Field is blank
  • Manufacturer: MOZILLA

The other side of the customer's point of view, of course, is IT's point of view. Continuing with the Firefox example, above, let's imagine that the incident has had to be escalated to a field services support team to confirm the initial request/diagnosis and perform the Restore action. Upon investigation, the field services agent realizes that the issue the customer reported was one she'd already seen just that morning. She knows that, in fact, the specific browser application issue being reported was likely due to an OS service that had stopped running.

The field services agent reboots the customer's laptop and ensures that all OS services are running as expected. The customer's issue is, indeed, resolved. The field services agent then resolves the incident with the following categorization, using Resolution categorization so that the original Operational Categorization remains intact:

Resolution categorization differing from operational categorization

Figure 7 Resolution categorization differing from operational categorization

Accessible description of figure 7

Figure 7 is a screenshot of an Incident ticket from eSMT of two sections: Resolution Categorization and Resolution Product Categorization. The screenshot can be described as follows:

Resolution categorization:

  • Tier 1: Restart/Reboot
  • Tier 2: OS Services
  • Tier 3: Field is blank
  • Resolution Product Categorization:
  • Tier 1: Support Software
  • Tier 2: Operating System
  • Tier 3: PC
  • Product Name (R)+: Microsoft Windows Professional Edition
  • Model/Version (R): 7.0
  • Manufacturer (R): MICROSOFT

The resulting Incident Record provides a full historical record of the transaction, in keeping with best practices. With the full context of classification of Incident Records, along with associated information, a complete story of the incident can be gleaned, summarized hypothetically in Table 9 The Full Historical Record of the Incident, below.

Table 9 The full historical record of the incident

ViewpointSummary of the transaction
Customer experience< Lester Pearson> < Called> needing < Service Restoration>. The customer was using/doing < Personal Computing Services>, and indicated he needed IT to < Restore> his < Software>'s < Settings>, specifically in relation to < Application> | < Software> | < Desktop> | < Firefox>. IT was to complete this work within <3 business days> [SLT in SLA].
IT ExperienceIT followed procedure and the incident was deemed to be a < Priority 3>. The supporting < Field Services> agent responded to the < Priority 3> incident within the agreed response time of < 1 business day> [SLT in OLA]. Field Services carried out a < Restart/Reboot> to address < OS Services>, specifically due to an issue with < Support Software> | < Operating System> | < PC> | < Microsoft Windows Professional Edition 64-bit>. IT was to complete this work within <3 business days>. IT resolved this incident in <1.75 business days> [SLT Elapsed Time] and < Met> the agreed <3 business days> commitment [SLA].

Using the Action | Scope | Aspect theme, a set of values for Operational Categorization of User Service Restoration incident type might look like this:

Tier 1Tier 2Tier 3
VerbNounNoun
are used to describeare used to describeare used to describe
ActionScopeAspect
  • Restore
  • Repair
  • Replace
  • Update
  • Inform/Help
  • Move
  • Delete/Cancel
  • Add/Enable
  • Block/Secure
  • Escalate
  • Other
  • Function
  • Access
  • Error
  • Service
  • Computer
  • Peripheral
  • Software
  • Feature
  • Navigation
  • Usability
  • Operation
  • Performance
  • Interface
  • Format
  • Defaults
  • Settings
  • Data
  • Permissions
  • Process
  • Procedure
  • Design

Some examples of IM Operational Categorizations:

Tier 1Tier 2Tier 3
VerbNounNoun
are used to describeare used to describeare used to describe
ActionScopeAspect
RestoreServiceOperation
RestoreServiceNavigation
RepairComputerPerformance
UpdateSoftwareSettings

8.1.2. Change and release management classification

An Operational Categorization element was added to the Change Management and Release Management enabling tool as part of the transition to the Enterprise Service Management Tool (eSMT). An agreed definition and set of operational categorization values has yet to be arrived at. The following discussion aims to promote discussion among stakeholders regarding the value and uses of Operational Categorization for these two processes, which share a common set of Operational Categorization values.

Since Change Management requests, in a broad sense, relate more to enterprise level assets and resources compared to user-level assets and resources dealt with through Service Request Fulfillment, Operational Categorization provides meaningful information when the values reflect the classification structure in the CMDB.

Moreover, Operational Categorization of a change record that relates to the root causes of problems in the environment help fill the gap in information regarding the drivers of changes. If a server needs to be re-booted as part of the resolution of a user service interruption, such an activity is recorded in an incident record. The activity needed to address the reasons why a service had to be re-booted is recorded in the change record.

For Release Management, as well, categories relate more to enterprise level assets and resources manage via SACM process elements and represented in the CMDB. The perspective from Release is more project-oriented but with clear interactions with Change Management.

Thus, with these considerations in mind, a set of values for Operational Categorization may look something like the following:

Tier 1Tier 2Tier 3
VerbNounNoun
are used to describeare used to describeare used to describe
ActionScopeAspect
  • Add/Create
  • Fix/Repair
  • Replace
  • Update/Renew
  • Move/Transfer/Migrate
  • Remove/Delete
  • Modify/Redo
  • Restart/Reboot
  • Install
  • Other
  • Physical CI
  • Logical CI
  • Functionality
  • Access
  • Service
  • Hardware
  • Peripheral
  • Software
  • Documentation
  • Server
  • Server peripheral
  • Storage
  • Storage appliance
  • Network
  • Security
  • Service
  • Service offering
  • Application software
  • Application solution
  • Support software
  • View
  • Report
  • Policy
  • Standard
  • Facility
  • Attribute
  • Configuration
  • Version

Some examples of CM and RM Operational Categorizations:

Tier 1Tier 2Tier 3
VerbNounNoun
are used to describeare used to describeare used to describe
ActionScopeAspect
Add/CreateServiceService offering
ReplaceHardwareNetwork
Update/RenewSoftwareVersion
Move/TransferHardwareServer

Taken in the full context of Change Management classification and relationships, in which the impacted IT Business Service(s) is (are) identified and the CI subject to the change, Operational Categorization reveals its value. For instance, consider a Change Record showing only the following:

Data elementData value
Service:Key Ministry Process 1
Class:Emergency
Risk level:4
Product categorization:
  • Tier 1: Solution
  • Tier 2: Application Solution
  • Tier 3: Business Critical
  • Tier 4: Process 1 Enabling Solution
  • Model/Version: 1.15

There is considerable information here. However, a driver or business goal for the change isn't evident without reference to a field such as Notes. Reporting in the aggregate to identify, say, IT activities carried out to update a service's solution software is considerably more difficult and likely to be less accurate if only Notes are available. Add Operational Categorization to the information available on the change record and the value of the change record in generating usable data becomes clearer:

Data elementData value
Service:Key Ministry Process 1
Class:Emergency
Risk level:4
Operational categorization:
  • Tier 1: Update/Renew
  • Tier 2: Software
  • Tier 3: Version
Product categorization:
  • Tier 1: Solution
  • Tier 2: Application Solution
  • Tier 3: Business Critical
  • Tier 4: Process 1 Enabling Application
  • Model/Version: 1.15

An effective schema for Operational Categorization that follows the principles put forth at the beginning of this appendix (see "General Principles for Record Classification", above) provides key informational elements that allow pattern detection, operational analyses, performance measurement and reporting, trend observations, insights into process interactions, Continual Service Improvement, and so on.

8.1.3. Service asset and configuration management

Criticality classifications

As outlined in section, 5.3.1 SACM Product Category Classification Model, five Tier 3 values are in place for the categorization of IT solution criticality. These five values are:

  1. Business Support
  2. Business Critical
  3. Mission Critical
  4. Personal Productivity
  5. Workgroup Support

These categorization values were adopted following recommendations set forth in the run up to the Year 2000 (Y2K) risk remediation initiatives put in place for the OPS.

These categorizations have since been broadly, though not commonly and consistently, adopted across OPS I&IT jurisdictions in relation to their application solutions. The opportunity to review the use, definitions, and application of these criticality classifications is both timely and highly relevant to the maturation of OPS ITSM processes.

As I&IT moves toward greater horizontal integration in service delivery as well as toward a greater Business Service Management orientation, a review of the potential benefits of applying criticality classifications to IT Business Services should be undertaken. Such a review should consider whether criticality classifications of IT Business Services should be exclusive, should be in addition to classification of solutions, should include Technical Services, or should remain exclusive to solutions.

To promote discussion, a brief outline of some the points to consider, the current challenges, and the potential benefits of changing the current approach are provided below.

  • The IT Business Service represents the customer view of the full value of IT, whereas a solution represents only a portion of the value
  • The impacts of a service incident on business will be more readily identifiable through the service model that is built around IT Business Service than through individual solutions
  • A single IT Business Service may be enabled/supported by more than one solution, but only one of those solutions may be classified as Mission Critical while the other may be Business Support; this can lead to disagreement and confusion in prioritizing incidents
  • Clarifying the type relationship of each supporting technical service, solution, system, and so on to IT Business Services offers a more nuanced view of service impacts and the required support and service levels
  • A review of the current approach is required to establish clear expectations for support hours of operation for solutions; this is more readily achievable by leveraging the IT Business Service support requirements and service level agreements rather than a single criticality categorization of a solution
  • The model and service agreement for an IT Business Service provides a more accurate and nuanced reflection of the business requirements and expectations for that service
  • Alignment of an IT Business Service to the ministry programs and services that are deemed mission critical allows more direct identification of ministry impacts and more meaningful performance reporting against service level agreements
  • Service CI's include a five-level Priority attribute driven by Impact and Urgency; these classification elements offer a potential means for aligning or defining criticality classification in association with the criticality classification of solutions

A review and consideration of the opportunities presented by the ITSM enabling toolset for extending the relationship of solutions and their criticality classifications to services is both timely and highly relevant in the maturation of OPS ITSM processes.

Use of impact, urgency, priority

All Configuration Items in the CMDB provided via the ITSM enabling toolset (eSMT) offer a five-level Priority attribute driven by Impact and Urgency, as noted above in relation to Service CI's. These classification elements represent an opportunity to more closely align priority ratings across processes with the services, assets, and resources represented in the CMDB and managed through process execution. Such priority classifications may provide a more nuanced and thorough scheme comparing to the tiered categorization of solution criticality described in section 5.3.1 (see sub-section "Product Categorization for Solution CI's").

The relationships among services and the solutions, applications, and various infrastructure elements that enable those services may be better reflected in a coherent application of Priority, Impact, and Urgency across the CI's. Automated discovery, data reconciliation, service impact assessments, and SACM asset data reporting would potentially be provided an effective and more complete view of dependencies, relationships, and exceptions through the use of these classification elements.

An exploration of the opportunities offered by the Priority scheme in the CMDB is recommended for future terminology reference models.

Service configuration items

Service Configuration Items (Service CI's) are an important new base element in the CMDB introduced with the new ITSM toolset launched in 2015. There is opportunity to establish the definitions and intended uses, the acceptable values, the policies, and the standards for the various attributes and relationships available for Service CI's within the larger SACM model.

The appropriate standard in which to document the Service CI element will need to be determined as part of any such work that is undertaken.

8.1.4. Service request fulfillment

Like the Change and Release Management processes, the Service Request Fulfillment process manages what often amount to changes to the I&IT environment but for individual users.

The Request Fulfillment process in the OPS I&IT now has available an enablement tool in eSMT's Service Request Management module. As the advanced functions and features of this module are leveraged to manage the very high volumes of IT services requests, important opportunities exist to establish and manage an effective classification framework for the three tiers Operational Categorization for process definitions.

The process definition function that is part of the Service Request Management module allows for mapping Operational Category values from one process phase to another based on event triggers. For instance, if a request process starts as a generic request for a single user but the Quantity input from the order form on the orderable service catalogue triggers an exception process workflow, the operational categorization can be dynamically set in response. This provides Service Level Management the ability to ensure the correct service level target is attached to the request. It also provides the service order management function with the ability to understand demand trends and capacity requirements, for instance.

With these considerations in mind, a set of values for Operational Categorization may look something like the following:

Tier 1Tier 2Tier 3
VerbNounNoun
are used to describeare used to describeare used to describe
ActionScopeAspect
  • Add/Create
  • Replace
  • Update/Renew
  • Move/Transfer/Migrate
  • Remove/Cancel/Delete
  • Modify/Change
  • Install
  • Other
  • Account
  • Access
  • Single User
  • Multiple Users
  • Data/Information
  • Documentation
  • Personal Computer
  • Server
  • Service
  • Physical CI
  • Logical CI
  • Software
  • Hardware
  • Peripheral
  • Storage
  • Storage appliance
  • Network
  • Security
  • Patch
  • Service offering
  • Service feature
  • Application software
  • Application Solution
  • Support software
  • View
  • Report
  • Policy
  • Standard
  • Facility
  • Attribute
  • Configuration
  • Location/Site
  • Subscription

Some examples of Request Fulfillment Operational Categorizations:

Tier 1Tier 2Tier 3
VerbNounNoun
are used to describeare used to describeare used to describe
ActionScopeAspect
Add/CreateAccountApplication
Update/RenewData/InformationPhysical CI
Move/Transfer/MigrateMultiple UsersLocation/Site
Move/TransferPersonal ComputerHardware

Appendix B: Glossary

9.1. Glossary of common terms

TermDescription
AssetAny Resource or Capability used by a Service Provider to contribute to the delivery of a Service. (See Service Asset.)
Asset managementAsset Management is the process responsible for tracking and reporting the value and ownership of financial Assets throughout their Lifecycle. Asset Management is part of an overall eSACM process.
AssignmentAssignment occurs when an incident is assigned by the ITSD to a Tier 2-N support group within the OPS to attempt incident resolution. The assigned support group must respond in accordance with the OPS Incident Management process/procedures and their actions may be directed by the OPS Incident Manager. (see Dispatch)
AttributeA piece of information about a Configuration Item. Examples are: name, location, Version number, and Cost. Attributes of CIs are recorded in the CMDB.
BaselineIs a benchmark used as a reference point and can be used to enable the IT Infrastructure to be restored to a known Configuration if a Change or Release fails.
CapabilityCapabilities are intangible Assets of an Organization. Capabilities are used by an organization to coordinate, control, and deploy Resources to produce value, i.e. Services. They are typically experience-driven, knowledge-intensive, information-based, and firmly embedded within an organization's people, systems, processes and technologies.
Capability assets include: Management, Organization, Process, Knowledge, People
ChangeFrom an eCM scope perspective, a Change is a modification to a CI in the Production environment including:
  • HW/SW components,
  • Services and service components,
  • Production support documentation (e.g., Service Desk knowledge records, operations procedures)
  • eSACM data relating to any of the above.

A change is required to modify any of the following CI attributes:

  • Capacity
  • Functionality
  • Scope
  • Availability
  • Data
Change request (CRQ)The physical record of the change in the change management system. A CRQ will transition through various states throughout its lifecycle.
CI type/classA Category that is used to Classify CIs. The CI Type identifies the required Attributes and Relationships for a CI. Common CI Types include: Hardware, Software, Document, People, etc.
ComponentA general term that is used to mean one part of something more complex. For example, a computer System may be a component of an IT Service; an Application may be a Component of a Release Unit. Components that need to be managed should be CIs.
Configuration item (CI)A Configuration Item (CI) represents any component that needs to be managed in order to deliver an IT Service and is stored within the CMDB. A CI is maintained throughout its Lifecycle by eSACM. CIs typically include IT Services, hardware, software, buildings, people, and formal documentation such as process documentation and SLAs.
Configuration management database (CMDB)A database used to store CIs throughout their Lifecycle. The ITSM Tool maintains one or more CMDBs, and each CMDB stores attributes of CIs, and Relationships with other CIs.
CustomerSomeone who buys goods or services. The customer of an IT Service Provider is the person or group that defines and agrees the Service Level Targets. The term customer is also sometimes informally used to mean users, e.g., "this is a customer-focused organization".
Data modelDefine how the classes and types of assets and configuration items are to be selected, grouped, classified and defined by appropriate characteristics,
Diagnostic scriptsDocuments used by the Service Desk to help classify and resolve incidents. These documents, based upon input from specialist support groups and suppliers, identify key questions to be asked to obtain details about what has gone wrong, with suggestions for resolution activities to be performed.
DispatchDispatch occurs when the ITSD assigns an incident to a Service Provider outside the OPS to attempt resolution. Provider behaviour is specified by an Underpinning Contract and the OPS Incident Manager does not have authority to direct the providers' activities other than coordination of activities between the provider and other OPS support groups.
Enterprise change management (eCM)The Enterprise Change Management process. OPS GO-IT Standard 35.
Enterprise incident management (eIM)The process responsible for managing the Lifecycle of all Incidents. The primary objective of Incident Management is to return the IT Service to Customers as quickly as possible. OPS GO-IT Standard 37.
Error(Service Operation) A design flaw or malfunction that causes a failure of one or more Configuration Items or IT services. A mistake made by a person or a faulty process that affects a CI or IT service is also an error.
EscalationAn activity that obtains additional resources when these are needed to meet Service Level Targets or customer expectations. Escalation may be needed within any IT Service Management process, but is most commonly associated with Incident Management, Problem Management and the management of customer complaints. There are two types of escalation: Functional Escalation and Hierarchical Escalation.
External service providerAn IT Service Provider that is part of a different organization from its customer. An IT Service Provider may have both internal customers and external customers.
FederationIs the concept where the definitive CMDB acquires data or subsets of data from multiple, trusted sources to provide a view of the relationships across components.
Financial managementThe function and process responsible for managing an IT Service Provider's Budgeting, Accounting and Charging Requirements. Financial Management IS NOT part of the eSACM process.
Functional escalationTransferring an incident, problem or change to a technical team with a higher level of expertise to assist in an escalation.
Hierarchical escalationInforming or involving more senior levels of management to assist in an escalation.
ImpactA measure of the effect of an incident, problem or change on business processes. Impact is often based on how Service Levels will be affected. Impact and urgency are used to assign priority.
Implementation dateDate when change will be implemented. There are several 'views' of this date during the lifecycle of a change:

Requested date refers to the implementation date identified on the original CRQ submission.

Scheduled date refers to the date that the change is being assessed for implementation for - this date may change through the lifecycle of the change, however once the change is approved, the scheduled date represents the change window under which the change activities can take place.

Actual date refers to date on which the CRQ was implemented. This may vary from the "Scheduled" date, based on when the actual implementation work was completed, however, it should align with the Scheduled date.

IncidentAn unplanned interruption to an IT service or reduction in the quality of an IT service. Failure of a Configuration Item that has not yet affected service is also an incident. For example, failure of one disk from a mirror set.
Incident patternA pattern exists for each high level business service to define how the ITSD interacts with OPS service chain partners such as clusters, ministries and corporate providers to resolve reported incidents.
Incident recordA record containing the details of an incident. Each incident record documents the lifecycle of a single incident.
Information technology service management tool (ITSM Tool)A set of tools and databases that are used to manage an IT Service Provider's Asset and Configuration data. The ITSM Tool also includes information about Incidents, Problems, Known Errors, Changes and Releases; and may contain data about employees, Suppliers, locations, Business Units, Customers and Users. The ITSM Tool includes tools for collecting, storing, managing, updating, and presenting data about all Configuration Items, their Relationships and possible Asset information. The ITSM Tool data is maintained by the eSACM process and is used by all IT Service Management processes.
Internal service providerAn IT Service Provider that is part of the same organization as its customer. An IT Service Provider may have both internal customers and external customers.
Ishikawa diagramA technique that helps a team to identify all the possible causes of a problem. Originally devised by Kaoru Ishikawa, the output of this technique is a diagram that looks like a fishbone.
IT serviceAn exchange of value between two entities in order to achieve specific outcomes.

For Service Level Management and Service Catalogue Management in the OPS, an IT Service is considered to fall into one of two broad types:

  1. IT Business Service: A logical entity that represents the customer-valued outcomes offered/delivered by IT in direct support of a ministry process, program, service, or line of business.
  2. IT Technical Service: A logical entity that represents the supporting technical capabilities offered and/or delivered by IT and valued by IT service and solution provider
IVBRefers to the Installation, Verification and Backout instructions contained in the Implementation Plan.
KE recordA record containing the details of a Known Error. Each Known Error record documents the lifecycle of a Known Error, including the status, Root Cause and workaround. In some implementations a Known Error is documented using additional fields in a problem record.
Kepner & tregoe analysisA structured approach to problem solving. The problem is analysed in terms of what, where, when and extent. Possible causes are identified. The most probable cause is tested. The true cause is verified.
Known error (KE)A problem that has a documented Root Cause and a workaround. Known Errors are created and managed throughout their lifecycle by Problem Management. Known Errors may also be identified by developers or suppliers.
Known error databaseA database containing all Known Error records. This database is created by Problem Management and used by Incident and Problem Management.
LifecycleThe various stages in the life of an IT Service, Configuration Item, Incident, Problem, Change, etc. The Lifecycle defines the Categories for State and the State transitions that are permitted.
Master service level agreement (MSLA)A Master Service Level Agreement provides an "executive summary-type" view of the service levels and compliance targets offered for IT Business Services (end-to-end services). The Master SLA is an extension of the Business Service Catalogue that provides key information & service levels pertaining to IT services and service relationships.
Operational discoveryThis document specifies the impact of the change being implemented, in terms of when, where and how services and resources are affected.
Operational level agreement (OLA)An agreement between two IT Service Owners within the same organization.

An OLA often describes the levels of service and the responsibilities that are required of a supporting technical service in order to meet the agreed Service Level Targets in a customer-facing Service Level Agreement.

An OLA documents the services to be provided, the responsibilities of both parties to the agreement, and the agreed service levels and compliance targets for a supporting technical service. An IT Business Service and the Service Level Agreement for that service typically depends on a series of OLA's that represent the service delivery chain assembled to deliver service to the ministry end-user or business unit.

Most IT Business Services leverage a standard set of technical services and associated service levels (e.g., application hosting, networking, etc.). A service needing customized specifications and service levels would require an OLA with each supporting technical service of which the non-standard service levels are required.

Proactive problem managementPart of the Problem Management process. The objective of Proactive Problem Management is to identify problems that might otherwise be missed. Proactive Problem Management analyses incident records and uses data collected by other IT Service Management processes to identify trends or significant problems.
ProblemA cause of one or more incidents. The cause is not usually known at the time a problem record is created, and the Problem Management process is responsible for further investigation.
Problem managementThe process responsible for managing the lifecycle of all problems. The primary objectives of Problem Management are to prevent incidents from happening and to minimize the impact of incidents that cannot be prevented.
Problem recordA record containing the details of a problem. Each problem record documents the lifecycle of a single problem.
Process managerA role responsible for operational management of a process. The Process Manager's responsibilities include planning and coordination of all activities required to carry out, monitor and report on the process. There may be several Process Managers for one process; for example regional Change Managers or IT Service Continuity Managers for each data centre.
Process ownerA role responsible for ensuring that a process is fit for purpose. The Process Owner's responsibilities include sponsorship, design, Change Management and continual improvement of the process and its metrics.
Process service level objective (PSLO)A service level objective for a specific process task or metric. For example:
  • Problem resolution will complete within x weeks, based upon problem classification
  • 70% of incidents will be linked to Problems
Recovery time objective (RTO)Specifies the maximum tolerable service outage that can be sustained before consideration must be made to invoke Business Continuity or Disaster Recovery plans.
ReleaseA collection of hardware, software, documentation, processes or other components required to implement one or more approved changes to IT services. The contents of each release are managed, tested, and deployed as a single entity.
Root causeThe underlying or original cause of an incident or problem.
Root causeAnalysis An activity that identifies the Root Cause of an incident or problem.
ServiceSee "IT Service"
Service agreementA document that describes the value of IT in business terms and documents understanding of accountabilities of both business and IT.
Service assetAny resource or capability of a Service Provider used to create value and deliver a Service
Service deskThe Single Point of Contact between the Service Provider and the Users. A typical Service Desk manages Incidents and Service Requests, and also handles communication with the Users.
Service deskThe single point of contact between the Service Provider and the users. A typical Service Desk manages incidents and service requests and also handles communication with the users.
Service failure analysis (SFA)An activity that identifies underlying causes of one or more IT service interruptions. SFA identifies opportunities to improve the IT Service Provider's processes and tools and not just the IT infrastructure. SFA is a time-constrained, project-like activity, rather than an ongoing process of analysis. (See also Root Cause Analysis.)
Service level agreement (SLA)An agreement between an IT Service Provider and a customer.

The SLA describes the IT service, documents service level goals and compliance targets, and specifies the responsibilities of the IT Service Provider and the customer.

A single SLA may cover multiple IT services or multiple customers.

(See also Operational Level Agreement, Underpinning Contract, Master Service Level Agreement)

Service level objective (SLO)In the absence of a formally negotiated SLA, a Service Provider must define performance objectives for delivery and support of the service.
Service level requirement (SLR)A Service Level Requirement (SLR) is a statement from a customer to an IT service provider that describes what that customer needs from the IT service provider. This statement focuses on the service utility and warranty. A service provider prepares a service level agreement (SLA) based on the requirements from the customer.
Service management lifecycleAn approach to IT Service Management that emphasizes the importance of coordination and control across the various Functions, Processes, and Systems necessary to manage the full Lifecycle of IT Services. The Service Management Lifecycle approach considers the Strategy, Design, Transition, Operation and Continual Improvement of IT Services.
Service managerA manager who is responsible for managing the end-to-end lifecycle of one or more IT services.
Service offeringA statement of the utility and the warranty delivered as part of a service which a consumer of that service values and for which she is willing to pay.

A service offering usually specifies a level of service delivery at a specific cost. Aspects of a service offering that can be ordered or requested are referred to as orderable offerings, "requestable" offerings, or actionable offerings.

Service ownerMember of a Service Provider organization, accountable for delivery of a specific service and accountable to maintain accurate information for all CIs involved in delivery of his service.
Service providerAn organization supplying Services to one or more Internal Customers or External Customers.

Service Provider is often used as an abbreviation for IT Service Provider.

Where there are several Service Providers that enable an overarching service, they are sometimes called Supply Chain (or Service Chain) Partners

Support modelContains information required to support a specific service, including identification of support resources, classification elements, escalation contacts and service restoration targets. (This document contains some elements of what ITIL calls the Service Operations Plan.)
Support serviceInternal services that support a 'consumable' service. Support Services are typically not visible to end-users. Relationships and obligations between Service Support Owners and their customer (Service Owners) are documented in OLA's and UC's. (see Service)
Trend analysisAnalysis of data to identify time-related patterns. Trend Analysis is used in Problem Management to identify common failures or fragile Configuration Items and in Capacity Management as a modelling tool to predict future behaviour. It is also used as a management tool for identifying deficiencies in IT Service Management processes.
Underpinning contract (UC)An agreement with an external service supplier/vendor on service specifications and interactions, including the underpinning service levels, compliance targets, processes, and reporting requirements the internal technical service provider depends on to meet his or her respective service level commitments.
UrgencyA measure of how long it will be until an incident, problem or change has a significant impact on the business. For example, a high impact incident may have low urgency if the impact will not affect the business until the end of the financial year. Impact and urgency are used to assign priority.
UserA person who consumes the IT service on a day-to-day basis. Users are distinct from customers, as some customers do not use the IT service directly.
Work orderA request for some type of action to be undertaken, related to an existing Production Service; e.g., Information request, user account: add, delete, modify.

Formal name = Incident - Work Order (with multiple subtypes)

A Work Order has the following characteristics:

  • No impact to existing service (capacity, scope, functionality, availability)
  • Repeatable
  • Procedure based
  • An SLA exists to defines entitlement and response target

Note: A Work Order may have originally been a Standard Change, which, after being processed under the eCM process, was subsequently approved for processing as a Work Order.

 

WorkaroundReducing or eliminating the impact of an incident or problem for which a full resolution is not yet available. For example, by restarting a failed Configuration Item. Workarounds for problems are documented in Known Error records. Workarounds for incidents that do not have associated problem records are documented in the incident record.

9.2. Process priority matrices

9.2.1. Incident management

The following table provides the framework for classifying the urgency and impact of incidents, which are then used to establish incident priority. Urgency and impact were originally defined in GO-ITS 44, Terminology Reference Model, to ensure that local process implementations used common terminology.

ITSM has matured across the OPS and enterprise processes are now in place for Incident, Problem and Change Management. The definitions have been updated to reflect best practices.

ClassificationsDefinitionsField valuesCriteria
(At least 1 criterion must be met)
ImpactMeasure of scope and criticality to business. Often equal to the extent to which an incident leads to distortion of agreed or expected service levels.1 - Extensive / Widespread
  • A failure of an IT Business Service affecting multiple organizationsfootnote 7
  • A failure affecting public safety
  • A Security-related incident affecting a large number of users across multiple organizations where total loss or compromise of critical business data may result.
  • A Core network outage or a network outage affecting mission critical government location
  • A failure affecting > 1000 users
  • A failure that affects a money back guarantee public service offering
  • Mission-critical applications fully unavailable
  • Citizen-facing government websites
ImpactMeasure of scope and criticality to business. Often equal to the extent to which an incident leads to distortion of agreed or expected service levels.2-Significant/LargeFailure of an IT Business Service affecting a single organization which may include:
  • A network outage affecting business critical government offices
  • A security related incident affecting large number of users where work may be seriously impeded/interrupted within large groups or some business information may be at risk.
  • A failure or serious degradation affecting >500 users
  • A failure that affects a public-facing "non-guaranteed" service offering
  • Failure of business-critical applications
  • A failure affecting all users in a single organization
ImpactMeasure of scope and criticality to business. Often equal to the extent to which an incident leads to distortion of agreed or expected service levels.3-Moderate/LimitedAll remaining failures of IT Business Services which may include:
  • Single user(s)
  • A small isolated group of users with a common failure (single application, location, a failure on one of several IT Business Services utilized)
  • Security related incident affecting single or small number of users where some business data may be subject to limited compromise.
ImpactMeasure of scope and criticality to business. Often equal to the extent to which an incident leads to distortion of agreed or expected service levels.4-Minor/LocalizedService Requests
UrgencyMeasures how quickly an incident needs to be responded to based on the business needs of the customer.1-Critical
  • A formal SLA is in place that specifies an IT restoration of service time of < or = to 4.5 hours
  • A Security threat exists or a there is potential for severe or substantial impact
  • A failure where formal SLA has been breached or it is known that an SLA will be breached
  • Response required includes an immediate and sustained effort using any/all available resources until the Incident is resolved
  • Executive or VIP Service Interruptions
UrgencyMeasures how quickly an incident needs to be responded to based on the business needs of the customer.2-High
  • SLA/ SLO specifies a restoration of IT service within same business day
  • A security threat exists with potential for moderate impact. Work may be impeded in small groups. There might be some compromise of data and/or lack of availability for a small number of systems.
UrgencyMeasures how quickly an incident needs to be responded to based on the business needs of the customer.3-Medium
  • Single user(s)
  • A small isolated group of users with a common failure (single application, location, a failure on one of several IT Business Services utilized)
  • A security related failure with potential for minimal impact
UrgencyMeasures how quickly an incident needs to be responded to based on the business needs of the customer.4-Low
  • Service Request
PriorityImpact
1-extensive/ widespread
Impact
2-significant/large
Impact
3-moderate/limited
Impact
4-minor/localized
Urgency 1-Critical1233
Urgency 2-High2233
Urgency 3-Medium3333
Urgency 4-Low3334

9.2.2. Change management priority matrix

ClassificationsDefinitionsField valuesCriteria
ImpactThe potential business vulnerability and measure of the effect the Change will have on the enterprise. Impact does not drive any processes and its use will be at the discretion of the Jurisdiction initiating the change.1 - Extensive / WidespreadThere is significant business service impact because multiple customers are affected by the change. Considerable human and technical resources are needed. Management is involved in the decision process.
ImpactThe potential business vulnerability and measure of the effect the Change will have on the enterprise. Impact does not drive any processes and its use will be at the discretion of the Jurisdiction initiating the change.2 - Significant / LargeThere is clear service impact because at least one customer is affected by the change.
ImpactThe potential business vulnerability and measure of the effect the Change will have on the enterprise. Impact does not drive any processes and its use will be at the discretion of the Jurisdiction initiating the change.3 - Moderate / LimitedThere is little impact on current services because no customers are affected as a result of the change.
ImpactThe potential business vulnerability and measure of the effect the Change will have on the enterprise. Impact does not drive any processes and its use will be at the discretion of the Jurisdiction initiating the change.4 - Minor / LocalizedThe change can be executed without prior approval from the Change Manager because no customers are affected by the change.
UrgencyThe evaluation of the business impact of delaying the change. Urgency does not drive any processes and its use will be at the discretion of the Jurisdiction initiating the change.1 - CriticalA full service outage of a critical system. System is non-operational. Urgent response.
UrgencyThe evaluation of the business impact of delaying the change. Urgency does not drive any processes and its use will be at the discretion of the Jurisdiction initiating the change.2 - HighA change that will resolve an issue(s) that disrupts a users' ability to do work or an issue that partially impacts a very important person or process. Quick response.
UrgencyThe evaluation of the business impact of delaying the change. Urgency does not drive any processes and its use will be at the discretion of the Jurisdiction initiating the change.3 - MediumA change that will resolve an issue(s) partially impacts the user's ability to do work or one for which a workaround exists. Assistance is needed. Response as soon as possible.
UrgencyThe evaluation of the business impact of delaying the change. Urgency does not drive any processes and its use will be at the discretion of the Jurisdiction initiating the change.4 - LowA change that will resolve an issue(s) that has no impact on users' ability to do work. Response is not critical.
PriorityDetermines the relative importance of a change.n/aSee the Change Management Priority Matrix table below for details on how Priority is determined based on Impact and Urgency values.
PriorityUrgency
critical
Urgency
high
Urgency
medium
Urgency
low
Impact - Extensive1124
Impact - Significant1234
Impact - Moderate2234
Impact - Minor2334

9.3. SLM agreements model

Legacy ISAM nameeSLM eSAM nameeSMT enablementNotes
Memorandum of understand (MOU)IT service agreementContractStorage in eSMT enables better record keeping and management
Master service level schedule (MSLS)Master service level agreementAgreement type: SLALists SLT's provided commonly by enterprise services across the OPS. "Corporate" agreement (see Appendix B: Types of SLA's).
Customer moduleService level agreementAgreement type: SLAProvides SLT's tailored to an entity such as LOB, program area, ministry (for targeted services or for non-standard offerings). "Client" agreement (see Appendix B: Types of SLA's).
Cluster module
Or
Service provider agreement (SPA)
Operational level agreementAgreement type: OLAIT-to-IT agreement Service Chain enablement
Service offering specificationService design package (ITS transition TBD)Input to Service Catalogue, CMDB, SLM Module, SSMC (KA's)SLM review of SDP required
Catalogue of services (Cluster and Common Provider)Business service catalogue (must encompass orderable/actionable catalogue - S.ODO)

Technical service catalogue (incorporates approvals for OLA commitments)

Atrium core service catalogueCloser alignment and integration across customer-facing online assets is required to achieve customer satisfaction and process maturity

Appendix C: Document dependencies

A change to this Terminology Reference Model standard may require corresponding updates to one or more of the documents listed below. Likewise, a change to one of the documents below where terminology is involved may require a change to the corresponding content in this document.

DocumentContent
GO-ITS #37 - Incident ManagementPriority Matrix
States/Status
Classification
GO-ITS #35 - Enterprise Change Management (eCM)Priority Matrix
States/Status
Classification
GO-ITS #36 - Enterprise Service Asset Configuration Management (eSACM)Classification
CI Attribute definitions
GO-ITS #38 - Problem ManagementPriority Matrix
States/Status
Classification
GO-ITS #55 - Service Desk Enterprise Release ManagementStatus
Classifications
Enterprise Service Level ManagementService definitions
eSAM nomenclature
Performance Measurement model
ITSM Vendor Injection PackageStates/Status
Classifications