GO-ITS 55 Ontario Public Service IT Service Desk Interaction Model and Incident Management Support Patterns
This document is for ministries and agencies that use Ontario Public Service (OPS) information and information technology products or services. It provides service support patterns for the Ontario Public Service IT Service Desk (ITSD).
1 Introduction
Government of Ontario Information Technology Standards (GO-ITS) are the official publications on the IT standards adopted through the Office of the Corporate Chief Information Officer (OCCIO) and IT Executive Leadership Council (ITELC) for use across the government’s information and information technology (I&IT) infrastructure.
These publications support the responsibilities of the Treasury Board Secretariat for coordinating standardization of I&IT in the Government of Ontario. In particular, GO IT Standards describe where the application of an IT standard is mandatory and specify any qualifications governing the implementation of the IT standards.
2 Summary
2.1 Standard Name and Description
This document defines GO-ITS 55: OPS Service Centre Interaction Model.
2.2 Background and rationale
In August 2005, Cabinet approved eOntario as the government’s I&IT strategy. The eOntario program has identified a number of transformational initiatives for the OPS. A number of these initiatives are focused on the consolidation and delivery of infrastructure technology services to the OPS. One such initiative is the Service Management project. Within the boundaries of this initiative, the Infrastructure Technology Services (ITS) has been commissioned to implement the OPS IT Service Desk (hereafter known as OPS Service Centre OPSSC or OPSSC Technical) and to undertake the role of Incident Manager for service delivered through these consolidation initiatives.
This mandate is not limited to but will initially include:
- Providing a single Tier 1 OPSSC for all users of OPS technology.
- Consolidating existing Tier 1 IT Service Desks (cluster and business - process, hardware, and software) for users of OPS technology.
- Creating a single entity for consolidated infrastructure service provisioning (Service Order Management).
- Use of a common OPS-wide suite of technology / tools suite supporting ITSM processes for the Service Centre and all tier n+ support staff, for I&IT delivered services.
- Facilitating the integration of processes between the clusters and ITS, including enterprise Incident Management (eIM), enterprise Change Management (eCM), enterprise Service Asset and Configuration Management (eSACM), Release Management (RM) and Service Level Management (SLM), to support services delivered by the ITS organization.
In February 2020 Ontario Shared Services (OSS) Contact Centre was realigned into the I&IT organization. Following this realignment, in January 2021 the OPS Service Desk and OSS Contact Centre integrated forming the OPS Service Centre (OPSSC).
This document covers the engagement for the OPSSC – Technical or IT service for the IT Standard, but not the OPSSC Business services (formerly OSS Contact Centre).
2.3 Target audience
The contextual model is intended for the management teams of all internal OPS I&IT providers, as well as broader public sector partners, citizen-facing call centres and ministry program / business service desks.
ITSM Process Owners across the OPS should also be familiar with how this contextual model describes the implementation of the Service Centre function as a key enabler of the Ontario government’s IT service management strategy.
The model also defines how external providers, such as vendors, will interact with the OPS I&IT service chain via the OPSSC - Technical.
IT Service Owners for existing and new services will be required to incorporate the Incident Support patterns defined by this model into their designs at the earliest stages of service planning.
This will ensure that services are consistently supported across the OPS, reducing costs for custom support solutions, and improving the speed and efficiency of support activities for their respective services once they have been released to production.
2.4 Scope
2.4.1 In scope
The model is focused on the OPSSC - Technical from an ITIL service management perspective, including such standards as incident management, for services delivered by and elements of service delivery managed by I&IT, based on the ITELC provided mandate.
The scope of this document applies to all contacts for OPS I&IT support, where the Service Provider is within the OPS I&IT organizational structure or undertakes to outsource to third parties on behalf of these internal provider groups.
Ticket ownership is described and established in their corresponding models such as GO ITS 37 for eIM and as such are not described in detail in this model. For a full listing of other GO ITS models and standards please visit the official website of the Ontario Government
2.4.2 Out of scope
Process models for service level, problem, configuration, change and release management, etc., will need to incorporate the OPSSC contextual model accordingly and hence, the interaction and integration of these and other GO-ITS processes have intentionally been excluded from the development of this model. For reference to other GO-IT standards, please visit the official website of the Ontario Government
These processes will be addressed jointly by the Office of the Corporate Chief Information Officer (OCCIO), enterprise ITSM Best Practice Office in conjunction with the OPS I&IT clusters.
OPSSC - Business services are out of scope for this standard.
2.5 Applicability statements
2.5.1 Organization
All Ministries and I&IT Clusters are subject to Government of Ontario IT Standards.
All adjudicative and advisory agencies are subject to Government of Ontario IT Standards.
All other agencies that are using OPS information and information technology products or services are required to comply with Government of Ontario IT standards if they are subject to either the Governance and Management of Information Technology Directive OR Government of Ontario IT Standards by memorandum of understanding.
As new GO IT Standards are approved, they are deemed mandatory on a go-forward basis (go-forward basis means at the next available project development or procurement opportunity).
When implementing or adopting any Government of Ontario IT standards or IT standards updates, Ministries, I&IT Clusters and applicable agencies 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.
2.5.2 Requirement levels
Within this document, certain wording conventions are followed. There are precise requirements and obligations associated with the following terms:
Must - This word, or the terms "REQUIRED" or "SHALL", means that the statement is an absolute requirement.
Should - This word, or the adjective "RECOMMENDED", means that there may exist valid reasons in particular circumstances to ignore the recommendation, but the full implications (e.g., business functionality, security, cost) must be understood and carefully weighed before choosing a different course.
3 Technical specification
This model provides service support patterns for the OPSSC. The model is bounded and focused on the high-level business overview of the OPSSC, specifically around how it interacts with service chain partners such as clusters, ministries and corporate providers. It is intended to inform stakeholders of the OPSSC model, how their organizations would interact with the OPSSC, and to describe/define consistent ways in which non-IT partners and broader public sector providers would interface with the OPSSC.
3.1 OPSSC Roles and Responsibilities
It is important to note that these are roles and not individual resources. In many cases, resources may play one or many of these roles, in addition to other roles within their respective organizations.
3.1.1 OPSSC Senior Manager
This manager has overall accountability for the integrated OPSSC sites. He or she manages the OPSSC sites and, where appropriate, delegates authority to the OPSSC managers.
3.1.2 OPSSC Incident Manager
The Incident Manager is responsible for the operational quality and integrity of Incident Management process activities. The Incident Manager is ultimately accountable for all Incidents and is the primary Incident Management escalation point.
3.1.3 OPSSC Manager
This role is the on-site manager responsible for direct management of site staff. The OPSSC Manager may represent the OPSSC Senior Manager where appropriate.
3.1.4 OPSSC Team Lead
The Team Lead provides lateral and hierarchical business and technical operational support to all level of Service Centre staff.
3.1.5 OPSSC Incident Coordinator
The Incident Coordinator functions as the primary focal point for priority 1 & 2 incidents while in tandem coordinating the process execution, resource identification, and Major Incident Review (MIR) activities.
3.1.6 OPSSC Queue Manager
The OPSSC Queue Manager role is responsible for addressing process execution issues encountered by support personnel and ensuring that all tickets assigned to a queue are promptly actioned within pre-defined guidelines.
3.1.7 OPSSC Analysts
The OPSSC Analyst, being in most instances the 1st line support professional, is the primary contact person for the customers and functions as a hub between the customer organization and the IT organization.
3.2 Concepts and Definitions
3.2.1 Assign
A partner in the OPS I&IT service chain assigns a ticket to a provider that is in its own IT provider organization (e.g. internal OPSSC Tier 1 to internal tier n).
3.2.2 Dispatch
A partner in the OPS I&IT service chain dispatches a ticket to a provider outside of the OPS I&IT organization (e.g. OPS to an external vendor). Updates may be managed manually (e.g. phone, email, etc.) or electronically (e.g. ITSM electronic bridge).
3.2.3 Parent incident record
A parent record represents an incident where subsequent reporting of the same incident criteria is considered duplication of the parent (e.g. WAN outage affecting a large site).
3.2.4 Child incident record
A child record represents one of the duplicate incidents associated to a parent. Some updates to the child incidents are replicated to the parent incident (e.g. incidents related to the WAN outage).
3.2.5 Parent / child incident record functionality
Technical definition: parent/child is a model for a communication protocol where one device or process has unidirectional control over another (or others). Once a parent/child relationship between devices or processes is established, the direction of control is always from the parent to the child(s).
All updates to a parent incident are replicated to all Child incidents through technology.
- Updates to child incidents are not (unless they add relevance to management of the parent) replicated to the parent incident – replication in this case would be performed manually for now.
- Parent/child creation and management is a function of the OPSSC.
- Correlation of child incidents to a parent incident is a function of the OPSSC.
3.3 Service support patterns
3.3.1 Service definitions
| Term | Definition |
|---|---|
| Service | A Service is the exchange of value between two partners, where one partner plays the role of a provider and the other plays the role of a customer. |
| Service customer | The service customer is the payer of a service, representing a group of consumers for a given service. The customer approves service procurement activities and normally processes billing activities on behalf of the consumers. |
| Service consumer | A resource that consumes a particular service or in some cases makes a request of service that may then require customer approval. |
| Service provider | A partner that is responsible for the provisioning of a service, including, but not limited to, operations, invoicing, customer relations, marketing etc. Multiple providers are often combined to deliver/support an end-to-end service |
| Service owner | An individual who is accountable for the delivery of a service in compliance with stated objectives and for ongoing service improvement |
3.3.2 OPS I&IT service chain partner definitions
| Term | Definition |
|---|---|
| OPS I&IT Service Chain | The chain of customer/provider and provider/provider partner relationships that define the end-to-end capability and delivery of a particular service. |
| Citizen-Facing Desk | A consumer/user-facing interface to citizens for handling business program inquiries, government services/solutions and policy questions pertaining to one or more program offerings |
3.3.3 Key Roles
| Term | Definition |
|---|---|
| Ministry program | The primary “customer” of OPS I&IT services. It may provide services to external consumers (citizens) or internal consumers (OPS employees). |
| Application service provider | OPS I&IT service chain partners who support the functionality and quality of application-based services that are supported by various infrastructure services. |
| Infrastructure service provider | An OPS I&IT service chain partner who provides common, (possibly utility-grade) infrastructure services that are often used in the service chain of application-specific services. |
3.3.4 eIM Partner Tier Definitions
The definitions below are specifically provided for OPS I&IT service chain partners. The OPSSC provides a common tier 1 function for all internal OPS I&IT partners
| Tier | Deliver | Role/ Accountability | Implications and Activities |
|---|---|---|---|
| Tier 0 |
|
|
|
| Tier 1 |
|
|
|
| Tier n |
|
|
|
3.3.5 Support Patterns
3.3.5.1 OPSSC support pattern
Accessible description of infographic 1
In this very common pattern, ministry consumers experiencing service interruption/ degradation or requesting service request fulfillment will contact the OPSSC. The OPSSC will then assign internally to the appropriate internal support groups within ITS or cluster or dispatch the incident to one or more external partners for incident resolution or fulfillment. Inaccurate assignment/dispatch of incidents, or where service partners require engagement of other tier n service partners, may result in incident reassignment/dispatch back to the OPSSC
This model also addresses the OPP officially exempted OPSSC models within the ministries where IT support is provided due to exceptional circumstances (OPP desk for handling secure/sensitive OPP PKI requests and break-fix incidents).
*Vendor engagements and incident handoffs are designed during release and planning activates at the discretion of the OPSSC.
3.3.5.2 Ministry program/ business service desk pattern
Accessible description of infographic 2
This pattern represents the same incident support approach for both. Cluster or ITS services, but where ministry or broader public sector consumers require interaction with a ministry program / business service desk. This may be necessary for reasons such as security, privacy, information sensitivity or to ensure that user requests are not policy or business process-related.
The OPSSC would diagnose and assign/dispatch incidents to the appropriate tier n support groups as outlined in the previous patterns.
Incident communications would be exchanged with the consumer and the ministry program / business service desk. This facilitates the requirement where some program areas may have post-incident activities to perform in order to meet specific customer requirements.
This model also addresses any officially exempted business desk models within the ministries where IT support is provided due to exceptional circumstances (e.g. OPP desk for handling secure/sensitive OPP PKI requests and break-fix incidents).
3.3.5.3 BPS/ ABC Service Centre pattern
Accessible description of infographic 3
The Broader Public Sector (BPS) / Agencies, Boards, Commissions Service Centre pattern addresses the condition where another I&IT BPS/ABC partner is managing parts of their consumers’ end-to-end service but where other parts are delivered within the OPS. Agencies providing I&IT services would generally fall under this pattern.
The BPS/ABC I&IT Service Desk would have its own incident and would be considered the customer/ consumer of the OPS incident.
The OPSSC would diagnose and assign or dispatch the incident internally as outlined in the previous patterns. The BPS/ABC I&IT Service Desk would be responsible for updating their incident and communicating to their customer(s) as required.
*Terms and conditions may apply, at the discretion of the OPSSC, where BPS/ABC requires direct support from the OPSSC to meet their business needs/requirements, not defined in other engagement models.
3.3.5.4 Citizen-facing desk pattern
Accessible description of infographic 4
In this pattern, the consumer of service is a citizen. Citizens may contact ministry program / business service desk, or they may contact Service Ontario. These citizen-facing desks would qualify if the citizen is experiencing an outage resulting from an OPS service interruption. They would then contact the OPSSC to log an incident.
The customer/ consumer of the OPSSC incident would NOT be the citizen. It would always be the respective business desk/ service Ontario and/or the specific business desk agent who initially communicated with the citizen. No citizen information would be passed to the OPSSC or stored in the enterprise ITSM toolset.
Upon logging an incident, the OPSSC would diagnose and assign or dispatch the incident internally as outlined in previous patterns. Ongoing status and communication of the incident status would be performed between the OPSSC and either a ministry program / business service desk or Service Ontario. These citizen-facing desks would be responsible for communicating with the citizen accordingly.
* Terms and conditions may apply, at the discretion of the OPSSC, where a citizen group requires direct support from the OPSSC to meet their business needs/requirements, not defined in other engagement models.
3.3.6 OPS I&IT incident ownership
The OPS I&IT incident ownership represents the detailed principles required to effect the mandate provided to ITS by ITELC in October 2005, namely to commission the single point of contact (SPOC) for OPS I&IT technology-based services within ITS.
- Ownership implies monitoring, communication coordination, escalation, updates and resolution/fulfillment responsibility for both Service Interruption and Service Request incidents.
- All incidents are owned by the OPSSC either when incidents are initially logged, or when they are assigned from a tier n provider to the OPSSC.
- Validation of major / high priority incidents is a function of the OPSSC, requiring that incidents suspected of being major / high priority be communicated / called to the OPSSC.
- Once a major / high priority incident has been validated by the OPSSC, escalation and communication protocols for high-priority incidents are initiated.
- When a major incident manager / situation manager cannot easily be identified for a given major outage, the OPSSC incident manager will manage the major / high priority incident until a situation manager can be identified.
4 Related standards and impacted infrastructure
4.1 Impacts to existing standards
Identify any standards that reference or are referenced by this standard and describe the impact.
| GO-ITS standard | Impact | Recommended action |
|---|---|---|
| GO-ITS 37: Enterprise Incident Management Process | GO-ITS 55 provides additional detail and clarity around the generic OPS incident management Process Procedures Guide (PPG), specifically around roles. | Review / employ both GO-ITS 37 and GO-ITS 55 when undertaking service development or service planning initiatives. |
4.2 Impacts to existing infrastructure
Identify any applications, systems, solutions and technology platforms that could be affected by this standard and describe the impact.
| Impacted infrastructure | Impact | Recommended action |
|---|---|---|
| Service Management documentation may require amendments / updates to reflect overall Continual Service Improvement (CSI) | Clusters and service providers required to interact with the OPS ITSD may have to update / adjust internal / local process documentation to reflect standard patterns provided in this document | Add a step in all Service Transition plans within the Clusters to review / assess level of incident management documentation required and perform gap analysis against GO-ITS 37 (Roles specifically) and GO-ITS 55, detailed incident support patterns to ensure continuity of services. |
5 Compliance requirements
In order to manage the effectiveness and implementation of this standard, Ministries, I&IT Clusters and applicable agencies are expected to adopt and monitor compliance.
6 Roles and responsibilities
Accountable Role (Standard Owner) Definition
The individual or committee ultimately accountable for the process of developing and maintaining 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.
Accountable Role:
Title: Chair, Service Management Executive Committee (SMX)
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):
Ministry: Ministry of Public and Business Service Delivery (MPBSD)
Division: Infrastructure Technology Services (ITS)
Branch: Service Management Process and Operations
Support Role Definition
The support role is the resource(s) to whom the responsibility for maintaining this standard has been assigned. Inquiries, feedback, and suggestions should be sent to this resource.
Support Role (Editor):
Ministry: Ministry of Public and Business Service Delivery (MPBSD)
Division: ITS
Branch: Service Management Process and Operations
Job title: Senior Manager
Name: Justin Stiles
Phone: 905-658-6476
Email: Justin.Stiles@ontario.ca
7 Consultations
Areas consulted as part of the development of this standard. Include individuals and committees, councils and/or working groups:
| Organization Consulted (Ministry/I&IT Cluster) | Division | Branch | Date |
|---|---|---|---|
| Tracey Burns | CAC | n/a | n/a |
| Steve Theofilaktidis | CAC | n/a | n/a |
| Sacha Sone | CAC | n/a | n/a |
| Jennifer Ellis | CYSSC | n/a | n/a |
| Lucille Gauthier | LTC | n/a | n/a |
| Tim Trojko | GSIC | n/a | n/a |
| Ben Wagner | GSIC | n/a | n/a |
| Chantal Gallant | HSC | n/a | n/a |
| Ian Andersen | LRC | n/a | n/a |
| Vicki Barber | LRC | n/a | n/a |
| Jennifer Sherlock | JC | n/a | n/a |
| Cathy Hogan | JC | n/a | n/a |
| Candice Wright | CYSSC | n/a | n/a |
| Kathy Beaton | CYSSC | n/a | n/a |
| Christopher Phillips | CAC | n/a | n/a |
| Matthew Mroczeck | CAC | n/a | n/a |
| Jeff Miclash | LTC | n/a | n/a |
| Linda Anceriz | CSC | n/a | n/a |
| Stephane Vertefeuille | ITS | n/a | n/a |
| Jeff Martinson | ITS | Service Management | n/a |
| Committee/Working Group Consulted | Date |
|---|---|
| Partner Incident Management Liaison (PIMLs) and enterprise Incident Manager (eIM) review | 2015-12-11 |
| IT Service Management Leads (ITSML) | 2015-12-17 |
8 Document history
| Date | Summary |
|---|---|
| 2007-04-30 | Original - GO ITS 55 version 1.0 created |
| 2007-04-30 | Changed the informative reference - Internal incident management process and procedures guide v1.2.5 to v1.2.9 |
| 2007-07-26 | Approved by the Architecture Review Board (ARB) 2015-11-19 Modernized engagement standards and terminologies, to align with business models. |
| 2015-12-11 | PIML review and feedback implemented |
| 2016-01-22 | Updated to current GO-ITS template (2014-11-27) and revised to ensure content consistency and structure across GO-ITS process standards. |
| 2016-03-16 | Architecture Review Board endorsement |
| 2016-03-31 | IT Executive Leadership Council approval |
| 2022-02-22 | Updated to reflect realignment of Ontario Shared Services (OSS) within the I&IT organisation and the name change from Service Desk to Service Centre |
| 2022-10-05 | Architecture Review Board endorsement |
| 2022-11-24 | IT Executive Leadership Council approval – Approved version number set to 2.0 |
9 Appendices
9.1 Normative references
Governance and Management of Information Technology Directive:
Enterprise Incident Management GO-ITS 37
Note: a normative reference specifies a supporting document or GO IT Standard (in the case of the Government of Ontario's I&IT infrastructure, often another OPS I&IT authorized publication) that must be read to fully understand or implement the subject matter of the main GO IT Standard. Such authoritative or de facto references may be external and may, or may not be, owned/controlled by the GO IT Standard owner.
9.2 Informative references
None applicable
Note: an informative reference is not normative; rather, it provides only additional background information.
9.3 ITELC approved (Oct. 2005) vision
Accessible description of infographic 5
OPS Service Centre contextual incident model
Accessible description of infographic 6
9.4 Infographic Descriptions
Infographic 1: OPSSC support pattern
Step 1 - ministry consumer contacts the OPS Service Centre (tier 1)
Step 2 - incident is created
Step 3 - if incident can not be resolved at tier 1,it is assigned to either cluster tier 2 or ITS tier 2
Step 4 - if incident can not be resolved at tier 2, the current incident is assigned to external tier n
Step 5 - incident assigned to vendor Note: if applicable the OPSSC can and will assign incidents directly to the external tier n group where an agreement is in place for that direct relationship
Infographic 2: ministry program/business service desk pattern
Step 1: Ministry consumer/broader public sector consumer contacts the ministry program/business service desk
Step 2: Ministry program/business service desk contact the OPS Service Centre (tier 1)
Step 3: incident is created
Step 4: if incident can not be resolved at tier 1, it is assigned to either external tier n, ITS tier 2, or cluster tier 2
Infographic 3: BPS/ABC I&IT service desk pattern
Step 1: broader public sector consumer contacts the broader public sector I&IT service desk or can contact the IT service desk if this is an approved exception
Step 2: broader public sector I&IT service desk contacts the OPS Service Centre (tier 1)
Step 3: incident is created
Step 4: if incident can not be resolved at tier 1, it is assigned to either external tier n, ITS tier 2, or cluster tier 2
Infographic 4: citizen-facing desk pattern
Step 1: citizen of Ontario will contact either Service Ontario or ministry program/business service desk
Step 2: Service Ontario or ministry program/business service desk contacts the OPS Service Centre (tier 1)
Step 3: incident is created
Step 4: if incident can not be resolved at tier 1, it is assigned to either external tier n, ITS tier 2, or cluster tier 2
Infographic 5: ITELC approved (Oct. 2005) vision
The Information Technology Executive Leadership Council (ITELC) provides leadership and governance for the Information & Information Technology (I&IT) organization. This workflow demonstrates details about the infrastructure service delivery.
Vision is as follows:
- Ministry clients submit service requests/incidents
- Cluster provides the following in regard to infrastructure service delivery:
- Strategic services - customer relationship management,
- Strategic advice, business cases/assessment, investment decision.
- Business solutions - application development
- Solutions architecture,
- Integration/assembly,
- Application support & maintenance,
- Requirements definition
- Functional specification Information management security/architecture/privacy
- Business services - human resources/finance
- Administration
- Governance
- Planning
- Billing/chargebacks executive support to minister
- Deputy minister, and assistant deputy minister office -tier 2 support
- Customer care
ITS drives the infrastructure service delivery with:
- Infrastructure operations & support
- Release management in collaboration with the cluster - bundling related changes, testing, certification, service activation, readiness
- Technology integration - provides alignment, blueprints to cluster business solutions
- Service desks - support ministry clients and executive support via incidents
- Order desk for service in service catalogue - validate
- requests, orders, move-add-changes, order tracking
- Service catalogue (access, email, desktop, hosting, voice, GMCP, network, video) - driven by order management service provisioning
- Operational security
- Business services
- Others
Service assurance/end-to-end monitoring is fulfilled by:
- Service level management - IT SLA/OLA/UC
- IT - manage service performance
- Change management - assess, approve & schedule IT changes, change advisory board & RFC processing
- Configuration management - register, tracks, reports on IT assets using CMDB
- Governance - set IT policy & standards and administer controls
Infographic 6: OPS Service Centre Contextual Incident Model
The workflow demonstrates the OPS Service Centre - Incident Management Interaction Model. At the top we have the consumers/partners, which are:
- Automatic events detection
- Vendors
- External contractors (e.g., area maintenance contractors, Bell Canada)
- Business partners (e.g., business program/service desks)
- Insurance bureau of Canada
- Serco, LCS), OPS staff/FFS consultants
- Third party service provider (e.g., Getronics, Telus, Compugen)
- Broader public sector (e.g., municipalities, police services)
- Agencies, boards, and commissions (e.g., CAS)
Next, we have the communication channels, which are:
- Web access/service catalogue
- Electronic bridge
- Phone
- Faxes
- Web chat
- Teletype (TTY)
The workflow then identifies two sections that are part of the OPS incident management process (awareness & improvement). Both involve the incident management process owner.
- First, tier 1 – OPS Service Centre involves incident agents - generalists & SME and incident agents - VIP. Queue managers (in collaboration with service order management) include team leads, service order agents and service desk managers who work with incident coordinators and the incident manager on major incidents.
- Second, via either a functional escalation (assignment) or a stakeholder communication & escalation management we move to tier 2 - ITS Common infrastructure partner IM/KM liaison involving DS, EES, NAS, etc., incident analyst, queue managers, & Situation Mangers, cluster partner IM/KM liaison involving Solution Support Incident Analyst, Queue Managers, & Situation Mangers.
Finally, we have tier n which is driven by function escalation (dispatch) and is part of the OPS standard compliant incident management process. It involves external vendor support via the partner IM/KM liaison.