GO-ITS 41 Enterprise Service Level Management

1. Introduction

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.

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:

• Internet: https://www.ontario.ca/page/information-technology-standards

2. Summary

2.1 Standard Name and Description

GO-ITS document number 41 outlines the technical standards for the IT service management practice called Service Level Management, based on the Information Technology Infrastructure Library (ITIL) framework.

2.2 Background and rationale

2.2.1 Background

The need for an OPS Service Level Management standard grew as the post-eOntario I&IT organization has matured. The establishment of Government of Ontario IT (GO-IT) standards for Incident, Problem, Change, Service Asset and Configuration Management processes prepared a family of GO-IT standards that is missing Service Level Management.

In 2005, occurring concurrent with the positioning of all infrastructure service and support within Infrastructure Technology Services (ITS), a Terminology Reference Model (GO-ITS) Document 44) was drafted which made repeated reference to service level management as well as to performance monitoring and reporting. A document titled “Service Categorization Framework” was also drafted that spoke of the need for the new organization within the OPS (mandated in 2005) to deliver infrastructure services to the OPS. The ITS organization was created in 2006 to achieve this goal.

2.2.1.1 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:

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, e.g., GO-ITS 40 Enterprise Release Management (2016) and GO-ITS 41 Enterprise Service Level Management (2018).

2.2.1.2 Enterprise Service Management

In 2016, the Enterprise Service Management (eSM) Division was established to centralize the provisioning, management, and development of IT Service Management functions and processes. The establishment of a single Enterprise Service Level Management process was part of the mandate for eSM. A GO-IT Standard to support the roll out and operation of Enterprise Service Level Management was seen as essential.

In 2019, the eSM division was re-aligned with the ITS division of the Ministry of Government and Consumer Services as a branch of that division.

2.2.2 Rationale

2.2.2.1 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 to accommodate changes in terminology and process elements. The new ITSM toolset is called the Enterprise IT Service Management Tool, which will be referred to as eSMT throughout this document.

The new ITSM toolset introduced a Service Level Management enablement module as part of the suite of process enabling capabilities. The existing SLM process framework was adapted in part to align with the model for SLM process execution that eSMT introduced.

In this context, in recognition of the growing interest in and need for measuring, monitoring, and reporting on performance in the delivery of IT services, approval was granted to the ITS Best Practice Office to begin authoring a Service Level Management GO-IT Standard.

In December 2015, a working group charged with developing a forward-looking enterprise Service Level Management process was established. That working group provided substantial input into the standard elements of this current SLM process document herein. Additionally, a Service Level Management Community of Interest (SLM CoI), a sub-committee of the IT Service Management Leadership Forum (ITSML), was provided authority to review and recommend endorsement of SLM standards proposals.

As part of the establishment of the eSM division, a new governance framework was implemented that remains in place today, including a Process Standards Working Group (PSWG) that has a mandate to oversee the maintenance of IT Service Management standards documents.

2.3 Target audience

The target audience for this document includes, but is not limited to:

• Developers
• Technical implementers
• Procurement staff
• Program managers
• OPS I&IT Service Providers
• External or third-party service suppliers
• IT Service Management staff and agents

2.4 Scope

2.4.1 In scope

GO-ITS documents apply to all vendors, ministries, former Schedule I and IV agencies, and third parties (including any information technology system or network that processes ministry and agency information) under contract to the Ontario government unless exempted in a Memorandum of Understanding.

The scope of this document is to define key aspects of the enterprise Service Level Management process, including principles, roles, and process models. Major topic areas include:

• Principles, Roles, Responsibilities, and the high-level process flow required to ensure an enterprise perspective of Service Level Management for the OPS.
• Definition of an Enterprise Service Agreements Model (eSAM) outlining the core set of documents to be used to formalize arrangements for the delivery and consumption of IT services across the OPS
• Incorporation of ITIL 2011 concepts and terminology and a discussion of the implications of ITIL v4
• Introduction of a service-based focus for enterprise process management disciplines based on a Business Service Management model

2.4.1.1 Recommendations for Future Direction

These standard elements aim to establish a single, unified process for enterprise Service Level Management within the OPS. Use of a single process and supporting information will enable OPS-wide management and reporting for Service Level Management through the establishment of pertinent metrics and measurement norms.

The GO-ITS 44 ITSM Terminology Reference Model documents a common information model for key process parameters that require standardization across the OPS to ensure consistency, reliable business intelligence, and to support end-to-end cross-jurisdictional service management. GO-ITS 44 will be updated with additional values defined as part of GO-ITS 41. Please refer to GO-ITS 44 at: https://www.ontario.ca/page/information-technology-standards#section-3

2.4.2 Out of scope

The Enterprise Service Agreements Model (eSAM) outlining the core set of SLM documents includes references to the Service Catalogue (Business and Technical) as well as references to Underpinning Contracts (agreements with external service suppliers). At this time, a full description of standards related to Service Catalogue Management and of the applicability and contents of Underpinning Contracts is out of scope for this GO-ITS.

2.5 Applicability statements

2.5.1 Organization

All Ministries and 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 organizations’ 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, boards, or commissions.

2.5.2 Other applicability

Service Catalogue Management was added as a distinct new process in ITIL V3 (2007). Prior to that change, Service Catalogue Management was carried out as part of the Service Level Management process.

Within the OPS I&IT, accountability for Service Catalogue management has remained with Service Level Management and has not been formally identified as a distinct practice.

This standards document addresses Service Level Management activities and terminology within the context of a Service Catalogue Management function that is overseen by Service Level Management.

2.5.3 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.

2.5.4 A Word on Capitalization

The rules regarding the capitalization of titles are not universally agreed to and provide only vague guidance. In this document, capitalizing terms such as service level agreement, operational level agreement, agreement, and so on, will depend on specificity. That is, in cases where the usage is general, the term will be lowercased. Where the usage is specific, the term will be capitalized as a proper noun.

Thus, in referring to agreements as a type of document, the term will be lowercased. For example, in the phrase “arrangements are documented in operational level agreements”, the reference is general and therefore the term is not capitalized.

However, in referring to a document formally identified in the Enterprise Service Level Management document set, for example, the term will be capitalized, as in the Primary Service Level Agreement, or the Enterprise Operational Level Agreement. Likewise, a role that is formally defined in this GO-IT Standard will be capitalized, as in ‘Service Owner’ or ‘Service Level Manager’.

3. Technical specification

The following requirements apply to all I&IT assets and operations within the scope of the Governance and Management of Information Technology Directive.

3.1 SLM Process Definition

Service Level Management (SLM) is part of the Service Design stage within the Information Technology Infrastructure Library (ITIL v2011). In ITIL v4, SLM is part of the set of service management practices.

SLM is the process of negotiating, obtaining agreement, and documenting appropriate IT service targets with representatives of the business. As part of the SLM process, agreed IT service targets are monitored and the service provider’s ability to deliver the agreed levels of service is reported to the business.

In support of service delivery to the business, Service Level Management ensures that arrangements are in place with internal IT service providers and that those arrangements are documented in operational level agreements (OLAs). Where necessary, arrangements are established with external service suppliers and those arrangements are documented in underpinning contracts (UCs.

According to ITIL guidance, “SLM is a vital process for every IT service provider organization in that IT is responsible for agreeing and documenting service level targets and responsibilities within SLAs and SLRs, for every activity within IT.”^{footnote 1[1]}

3.1.1 SLM Process Objectives

The objectives of the SLM process are to:

• Identify, document, monitor, measure, and report on the level of IT services provided
• Improve the relationship and communication with the business and customers
• Develop specific and measurable targets for all IT services
• Monitor and improve customer satisfaction with the quality of service delivered
• Ensure that IT providers and their customers have clear, unambiguous expectations of the level of service to be delivered
• Take proactive measures to reduce the risk of breaching the commitment to deliver specific levels of service
• Take action to improve the levels of service delivered when there has been a breach of commitment are wherever IT is cost-justifiable to do so

3.2 SLM Process Principles

Principles are established to ensure that the process 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 work instructions that will ensure consistent execution of the process. The absence of well-defined and well-understood principles may result in process execution that is not aligned with the process standard. Process Principles for OPS Enterprise Service Level Management are listed below.

3.2.1 Process Principle 1

Business units will provide consolidated business Service Level Requirements information.

Rationale:

• Promotes business unit buy-in and responsibility for influencing the Service Level Requirements for their services
• Promotes a business-oriented approach to defining Service Level Requirements information
• All Service Level Requirements are driven by business needs

Implications:

• Business units have committed to the process
• A method exists to translate business requirements into IT terms and targets

3.2.2 Process Principle 2

One Service Level Management process based on the IT Infrastructure Library (ITIL) will be utilized throughout the organization.

Rationale:

• To ensure consistent and quality collecting of service level and performance data and one unified Service Level Management process

Implications:

• Improved ability to manage end-to-end IT service and performance levels
• Improved ability to meet the customer’s requirements, in a cost justifiable manner
• Improved ability to meet service levels documented in the Service Catalogue and/or service level agreements^{footnote 2[2]}
• Consistent planning
• Improved monitoring, analysis of data and management information
• Clear roles and responsibilities along with proper authority defined and documented
• Cleary defined expectations

3.2.3 Process Principle 3

Each service provided shall be defined, agreed, and documented in one or more service agreements (SLAs, OLAs).

Rationale:

• To ensure Customers have a clear understanding of the responsibilities and services provided by the IT providers
• To ensure the customers understand their responsibilities and the IT providers have a clear view of the customers’ needs

Implications:

• Improved communication between Business and IT service providers.
• Improved ability to meet service levels defined in the service agreements
• Improved Management Information
• Clear roles and responsibilities along with proper authority defined and documented
• Cleary defined expectations
• A service agreement is in place to ensure both parties have equal expectations of the service to be delivered

3.2.4 Process Principle 4

Service agreements, supplier contracts, and procedures for managing and maintaining these, shall be agreed by all relevant parties. These procedures and the agreement to them shall be recorded.

Rationale:

• Ensures that consistent and formal approaches are used to capture business requirements and agree on the service levels required
• Provides a communication vehicle to demonstrate how IT is improving its service quality to the business

Implications:

• Clear understanding of business requirements and IT capabilities for the delivery of services
• Baseline for measuring service levels and identifying potential areas of improvement
• Participation of all parties in the creation of service agreements improves accountability
• Improved ability to properly prepare and design services and agreements to meet business requirements

3.2.5 Process Principle 5

The services to be provided will be defined in the form of specific service offerings that support our customers’ business processes and expectations.

Rationale:

• Ensures service offerings are aligned with business processes and support business goals
• Assure the affordability of services being offered/received
• Limit the number of special services by ensuring basic services provide the utility and the warranty to meet business needs
• Reduce the number of service agreements to be managed

Implications:

• There is an understanding of how our services support our customers’ business processes.
• We have tools that support the allocation of cost
• We ensure only valuable services are funded
• We consider which service agreement structures to use

3.2.6 Process Principle 6

Service Level Management will conduct periodic reviews of the service agreements and related Service Level Management reporting.

Rationale:

• Ensure that the service agreements and reporting are current and remain effective over time
• Reviews are performed to ensure that service performance management-reporting activities continue to meet established Key Performance Indicator (KPI) requirements for the Service Level Management process
• Periodic reviews help ensure agreements and reports remain meaningful over time
• Meaningful reports will enable IT to communicate the value of its services to the business
• Business can more clearly understand how IT services support business goals and objectives

Implications:

• Improved management of customer expectations
• Improved communication between Business and IT provider(s)
• Provides continual improvement of all reports
• IT service providers understand the business use of their services
• A mechanism for measurement and regular reporting on these services is in place
• KPI definitions are in place that use business terms
• Communicating the relevance of KPIs in providing business value is achieved
• A process to track KPIs and adjust service accordingly is in place

3.2.7 Process Principle 7

Service levels shall be monitored in a manner that allows notifications to be provided when compliance with service agreements is at risk; this should allow Service Owners to take preventive actions before a breach of commitments occurs.

Rationale:

• Supports the delivery of service to business in compliance with commitments
• Promotes a proactive stance in managing service delivery to meet commitments

Implications:

• Improved management of service performance
• Improved customer relations
• Tools and/or processes are required to support continuous monitoring of service performance status against commitments
• Service Owner’s organization must be responsive to notifications for such notifications to be effective
• Service Level Management process must provide a means of ensuring the notifications and response to them remain effective and are managed through measurements, monitoring, and reporting

3.2.8 Process Principle 8

Service levels shall be monitored and reported against targets, showing both current and trend information. The reasons for non-compliance shall be reported and reviewed. Actions for improvement identified during this process shall be recorded and provide input into a plan for improving the service.

Rationale:

• Supports continual improvement of IT Services
• Ensure the creation of service improvement plans
• Provides a means for prioritizing improvements based on business priorities and needs
• Provides a communication vehicle to demonstrate how IT is improving its service quality to the business
• Objective measurement facilitates cost-benefit analysis of changes

Implications:

• Improved customer relations
• Improved management of service performance
• Formal and consistent reporting
• Both IT and the business recognize that service improvement is an ongoing activity – not a one-time project
• We have objective measurements
• We educate all involved in the improvement cycle
• We understand that improvement activities must be seen as an investment, they cost time and resources that are recovered later in terms of quality-of-service delivery
• We communicate the benefits of continual improvement to all
• Our culture recognizes that continual improvement of service quality is a key part of Service Management’s role

3.2.9 Process Principle 9

Except under strict conditions, a single Service Owner shall be identified for each service for which there is a service agreement; the Service Owner is accountable for preventing breaches and correcting problems once a breach has occurred.

Rationale:

• Ensures service agreements are met and that any breaches to commitments that do occur will be avoided in future
• Supports continual improvement of IT Services
• Ensures the creation of service improvement plans

Implications:

• Only one individual with the appropriate authority to allocate resources may be identified as the Service Owner unless a specific, formal agreement is documented for shared service ownership
• The service level management process, along with its tools and roles, must support the Service Owner
• A service that will be the subject of a formal agreement may not proceed to production and support without a Service Owner identified who accepts accountability for that service’s performance

3.3 Service Agreement Principles

Service Agreement Principles are established to promote the desired outcomes or behaviours related to drafting service agreements. They also serve to provide direction for the development of procedures and (as necessary) work instructions that help ensure consistent creation of agreement documents and related service documentation. The term ‘service agreements’ is used here and throughout this document as a general reference that includes service level agreements (SLAs) with customers and operational level agreements (OLAs) with IT Service Providers, and underpinning contracts (UCs).

The absence of well-defined and well-understood principles may result in service agreements that do not support the overall process principles, and which are not aligned with the process standard. Principles for OPS Enterprise Service Level Agreements are listed below.

3.3.1 Service Agreement Principle 1

Service Level Management is responsible for documenting the service level agreement between the IT customer and the IT service provider.

Rationale:

• Promotes the development of expertise and the adoption of standards relating to service level management and service level agreements within the OPS
• Helps ensure a consistent procedures and language are adopted to support the business-oriented approach to documenting business service level requirements and IT commitments in relation to those requirement
• Supports the Process Principle 2 (‘One Service Level Management process’)

Implications:

• Adequate personnel are deployed to Service Level Management
• Other IT service management processes and functions have committed to the process
• Business units have committed to the process
• Engagement with SLM early in the service design or service renewal phase is required

3.3.2 Service Agreement Principle 2

Service agreements (SLAs, OLAs) document the key aspects and provisions of the agreement between the customer and the IT organization that are intended to support improving communications.

Rationale:

• Ensures IT customers have a clear understanding of their responsibilities in consuming the services provided by the IT providers
• Ensures service agreements are used as a convenient reference for business leaders in understanding IT’s commitments and how to assess the success in meeting those commitments
• Ensures IT providers have a clear view of the customers’ needs and how to ensure those needs are met and perceived to be met by the customer
• Ensures service agreements support the central purpose of Service Level Management (promote dialogue, mutual trust and respect)
• Ensures service agreements are used as a convenient reference for IT leaders in understanding the supporting commitments they depend on to build service value
• Supports the need for regular reviews of existing service agreements

Implications:

• Requires well-defined processes with clearly identified cross-process inputs and outputs to ensure consistent service planning, design, and coordination
• Requires that clear roles, responsibilities, and authorities be defined and documented
• Requires specific and broadly publicized means of documenting, communicating, and distributing relevant service information
• Requires an explicit description and broad adoption of the concept of a holistic Service Information System.
• Information that is superfluous to service agreements must be removed and, where necessary, published in supporting, corollary vehicles such as the Service Catalogue.

3.3.3 Service Agreement Principle 3

Service Agreement documents shall focus on summarizing IT service level commitments and service benefits which the customer requires and which the IT organization has the capacity to deliver.

Rationale:

• Ensures agreement documents are clearly focused on IT service level commitments and, with Service Agreement Principle 2 above, on related information and functions
• Ensures the proper alignment exists between business requirements and IT capacity
• Increases the likelihood that service agreements succeed as convenient reference documents and as tools for supporting effective communications between the business and IT
• Supports identifying common, repeatable service performance commitments and metrics that can be summarized for multiple customers (example: corporate-level service commitments)
• Helps clearly delineate the roles of various document sets that are used to capture service information such as solution and system architecture, design specifications, financial arrangements, service level provisions, etc.
• Allows SLM to create a sustainable and manageable strategy for documenting and managing service levels and service delivery performance across the OPS
• Helps SLM more effectively identify, measure, and monitor end-to-end IT service and performance levels
• Supports the need for regular reviews of existing service agreements

Implications:

• Simple, efficient, and highly focused documents are required to improve their usefulness to business and IT leaders
• Service documentation must exist and be published to make other important service information available to business and IT leaders
• Service agreements must be written and read in the context of a broader set of service documentation that forms Service Information System
• Requires an explicit description and adoption of the broad concept of a Service Information System
• Clear roles and responsibilities, along with proper authority, are defined and documented
• Information superfluous to service agreements must be removed and, where necessary, published in supporting, corollary vehicles such as the Service Catalogue

3.3.4 Service Agreement Principle 4

Service agreements shall be drafted in accordance with the highest principles of partnership between the Business and IT.

Rationale:

• OPS Ministries and the OPS I&IT organization operate on the principle of strategic partnership built on mutual trust, respect, openness, and transparency for the benefit of the citizens and businesses of Ontario
• Service agreements are not intended to function as educational documents, as a defensive or protective measure, as a contract, or as a strategic political lever
• Minimizes resistance to entering into agreements and supports adoption of the service level management process and realizing its benefits

Implications:

• Parties to service agreements must commit to the fundamental principle of cooperation, openness, and mutual trust and respect
• A broad perspective must be adopted with regard to creating service documentation and making IT available to customers
• An agreed set of documents and publication vehicles must be in place for capturing other service information such as financial arrangements, technical specifications, service and solution design considerations, detailed policies, restrictions, limitations, and management considerations

3.3.5 Service Agreement Principle 5

The language of any service agreement must be appropriate to the receiving party.

Rationale:

• Ensures agreement provide value to the receiving party as a usable, convenient document
• Supports key objective of the SLM process, namely, to foster and promote effective communications between or among customers and their IT providers
• Supports the promotion of transparency and openness in dealings between IT and customers.

Implications:

• Agreements may require reviews and rewriting to ensure the language is appropriate
• Other service documentation such as portions of the Service Design Package and the Service Catalogue may require reviews and rewriting
• Personnel may require training and/or support to ensure the skillsets are available to write agreements and related service documentation in language appropriate to various receiving parties

3.3.6 Service Agreement Principle 6

SLM shall conduct periodic reviews of the service agreements and related Service Level Management reporting.

Rationale:

• Ensures that the service agreements and reporting are current and remain effective over time.
• Reviews are performed to ensure that service performance management-reporting activities continue to meet established Key Performance Indicator (KPI) requirements for the Service Level Management process
• Meaningful reports will enable IT to communicate the value of its services to the business
• Business can more clearly understand how IT services support business goals and objectives
• Misalignment of IT service delivery with its capacity or with business requirements are duly identified and corrected

Implications:

• Tracking the success in meeting customer expectations is required to inform reviews of service agreements
• Communication between Business and IT provider(s) should occur regularly to avoid unpleasant surprises or insurmountable issues during reviews of service agreements
• Requests for improvement during the agreement cycle, prior to the review exercises, must be effectively tracked and included in the review of an agreement
• KPI definitions for process effectiveness and for service effectiveness are in place, use business terms, and are ready for use as input into the review of agreements

3.4 Conceptual Foundation: 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.

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.

3.4.1 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 literature^{footnote 3[3]} 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 to maximize the return on public funds.

3.4.2 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.

Image

Figure 1 Visualization of the Business Service Management Model ^{footnote 4[4]}

Accessible description of figure 1

Above the diagram, at the very top of the image, “Business Services” is written.
A larger outer torus surrounds an inner circle.
The inner circle has at the centre of it “CMDB/CMS” and the heading ‘Integrate and Orchestrate’.
The outer torus is divided into four equal parts labelled, clockwise, ‘Request and Support’, ‘Provision and Configure’, ‘Monitor and Operate’, and ‘Plan and Govern’.
On the boundary of each of these four parts are listed two IT service management processes or functions, starting with the two on the boundary between ‘Request & Support’ and ‘Provision and Configure’, then continuing clockwise. These pairs are:

• Change & Release Management & Service Level Management
• Discovery & Dependency & Mainframe Automation
• Dashboards & Analytics and Event & Impact Management
• Service Catalog and Asset Management

Surrounding the outer edge of the torus are the names of IT Service Management processes, IT functions, and operational capabilities; these are:

• Service Request Management
• Incident Management
• Knowledge Management
• Service Request Management
• Problem Management
• Identity Management
• Application Automation
• Server Automation
• Network Automation
• Client Automation
• Enterprise Scheduling & Workload Automation
• Application Problem Resolution
• Middleware Management
• Performance and Availability Management
• Data Management
• Storage Management
• Capacity Management
• IT Controls and Policy Management
• Service Cost Management
• Financial Planning and Budgeting
• Supplier Management
• Demand and Resource Management

Below, at the very bottom, “Infrastructure” and “Shared Resource Pools” are written in large letters. In smaller letters, contained between the larger headings, the following infrastructure and shared resource pool types are listed:

• Physical
• Virtual
• Internal Cloud
• External Service Providers

This SLM standard is written with the intent of allowing ITSM processes in the OPS to move toward the BSM model. With that in mind, this Government of Ontario Standard puts forth terminology and process models in keeping with the precepts of the BSM model.

Further detail regarding the broader terminology within the BSM model and current OPS IT Service Management standards, please refer to the Terminology Reference Model GO-ITS 44 or individual IT Service Management standard documents.

3.5 Mandatory

3.5.1 Core Terminology: Working Definition of “Service”

3.5.1.1 Defining “Service”

In the context of the process Principles and the Business Service Management Model discussed above, the importance of defining “service” is clear. The casual use of the term to refer to resources, assets, capabilities, or functions renders IT nearly meaningless. For practical purposes within this standard, the term service will use the definitions below.

For a complete discussion of the rationale and underpinning concepts for this definition, please refer to the most recent version of the Terminology Reference Model, GO-IT Standard document number 44.

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:

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.

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 several 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

3.5.1.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., Active Directory 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 or Programs, IT Business Services, IT Technical Services, and IT assets is provided in Figure 2, below.

Image

Figure 2 Relationships among types of services and IT assets

Accessible description of figure 2

Image title: "Service Information Schema"

Connected shapes divided into four main groupings and one sub-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.

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

Below Business Services is the IT Business Services grouping, described as either "Services for Staff" or "Services for Business", which are: “Customer-valued outcomes offered and 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.”

Below IT Business Services is the IT Technical Services grouping, known also as "Services for Solution Providers". This grouping is described as “services offered and/or delivered by IT. Not valued on their own by the business customers. Supports the IT Service. Technical Services combine IT capabilities, assets, and resources in logical groupings. Technical Service providers often combine their services with other providers' services (e.g., Directory Services requires Hosting and Networking).”

Below IT Technical Services is the IT Components and Products grouping, which includes ‘IT Component Set (Solution)' and ‘IT Component Set (System)'. Each of those is connected to an IT Technical Service above.

Below IT Components is the sub-grouping labelled Individual CI's, including ‘IT logical CI's' and ‘IT physical CI's'. Together, the IT Components and CIs grouping is described as follows: “combinations of IT Products can be represented in sets (Component Sets). One or more sets can represent IT solutions or systems. IT components may be logical (e.g., process, data) or physical (e.g., hardware, equipment) assets or resources.”

3.5.2 Service Agreements

Service agreements within the context of Service Level Management are generally considered to include three main types:

• Service Level Agreements, or SLA’s
• Operational Level Agreements, or OLAs
• Underpinning Contracts, or UC’s

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

Image

Figure 3 Relationship of Agreement Type to Services

Accessible description of figure 3

Image title: "Service Agreements Overlay"

On the left side, there are four connected rectangles arranged vertically that represent, from the top down, Business Services, IT Business Services, IT Technical Services, and 3rd Party Providers. Over these shapes are arrows pointing upward from 3rd Party Providers to IT Technical Services, then from there to IT Business Services, and finally from there to Business Services.

On the right side of those shapes are three shapes labeled, top to bottom, SLA, OLA, then UC.

At the top right, the SLA shape points to the space between Business and IT Business Services and is described as follows: “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.

Next down is the "OLA" shape. It points to the space between IT Business Services and IT Technical Services and is described as follows: “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.”

Finally. The shape labeled “UC" points to the space between IT Technical Services and 3rd Party Providers and is described as follows: “Underpinning Contract (UC) between internal I&IT organizational entities and external (i.e., third-parties, vendor, etc.) organizational entities.”

The standard terminology for IT service agreements outlined above has been adopted as part of the creation of the Enterprise Service Management Division (2016) in the OPS. Prior to 2016, another set of terminology – the Integrated Service Agreements Model – was developed and endorsed for use by I&IT as part of the implementation of an SLM process and in response to needs for clear service information identified Ministry clients.

3.5.2.1 Background: Integrated Service Agreements Model

A model for creating and maintaining IT service agreements within the OPS was developed starting in 2007 and adopted in 2008. That model was called the Integrated Service Agreements Model, or ISAM for short.

ISAM provided a framework for building service level agreements within the substantial complexity and scale of the OPS while still offering the following characteristics for service agreements:

• Simple yet Comprehensive
• Reusable/Repeatable/Flexible
• Manageable/Maintainable

For service agreements to demonstrate these characteristics, ISAM described the importance of providing a broader set of documentation of the services that are delivered to ministry customers. This broader set of documentation included development and publication of service details, or specifications. Publication of these details was to be accomplished using the Service Catalogue.

The Service Catalogue, then, formed the essential context for the creation of service agreements that was central to the model. Service agreements were to be written and read in the context of the service specifications published in the Service Catalogue. Service level agreements were to be focused on summarizing service level commitments for ministry executives and program managers.

Doing so would allow service level agreements to exhibit the characteristics listed above and increase the likelihood of success in implementing Service Level Management within OSP I&IT.

3.5.2.2 Enterprise Service Agreement Model

Enterprise Service Level Management (eSLM) 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 has been made to simplify terminology and adopt conventional naming of such agreements in order to avoid confusion and to promote transparency and broad adoption. At the same time, the core principles of ISAM have informed the eSAM model, namely that the model provide for agreements that are:

• Simple yet comprehensive
• Reusable, repeatable, flexible
• Manageable and maintainable

For an overview of the changes in terminology from ISAM to eSAM, please see Glossary, SLM Agreements.

3.5.2.2.1 Multi-level Agreement Structure

The eSAM provides for a multi-level agreement structure. In the simplest terms, such a structure is typically^{footnote 5[5]} described as follows:

• A corporate-level SLA describing default service levels provided all customers within an organization
• A client-specific SLA addressing service level requirements and issues particular to one customer group
• A service--specific SLA describing service levels provided for a particular service (or services) and covering issues particular to the service(s) as provided to a customer group

Most Service Level Agreements in the OPS are written within the context of other existing agreements - or the “multi-level agreement” structure. By way of example, for the majority of IT service support and maintenance work covering the application solutions and infrastructure across the OPS, default service levels are provided to all customers (whether explicitly documented or implicitly agreed). A specific program area within a Ministry may, however, require additional or elevated support arrangements. If agreed by the IT service providers, the arrangements for exceptions to the default or standard service levels provided are documented in a separate agreement.

The agreement on exceptional arrangements for a program area may refer to the provisions covered in the corporate-level agreement to achieve efficiency and reduce the need to repeat the same information across multiple SLAs. This helps service agreements remain useful for business customers and helps maintain a sustainable Service Level Management practice.

The following table lists the types of formal documentation in the eSAM as they relate to the types of service described above in the Service Information Schema (Figure 2).

The diagram below (Figure 4) provides a visual representation of how the eSAM documents may be deployed in a multi-level SLA structure for a Ministry.

Image

Figure 4 How the eSAM documents may be deployed in a multi-level SLA structure for a Ministry.

Accessible Description of figure 4
A hierarchal tree of connected boxes divided into three main levels.

• The topmost level is titled: "Executive Summary of Client or Service-specific SLA and Enterprise SLA," containing one box at the top. It says, "Primary SLA for Ministry ‘A'".
• Continuing downward, the second level is titled "Detailed Client-specific SLA, Service-specific SLA, and Enterprise SLA". Three separate boxes contain these SLA titles and are connected separately to the box on the first level above.
• The third level below is titled "Supporting OLAs for customer-facing commitments." On this level there are 6 boxes. Boxes 1 and 2 are titled "Cluster OLA" and box 3 is "Enterprise OLA"; all three are separately connected to "Client specific SLA" above. Box 4 is titled "Service OLA 1" and box 5 is titled "Service OLA 2" and both are connected to "Service specific SLA" above. Box 6 is titled "Enterprise OLA" and is connected to "Enterprise SLA" above.

3.5.2.3 Content of Agreements

The success of any agreement within the OPS depends on its usefulness to the executives and management who require an accurate summary of an IT service provider’s commitments. The usefulness of an agreement document will be determined largely by how clearly, efficiently, and meaningfully IT presents the essential information relating to service level commitments by the IT provider.

Failed service level agreements are often burdened with a tremendous amount of either technical or business-related information that is ostensibly intended to educate or inform one party or another, or which is used as a defensive or protective measure.

3.5.2.3.1 Role of the Service Catalogue

It is important to state the point clearly: The content of a service level agreement document is not provided in isolation but, rather, within the context of the broader documentation of the service and related IT components (the Service Information System).

There is crucial information documented for the IT services and IT components that Ministries rely upon to help operate their processes, programs, and lines of business. That documentation provides information that is important to the understanding of how a service or solution is designed and implemented for each Ministry’s.

To try to limit the size of service level agreements and improve their usefulness, in keeping with the Service Agreement Principles, some detailed service specifications and other information must be made available in the Service Catalogue or other acceptable, agreed vehicle. Such detailed specifications and information may include:

• Information from process standards that underpin service levels and other agreement provisions
• SLM process methods, procedures, and information that form the framework for the agreement document Service-specific or process-specific roles and responsibilities
• Limits or detailed definitions of service availability considerations
• Service-specific or application-specific performance specifications
• Business-specific capacity considerations
• Detailed provisions related to security requirements
• Standards and/or other documentation that set out system and service continuity provisions
• Standards and/or other documentation that set out the frameworks or requirements for regulatory compliance and which address regulatory issues
• Constraints and specifications around usage and demand of a service, application, or system
• Details of financial arrangements and stipulations
• Broad governance frameworks, organizational accountabilities and responsibilities within a relationship at an organizational level

To achieve adequate clarity, deliver required details efficiently, and convey meaningful information, the language of an agreement document must reflect the audience it addresses. The content of an agreement must strike a balance between breadth and brevity, between detail and digestibility.

To support achieving such a balance and creating successful agreements, content requirements for agreements are provided, below, based on the Service Agreement Principles discussed in section 3 Service Agreement Principles.

3.5.2.4 Content Requirements by Agreement

• The agreement supports effective, open, regular communications between or among the Parties
• Service Agreement Principles 2 and 3 are adhered to
• Expectations for service delivery and support are clearly understood by all Parties to the agreement
• Optimal coverage of the issues, questions, and provisions that typically need to be explicitly addressed in service agreements

3.5.2.4.1 Service Level Agreement Contents

Service Level Agreements (capitalized here to signify the specific type of agreement) are intended for consumption by a business audience. These are ministry-facing service agreements and therefore must avoid assuming a technical, IT-centric perspective and must remain focused narrowly on service level commitments, key specifications, and related functions.

Service Level Agreement documents often follow on the outputs from other Service Design processes such as the Service Design Package (SDP), the Service Level Requirements document or portion of the SDP, and others.

Multi-level Agreement Structure - In deciding what contents to include and the extent of the detail to be provided in a Service Level Agreement, it is crucial to be sensitive and respond to the specific scenario or to the needs of the particular customer for whom the Agreement is being written.

In a multi-level agreement structure (described above in Section 7.2.2.1) not all content listed below will be appropriate to include, in full, in all agreements. It is important, however, to make explicit what information is excluded from the agreement at hand and where that information is covered; that is, in what other part of the multi-level agreement structure, or broader Service Information System, can the customer find the excluded information.

3.5.2.4.1.1 Contents for an SLA

3.5.2.4.2 Operational Level Agreement Contents

Operational Level Agreements (OLAs) are intended for consumption by IT service providers in the same organization. An OLA can help align a service delivery chain to deliver an IT service that the business values.

SLA commitments presented to a customer must be underpinned by the supporting commitments in one or more OLAs to ensure that the SLA targets are not breached due to a failure in a part of the support chain. OLAs provide a compelling list of benefits for an organization:

• OLAs with targets that underpin customer commitments increase the likelihood of meeting customer SLAs
• OLAs help increase the consistency and repeatability of service delivery and is an important part of ensuring service availability, reliability, and continuity
• OLAs help assure each “silo” in a large, expansive I&IT organization what expectations of other silos are reasonable
• OLAs help clarify for solution and service designer and for relationship managers what service levels are reasonable
• OLAs provide a means for measuring the parts of a service delivery chain or service partnership to identify areas of success and of opportunity
• OLAs provide input to Continual Improvement (CI) activities and generate valuable information to support performance reviews, SLA reviews, and service planning.

3.5.2.4.2.1 Contents for an OLA

3.5.2.5 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 2, below.

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

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 3, below.

Table 3 Accepted and Negotiated Pending Status Reasons

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.

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.

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.

5.1 Standards Lifecycle Management

5.1.1 Contact Information

5.1.1.1 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 Executive (SMX) Council

5.1.1.2 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): Infrastructure Technology Services Division

5.1.1.3 Support Role Definition

The support role is the individual(s) to whom the responsibility for 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 Public and Business Service Delivery
Division: Infrastructure Technology Services
Branch: Service Planning, Design and Transition Branch
Section: Service Level Management

Job Title: Manager, Service Level Manager
Paul Golden (editor)
Phone: (647) 297-2370
Email: paul.golden@ontario.ca

Job Title: Enterprise Practice Lead

Tim LeBlanc (author)
Phone: (519) 820-9162
Email: tim.leblanc@ontario.ca

The above individuals 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).

6. Roles and responsibilities

6.1 Process Roles and Responsibilities

For the Enterprise Service Level Management Process, the primary roles include:

• Service Level Management Process Owner
• Service Level Manager
• Service Level Management Coordinator
• Service Level Analyst
• Service Owner
• Service Delivery Manager
• Service Delivery Lead
• Customer Relationship Manager (CRM)
• Customer
• Business Relationship Manager (BRM)
• Service Portfolio Manager (SPM)

The following roles and responsibilities are detailed as IT relates directly to the eSLM process.

6.1.1 Service Level Management Process Owner

The Process Owner owns the process and the supporting documentation for the process, provides process leadership and ensures that the process is followed by the organization. The Process Owner is accountable for defining the strategic goals for the process and allocating all required process resources.
When the process isn't being followed or isn't working well, the Process Owner is accountable for identifying why and ensuring that required actions are taken to correct the situation. In addition, the Process Owner is responsible for the approval of all proposed changes to the process, and development of process improvement plans.
Accountabilities and responsibilities include:

• Ensuring that the process is defined, documented, maintained, and communicated
• Reviewing effectiveness and efficiency of the Enterprise Service Level Management process and accountable for process improvement
• Accountable for the success or failure of the process
• Defining and developing Enterprise Service Level Management process common metrics and reporting requirements
• Ensuring Enterprise Service Level Management processes and tools integrate with other processes
• Ensuring organizational adherence to the process
• Ensuring adequate process training is available for the organization
• Managing changes to the process within a defined governance framework
• Ensuring effective linkages between the Enterprise Service Level Management Process and other Enterprise Service Management processes, Cluster, Corporate, and other Service Provider processes
• Documenting and publicizing the process
• Defining appropriate policies and standards to be employed throughout the process
• Defining Key Performance Indicators (KPIs) to evaluate the effectiveness and efficiency of the process and designing reporting specifications
• Ensuring that high-quality reports are produced, distributed, and utilized
• Periodically auditing the process to ensure compliance to policy and standards
• Reviewing opportunities for process enhancements and for improving the efficiency and effectiveness of the process
• Ensuring that the process, roles, responsibilities, and documentation are regularly reviewed and audited
• Providing input to the on-going service improvement plans/programs
• Reviewing integration issues between the various processes
• Attending executive-level Enterprise Service Level Management meetings to assess and represent the service level requirements balanced with the relative cost
• Attending Enterprise Service Level Management meetings to fully understand service level requirements and functions as a point of escalation when required

6.1.2 Service Level Manager

The Service Level Manager is accountable to the Service Level Management Process Owner and performs the day-to-day operational and managerial tasks demanded by the process activities.
The Service Level Manager is primarily responsible for the overall effectiveness, measurement, and performance reporting of the Enterprise Service Level Management Process.
Accountabilities and responsibilities include:

• Negotiating service agreements and ensuring that these are met
• Making sure that all IT service level agreements, operational level agreements, and underpinning contracts are appropriate for the agreed service level targets
• Working with the Service Owner(s) to identify service level requirements through discussion with the business users
• Designing, maintaining, and reviewing the structure for the process that covers the interactions of the people involved and the expected content of Enterprise Service Level Management related documents (involving IT and Customers)
• Coordinating any required service improvement plans/programs to correct service performance issues and concerns
• Coordinating process reviews utilizing independent parties to provide an objective view on the simplicity of the process and areas for improvement
• Forecasting future service level requirements based on business plans, usage trends and sizing of new services
• Creating, maintaining, and regularly reviewing the service agreements in line with the organization’s business planning cycle, identifying current service usage and forecasting requirements during the period covered by the operational plan
• Analyzing performance data and reports on performance against targets contained in service agreements
• Raising awareness of potential performance threshold breaches and assisting with the investigation and diagnosis of service level-related Incidents and Problems
• Reporting on service performance against targets contained in service agreements
• Making available relevant, concise reports that are both timely and readable for Customers and IT Service Providers
• Determining performance service levels that are maintainable and cost justified
• Acting as a focal point for all service level and performance issues
• Reviewing whether all parties involved are familiar with and following the process, including external suppliers (contractors and vendors). If deficiencies are discovered, initiating appropriate action to ensure that the process is followed
• Ensuring and promoting the correct use of the Enterprise Service Level Management process
• Promoting and communicating the process to all parties involved
• Providing Enterprise Service Level Management process staff with appropriate information to enable them to perform their function effectively

6.1.3 Service Level Management Coordinator

There may be multiple eSLM Process Coordinators but only a single eSLM Process Manager. The eSLM Process Coordinator is primarily responsible for the day-to-day execution of the Enterprise SLM process and provides detailed process leadership for his or her portfolio.
Accountabilities and responsibilities include:

• Negotiating service agreements and ensuring that these are met
• Ensuring that all service agreements include SMART targets agreed to by business and IT
• Monitoring and reporting on service levels and process health
• Initiating any actions required to maintain or improve service levels
• Implementing and managing the ongoing, day-to-day execution of the eSLM process
• First line of support for process-related escalations
• Attending the periodically scheduled performance review meetings with Service Owners (or their delegates) and with Service Customers
• Supporting other process roles in the documentation of periodic performance review meetings
• Ensuring that documentation and records are managed in accordance with any internal audit requirements
• Reviewing, analyzing, providing and updating Enterprise SLM Reports, service improvement plans, and Continual Improvement (CI) Opportunities
• Monitoring process adherence to ensure the quality of management information is maintained at the highest level
• Providing guidance, support, and expertise for people utilizing the process
• Expert knowledge of the process workflow and process CSF’s/KPI's
• Supporting the Service Level Manager in planning, updating, and documenting process activities, including roles and responsibilities, process flows, procedures, and reporting
• Identifying opportunities for process improvements

6.1.4 Service Level Analyst

Service Level Management Analysts are the line staff members who are the subject matter experts for documenting and monitoring service agreements for their functional organization.
Accountabilities and responsibilities include:

• Assisting with negotiation, agreement, and maintenance of SLAs in conjunction with Service Owners and Service Level Manager
• Identifying service requirements for OLAs
• Ensuring appropriate OLAs/SLAs in place to support any new services
• Reviewing SLA targets and metrics where necessary
• Reviewing OLA targets and metrics where necessary
• Reviewing third party underpinning contracts where necessary
• Agreeing to appropriate actions to maintain or improve service levels
• Coordinating actions required to maintain or improve service levels
• Acting as a coordination point for any temporary changes to service levels when needed.
• Analyzing Service level requirements for a specific service and develops the service level agreements, operational level agreements and Underpinning Contracts to support a specific service
• Identifying opportunities for improvement
• Proactively providing the Service Level Management Process Manager with information when systems unexpectedly deviate from forecasted utilization
• Escalating to the Service Level Management Process Manager, if required

6.1.5 Service Owner

The Service Owner is typically an executive-level role that is responsible and accountable for delivery of a specific IT service.
Accountabilities and responsibilities include:

• Responsible for delivering a particular service
• Acting as the counterpart of the Service Level Manager when negotiating service level agreements and operational level agreements
• Ensuring that eSLM is kept up to date with regards to contacts and responsibilities under the responsibility of the Service Owner.
• Often, the Service Owner will lead a team of technical specialists, or an internal support unit required to:
• Monitor service performance  
• Take action to prevent service target breaches
• Implement continual improvements to the service
• Monitor service performance
• Take action to prevent service target breaches
• Implement continual improvements to the service
• Responsible for providing the strategy for how individual technical service commitments will be delivered within the Organization in relation to Service Models and operational level agreements.
• Responding to issues and service requests from the IT Organization
• Providing input to the Service Catalogue
• Providing input into service level agreements and operational level agreements that represent the services being delivered
• Coordinating service delivery activities within the organization(s) they represent
• Establishing the boundaries and strategy for how services will be delivered to internal and external customers
• Ensuring periodic reviews of service reports and operational activities
• Coordinating actions to ensure appropriate resources and capacity are established to make sure services can be delivered to meet service commitments
• Accountable for the prevention of occurrence and recurrence of breaches of agreed Service levels
• Identifying opportunities for improvement

6.1.6 Service Delivery Manager

A manager who is responsible for managing the lifecycle and operations of one or more supporting technical service. This role ensures compliance with service level targets for the Service within the OPS.
The term Service Delivery Manager, sometimes also referred to as Service manager, is also used to mean any manager within the service delivery chain, often a senior manager with responsibility for Services overall within the service portfolio of a Service Owner.
Accountabilities and responsibilities include:

• Acting as the counterpart of the eSLM Process Manager when negotiating operational level agreements.
• Leading a team of technical specialists or an internal support unit required to
• Monitor service performance
• Take action to prevent service target breaches
• Implement continual improvements to the service
• Ensuring that eSLM Reports are reviewed in a timely manner to both proactively and reactively manage Service performance.
• Ensuring that eSLM is kept up to date with regards to contacts and responsibilities under the responsibility of the Service Delivery Manager.
• Ensuring that all Service Improvement Plans (SIPs) are documented, reviewed for successful results, and managed through to completion.
• Ensuring that they or a member of their team attends and provides assistance and input to the scheduled meetings with eSLM.
• Preventing the occurrence and recurrence of breaches of agreed Service levels
• Identifying opportunities for improvement

6.1.7 Service Delivery Lead

A manager, team lead, or supervisor who is responsible for the day-to-day delivery of service to meet or exceed agreed service levels.
Accountabilities and responsibilities include:

• Attending periodic performance review meetings
• Monitoring work assignment and work completion against service level targets to ensure resource allocation is done in line with the business’s priorities
• Responding to notifications regarding risks to service agreement compliance in order to prevent breach of service commitments
• Providing detailed input relevant to service operations’ impact on periodic performance results in support of service performance reporting
• Providing detailed input regarding the strengths and weaknesses in service operations to support identifying service improvement opportunities

6.1.8 Customer Relationship Manager (CRM)

The Customer Relationship Manager may also be referred to as Client Engagement Manager/Lead and is the single point of contact and liaison between IT and Business Customers. They are responsible for ensuring that a consistent and cohesive approach to handling all requirements, requests, issues and escalations is provided to the business in a timely and organized fashion.
Accountabilities and responsibilities include:

• Reviewing service management reports, understands issues and current status/level of performance
• Setting up, coordinating and formally documenting meetings with Business to discuss eSLM Performance Reports on a regularly scheduled basis
• Providing explanations for breached service targets, and details/updates of related Service Improvement Plans
• Participating in establishment of new projects, service requirements and service agreements.
• Handling issues and escalations.
• Working with the Business and IT as necessary, on continual improvements.

6.1.9 Customer (Business Units)

The Customer of an IT Service Provider is the person or group who defines and agrees to the service targets, signs the Service Level Agreement and pays for the service. This is the line of business responsible for budgets and costs related to a specific service.
Accountabilities and responsibilities include:

• Providing a clear description of the new or changes to service requirements business needs, benefits, impact, schedule, and cost to the business.
• Following the Service Management Processes for submitting the request
• Working with the BRM’s / Client Engagement to determine the viability of the new or changes to service, sizing of the resources required and compatibility with current IT environment.
• Responsible for the negotiating service level agreements with the Service Level Manager and IT Service Providers.
• Responsible for the fact that the defined Service Levels are sufficient for the fulfillment of business objectives, and that the charges estimated for this purpose are justified from the Business perspective

6.1.10 Business Relationship Manager (BRM)

Technical groups providing advice and consulting support to business units, analyzing initiatives, and translating them into business requirements and solutions to be fulfilled by the IT Service Providers. These groups act as a liaison point between IT and the Business.
Accountabilities and responsibilities include:

• Taking ownership of a particular solution offering
• Developing and executing a solution strategy and business plan that supports customer needs
• Shaping, designing, and planning specific solutions supporting services strategy
• Acting as visionary and strategist for customer solutions
• Surveying market landscape for solution insights, direction, vendors, and methods
• Providing expertise to identify and translate customer business requirements into IT solutions.
• Building and maintaining a repository for deliverables, methodologies, and business solutions documents
• Interfacing and coordinating tasks with internal and external technical resources.
• Collaborating with Project Managers and technical directors to provision estimates, develop overall implementation solution plan, and serve lead as required, to implement installation, customization, and integration efforts
• Overseeing aspects of project life cycle, from initial kickoff through requirements analysis, design, and implementation phases for projects within solution area
• Providing quality assurance for services within solution area

6.1.11 Service Portfolio Manager (SPM)

Service Portfolio Managers are responsible for understanding client needs and requirements in order to ensure that IT services are planned, defined, documented, implemented with minimal impact to the client, managed and reported on, once in production, so any issues/escalations can be addressed according to established service agreements.
Accountabilities and responsibilities include:

• Acting as a liaison point between IT and the Business
• Acting as a point of contact when planning for the implementation of enterprise services, working with Business Relationship Managers (BRMs), internal service delivery partners like: Infrastructure Technology Services (ITS); Corporate Security; Common Components, Applications and Services (CCAS); and other OPS Clusters/organizations as well as external vendors

6.2 Process Workflows

An overview of the stages of SLM’s workflow is provided below, followed by details of each stage.

6.2.1 Overview of Enterprise SLM Workflow

Service Level Management High-level Process Activities: Accessible Descriptions

6.2.2 1.0 Requirements Identification

Identification of Service Level Requirements Activities: Accessible Descriptions

6.2.3 2.0 Design Coordination External

Design Coordination Activities: Accessible Descriptions

6.2.4 3.0 Transition

Service Transition Activities: Accessible Descriptions

6.2.5 4.0 Operations

Service Operational Activities: Accessible Descriptions

6.2.6 5.1 – 5.2 Continual Improvement – End-to-end Report and ISPs

Continual Improvement – End-to-end Report and ISPs: Accessible Descriptions

6.2.7 5.3 – 5.4 Continual Improvement – Register and SLA

Continual Improvement – Register and SLA: Accessible Descriptions

6.2.8 5.5 CI – Framework

CI – Framework: Accessible Descriptions

7. Consultations

Areas consulted as part of the development of this standard. Include individuals and committees, councils and/or working groups:

8. Document history

Standard Type: Process Standard (IT Service Management Process)

9. Glossary

10. Appendices

10.1 Normative references

Governance and Management of Information Technology Directive:

https://intra.ontario.ca/tbs/governance-and-management-of-information-technology-directive

GO IT Standards:

https://www.ontario.ca/page/information-technology-standards

Office of Government Commerce in the United Kingdom

ITIL books/content:

• ITIL Service Design Version 3, 2007
• ITIL Service Design 2nd ed., 2011
• ITIL 4 Drive Stakeholder Value, Service Management Practices

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.

10.2 Informative references

On Service Level Agreement structures, see:

• https://www.simplilearn.com/designing-sla-structures-sla-content-article
• https://en.wikibooks.org/wiki/ITIL_v3_(Information_Technology_Infrastructure_Library)/Service_Design

On the Business Service Management Model, see for example:

• BMC Inc., published on Fusion UK (originally at www.fusion.co.uk/businessservicemanagement.html; archived to https://web.archive.org/web/20160722155938/http:/www.fusion.co.uk/businessservicemanagement.html)
• Business service management 101: Manage IT with a business focus, IBM Corporation Software Group, January 2012
• Business Service Management Links IT Services to Business Goals, CA SOLUTIONS MARKETING, White Paper by Sarah Meyer, January 2008

On IT Service Management and Service Level Management concepts, practices, principles, and practicalities, see for example:

• “The Rise of Service Level Management”, Pink Elephant White Paper, by Gary Case
• Principal Consultant, February 2010
• “A Simple Framework to Translate IT Benefits Into Business Value Impact”, Gartner, May 2008
• “ITIL V3 Concepts Made Easy Part 1 - Utility and Warranty”, Pink Elephant, By Pierre Bernard, May 2008
• “Anatomy of a Service White Paper, Pink Elephant”, version 1.3, by Jack Probst, , September 2009
• “Defining IT Success Through The Service Catalog”, Cisco, by Troy DuMoulin, Rodrigo Flores and Bill Fine, 2011
• “Maturing IT Services to Deliver Business Value”, Gartner CIO & IT Executive Summit, Suzanne Adnams presentation at Toronto, June 2016
• “Service Modeling Best Practices White Paper v1_0”, BMC Software, September 2005

Note: an informative reference is not normative; rather, IT provides only additional background information.