The Strategy for Service Delivery

David Anthony

IT Services

Loughborough University

June 2015

Revision History Date Notes Issued By 26/6/15 Initial Draft David Anthony 31/7/15 Minor alteration from SLT David Anthony 22/10/15 Minor corrections David Anthony

Contents Glossary ..................................................................................................................... 5

Introduction ................................................................................................................ 7

Audience ................................................................................................................. 8

Scope ..................................................................................................................... 8

Principles ................................................................................................................ 8

Objectives ............................................................................................................... 9

How We Choose the Services Should We Provide .................................................. 11

Initiation ................................................................................................................ 12

Definition ............................................................................................................... 12

Analysis ................................................................................................................ 12

Approval ............................................................................................................... 12

Chartering ............................................................................................................. 12

How We Design Our Services .................................................................................. 13

Agreeing Service Levels ....................................................................................... 14

Planning for Capacity ............................................................................................ 14

Warranty and Utility .............................................................................................. 14

How We Build and Deliver Our Services .................................................................. 15

Managing the Change .......................................................................................... 15

Validation and Testing .......................................................................................... 15

Capturing Knowledge ........................................................................................... 15

Delivering to Operation ......................................................................................... 16

How We Run Our Services ...................................................................................... 17

Service Desk ........................................................................................................ 17

IT Operations Management .................................................................................. 18

Managing Underlying Issues ................................................................................ 18

How We Maintain and Improve Our Services ........................................................... 19

Monitoring Performance ....................................................................................... 19

Letting the customer lead ..................................................................................... 19

Letting IT lead ....................................................................................................... 19

Accountability throughout the lifecycle .................................................................. 19

Improvement Plans and Roadmaps...................................................................... 20

Roles and Responsibilities ....................................................................................... 21

Process Owner ..................................................................................................... 21

Process Manager.................................................................................................. 21

Process Practitioner .............................................................................................. 22

Service Owner ...................................................................................................... 22

Infrastructure Service Owner ............................................................................ 22

IT Service Owner .............................................................................................. 23

Standards for Documentation ................................................................................... 25

Introduction ........................................................................................................... 25

Process and Policy Descriptions........................................................................... 25

Policy Description .............................................................................................. 25

Process Description .......................................................................................... 25

Introductory Guides .............................................................................................. 26

Additional Artefacts ............................................................................................... 26

Assessing and Baselining our Service Management Maturity .................................. 27

Assessing the environment ................................................................................... 27

Assessing the Processes ...................................................................................... 28

Appendix A – Process Ownership and Mapping ...................................................... 29

Fitting Processes to the Lifecycle ......................................................................... 29

Process Owners ................................................................................................... 30

Appendix B – The Service Lifecycle ......................................................................... 31

Appendix C – Communication Style ......................................................................... 32

Process Icons ....................................................................................................... 33

Glossary A more expansive glossary can be found at: https://www.axelos.com/Corporate/media/Files/Glossaries/ITIL_2011_Glossary_GB-v1-0.pdf

Accountable – Ownership of a process, and/or activity. This refers to the sole person who is held accountable and ensures that the goals and objectives of a process are being followed.

Business Facing IT Service – A service that is directly advertised to and managed on behalf of users and customers

Customer – The person from the business who requested the service and who is accountable for the business case for the service (also likely to be the project executive for any related project)

Incident – The unexpected interruption or reduction in the quality of a service to the end user

Major Incident – An incident that has or has the potential to cause significant disruption to the business

Normal Service Operation – The desired operational state of a service

Pattern of Business Activity – A profile of the demands a specific set of users will place on a service over a period of time (e.g., an academic year)

Problem – The underlying cause of one or more incidents which may be fully repaired asynchronously to the incidents

RACI Chart – A matrix chart that maps service roles with four categories (Responsibility, Accountability, Consulted, Informed) in order to document service responsibilities

Request – See Service Request

Responsible – Performer of a task. This refers to the person responsible for getting the task/activity done, but does not necessarily have the authority to ensure that others are getting their tasks completed.

Service – The aggregate means by which we deliver value to the business by facilitating their desired outcomes

Service Catalogue – The catalogue of live services, divided into those that are business facing IT services and those that are underpinning technical services

Service Level Agreement – An agreement with the customer as to the expected performance, capacity and availability of a service, and the means and frequency at which this will be measured

Service Package – A offering within a service that provides a specific value proposition, or is aimed at a specific segment of the users of that service

Service Portfolio – The complete list of services, regardless of their lifecycle status, including those that have been retired

Service Request – An element of a service that it has been agreed can be requested directly by users, such as a password reset or a new computer

Service Transition – A lifecycle phase that converts the service design into an operational service whilst ensuring the business value of the chartered service remains in line with that which was agreed

Stakeholder – Users, customers, IT Staff and any other people who impact upon, or are impacted upon by a service

Technical Service – A service that provides key functionality to an IT service, but which the users and customers can not directly request or influence

User – The people from the business who will use the service when it is delivered, and who may be involved during the requirements capture and testing of service delivery

Utility – The extent to which a service does what was requested by the customer (fitness for purpose)

Warranty – The extent to which a service can be accessed, used and has the performance required by the customer (fitness for use)

Work Around – A temporary resolution to an incident that removes the interruption to a service, but will itself be removed when the underlying problem is resolved

Introduction

“The primary objective of Service Management is to ensure that the IT services are aligned to the business

needs and actively support them. It is imperative that the IT services underpin the business processes, but it is also

increasingly important that IT acts as an agent for change to facilitate business transformation.”

ITIL Service Delivery, OGC, 2007

The overarching aim of IT Service Management at Loughborough is to ensure that all our users have the right services for the work they are undertaking, and that these services are delivered, supported, measured, monitored and reviewed to ensure that they remain fit for purpose and fit for use.

The increasing demands from our users, coupled with the complexity of IT systems means that moving forward without coherent management processes in place presents a significant risk. Examples include the de-confliction of changes to our services that are interdependent, the management of underlying issues that affect multiple users and our ability to capture user requirements and present a simple business-focussed catalogue of our services.

Aside from the user’s experience of our services, we also risk damaging our own ability to deliver services and our reputation if we are not able to manage, monitor, support and enhance the services we provide.

We are now at a juncture where the introduction and improvement of our management processes will be key to preventing future significant IT disruptions, or failures to meet the requirements of our customers.

This document provides the strategic basis for our adoption of Service Management. It will provide details of our principles of operation, integration with other processes, standards for Service Management documentation, and the process by which we introduce and improve these processes.

This document does not detail the processes or policies in place, but instead provides the framework for their creation and adoption, and sets the overall context for our service focus going forward.

IT at Loughborough will be delivered via a coherent set of service management principles and processes that will be chosen, implemented and maintained in line with both the needs of the customer and the needs of the IT professionals they support.

To ensure that service management at Loughborough is supportable and extensible, the framework set out in ITIL v3 2011 will be used, and an approach of adoption and adaption will ensure that those parts of the framework most relevant to the institution are implemented.

This strategy will not align to the existing structure of IT provision within the University, not least as this strategy extends across the whole body of IT Professionals within the institution rather than just the IT Services department. Roles and responsibilities are outlined elsewhere in this document; however these assignments cross existing functional boundaries.

Audience The audience for this document is all staff within the institution who are involved in the design, transition and operation of IT. This will include IT Services staff, IT professionals in departments and other people involved in the delivery of IT. This document is of particular relevance for any individual who is responsible for any Service Management process, as it details your accountabilities.

More widely, this document may also be useful for staff outside of IT Services who have an interest in understanding the basis upon which we manage our services.

Scope This document covers the approach to selecting, designing, transitioning, operating and improving the services provided to end users.

Explicitly excluded from the scope of this document are:

• Project, programme and portfolio management • Technical elements of systems development, and associated methodologies

Principles Our key principles for the introduction of Service Management are:

• We will use one coherent set of processes which will be adopted or adapted from the ITIL v3 2011 framework

• All staff who manage IT across the University will use these processes, regardless of organisational boundaries

• Services will be managed from inception to final decommissioning via this approach, in concert with other frameworks where appropriate

Adherence to these principles is required to prevent services being disjointed, or appearing fragmented to end users. This is key to end user experience of our services, and is fundamental to why this document is targeted at all IT staff across the institution.

In documenting the requirement that all IT staff use these processes and abide by these principles, this document re-confirms that all stakeholders in the University-

wide IT Community will be provided with a common understanding, and appropriate training and access to undertake their roles.

Our customers and users will interact with IT primarily via three functions throughout the service lifecycle. Whilst these functions are managed by distinct teams within the IT Services department, all IT staff have a role to play in each function, and will work with the relevant teams to ensure these functions are fulfilled appropriately. The functions are:

• Engaging with our customers This function will ensure that IT and our customers share a common understanding of the prevalent business needs, the University’s calendar of events and the overarching issues our customers have with our current services. This function will create and liaise via service management groups of key stakeholders, and via other more direct fora.

• Supporting our users This function will act as the focal point for support for and routine requests of our services. The function will receive information about the current status of our services, known issues with our services and established ‘work-arounds’ for those known issues. This function will communicate directly with individual users via telephone, e-mail and other methods.

• Informing our users and customers This function will ensure that our users are fully aware of the services we provide, upcoming changes to our services, and significant issues with our services. The function will understand the distinct groups of users across the University, and will create, manage and co-ordinate a number of communications channels to communicate with each group.

Objectives The key objective of Service management is that our services shall be managed throughout their lifecycle, which can be broadly considered as consisting of four phases, plus an overarching continual improvement cycle.

The four lifecycle phases are: Service Strategy, Service Design, Service Transition and Service Operation. These phases are detailed further in Appendix A, and help guide us through the various elements of Service Delivery.

The lifecycle phases can be further subdivided into 26 processes, of which 12 are relevant to the strategy as detailed. These are:

• Demand Management • Service Portfolio Management

• Business Relationship Management

• Service Level Management • Availability Management • Capacity Management • Change Management • Knowledge Management

• Incident Management • Problem Management • Request Fulfilment • Service Catalogue Management

Additionally, Major Incident Management will be treated as a separate process.

As these processes are interdependent, it is important to set out priorities for their development that provide a solid basis for the others to build upon. In keeping with a keen customer focus, it is important to seek to build and improve process that will have the most positive impact on their experience of our services. It is with that in mind that the initial focus will be upon the Incident, Major Incident, Problem, Change and Service Catalogue Management processes.

This first set of processes will be developed and implemented through to the end of 2015, after which a brief review of progress and the development of a service management toolset strategy will help set the focus for 2016. This strategy aims to have all the listed processes in place by the end of 2017, with emphasis then moving to continual improvement of the processes.

During the remainder of 2016, the processes outside the initial focus may progress to some extent, where and when their owners are in a position to develop them. This will be especially important where they can start to contribute to a more positive user experience, or help support our effectiveness internally.

How We Choose the Services Should We Provide

Ultimately the services we provide will be driven by the needs of our customers across the institute and our tenant users. Project and Portfolio Management, which is outside the scope of this strategy, will ensure that the objectives of IT Services align with the objectives of the University, whilst the Demand and Service Portfolio Management processes within this strategy will be key interfaces to this.

Service Portfolio Management ensures that we manage the pipeline of new, changed and retired services. It is also at this stage in a services’ lifecycle that financial and strategic decisions are made.

The Service Portfolio continuum defines five stages that are undertaken in order for work to start on new or significantly changed services, which are Initiate, Define, Analyse, Approve and Charter. The following diagram details the interaction between these stages, and their products.

Initiation

Definition

Analysis

Approval

Chartering

- Business Case

- Value Proposition- Priority

- Service Portfolio- Authorisation

- Communication- Resource Commitment

Service Management Groups Other Committees Senior Stakeholders Internal Strategy

The Head of Service Delivery and Project and Portfolio Manager are jointly responsible for ensuring that the ITPRT and other internal processes and committees follow a form of Service Portfolio Management that ensures clean and

well defined demand transits the system, and that the key phases and deliverables of both project process and service process are created.

Initiation The demand from across the University will emanate from a number of directions, including Service Management Groups and other committees, as well as commentary from senior stakeholders in other fora. Additionally IT Services will need on occasion to refresh its core services for purposes of age or the management of underlying risk. Demand will be broadly grouped into two categories: 1) new or significant service changes or; 2) Continual Service Improvement. Only that demand which falls in to the first category is handled through these processes, whilst the demand which falls in the latter category is dealt with later in this document.

Definition After categorisation at initiation stage, demand will then undergo a process of definition to provide an outline business case. This case is again aligned to the business case required for project process purposes, and will remain a ‘living document’ that continues to provide the case for a service throughout its lifecycle. This document will also capture information about the customers, the proposed service model and the impact on the service portfolio (e.g., the retirement of other services).

Analysis With a business case in place, further detailed analysis will provide full value analysis document with details of the financial elements of the proposed service throughout its lifecycle. The key product from this stage should be an updated business case with a detailed value proposition. Additionally any ‘Patterns of Business Activity’ will be documented to describe the key periods that the service will be used. At this stage a prioritisation will also be given against the overarching strategic aims of the University to ensure that resources are used as efficiently as possible.

Approval At this stage the service approval is either agreed as feasible, or declined. The change management process is initiated with an aim on managing the overall transition of the service and any other Service Portfolio changes that are required.

Chartering This is point where the work to create a new or substantially changed service starts. A Service Charter is produced, which is a document that is aligned to, and may be combined with a project PID. This document provides a service-centric view of the project deliverables, required resources and the initial schedule. This document acts as the initiation for Service Design activities and in keeping with the PID should be agreed by the Project Executive. It is also the start of the Change Management and communications processes.

How We Design Our Services

The design of our services will be aligned to and derived from the requirements agreed with our customers as part of the Service Portfolio Process detailed previously in this document. With an approved Service Charter, we will embark on a Service Design exercise that meets the exacting standards agreed in the charter. This phase’s products are agreed within the Service Management Framework, but are delivered via project processes outside the scope of this document.

Ultimately the phase Service Design is based around describing the infrastructure, applications, information and people needed for the service to be successful throughout its lifecycle, and then describing the acquisition, management and integration of these resources. This phase is construed broadly; defining technology architectures, dealing with suppliers and undertaking security related work all take place within this phase. In general terms, a top down approach will be taken to designing our services:

Business Requirements

People, Roles and Activities

Processes and Procedures

Management Tools

Technology

In these respects Service Design is a significantly different from the technical design of systems. Whilst the technical design is a product of service design, this constitutes the last of a number of deliverables, the others including:

• Service Definition and Service Level documents to detail the business requirements

• Service Resourcing and Service Management documents to detail the people, roles and activities required to run the service.

• Incident Model and Service Request documents to detail the processes and procedures required to run the service

• Service Capacity and Contingency Plan documents to detail the management tools required for the service

Each of these documents looks to detail not just the build and delivery phase, but also how the service will require resource throughout its lifecycle; this is imperative for estimating and measuring the benefits of a service and its value for money.

Agreeing Service Levels Service Level Agreements are inherently complex to negotiate, especially in Higher Education; however the baselining and measuring of our services is critical to demonstrating compliance with the Utility and Warranty of our services. It is understood that setting our own minimum service levels is preferable to continuing in the absence of any service levels. However, wherever the customer is willing or able to provide Service Level Requirements, we should aim to negotiate a Service Level Agreement. The design of a service should use the agreed or minimum service level documentation in order to guide the resourcing requirements of the service; where a service is required to have a very high uptime, it will need infrastructural redundancy, where a service needs very fast incident response, it will need exceptionally well formulated support documentation.

Planning for Capacity In combination with the business customers, we need to have a clear understanding of the capacity and growth expectations for a service. This will be underpinned by a ‘Pattern of Business Activity’ document that forms part of the Service Charter.

Each Service Design will need to include a plan that describes how service capacity will be managed over time. This may include some detailed explanation of how services will be managed (e.g., how and when a user can request mode capacity), or it may take the form of a simple reactive plan and set of measures (e.g., add disk capacity when we reach >80%). However, the capacity plan must also give reference to the financial implication of growth – the overall value proposition of a service must account for capacity growth at expected growth levels throughout the expected life of the service.

Warranty and Utility Ultimately, services which we have designed fully and in keeping with the process outlined will be measured by their fitness for purpose (Utility – the functionality requested by the customer) and fitness for use (Warranty – the performance agreed in the Service Level Agreement).

In designing our services, ensuring that our work meets the Utility and Warranty that we have agreed is a shorthand method for ensuring we can meet the customer’s underpinning needs.

How We Build and Deliver Our Services

The build of our services will be derived from the information gathered and packaged during our design activities. We will build services on the basis of the agreed service levels, and to meet the agreed business requirements.

It is during this phase of our service lifecycle that undertake development activities, engage 3rd party suppliers and perform integration activities. This document does not detail the approach to these activities; however the entry and exit criteria to this phase of the service lifecycle provide bounding.

Ultimately this phase in a services’ lifecycle ensures that the transition of a service to its live environment is planned, managed and successful.

Managing the Change Having engaged with the Change Management process since chartering of the new or significantly changed service, it is throughout the build and delivery that it is important to provide thorough and frequent updates on progress. The Change Management process provides guidance, co-ordination and authorisation for the work, and ensures that the change remains beneficial to the University, and that there is minimum disruption from its introduction.

It is also during this phase that we agree the timings, the impacts and the risks of the change. We will need to continually manage the co-ordination of work across multiple changes to minimise risk from timing or resource clashes, and to execute the smoothest possible ‘go-live’ for the users.

Validation and Testing The Project Management process will define which new and changed services require which level of validation and testing, but it is the Change Management process that must accept their completion prior to authorisation for a changed or new service to go live.

In general terms, it is important that the utility and warranty expectations of the service have been tested so that the users can be sure that the functionality and performance requirements are met. It is encouraged that end users are involved in testing the service, and that other specialist testing groups (e.g., external penetration testers or load testers) are used where appropriate.

Capturing Knowledge Good service knowledge is co-created by those who design and develop services and those who operate and support services, and users derive most value from services which are well understood and supported. A key aim in managing our services is to ensure that knowledge about our services is captured, synthesised and deployed.

The knowledge we capture exists and is used within a four-phase continuum, the endpoint of which is a real and deployable wisdom about our services held by our Service Desk.

All changes to services will need to capture data and information that describes the way the service works, or what is now different. Projects will also have the delivery of these products within their plans. This will allow our Service Desk, through experience and exposure, to develop real service knowledge and eventually service wisdom to the benefit of our users.

The Service Desk will be invited, via CAB, to comment on the quality and quantity of service knowledge presented as part of any transition of a service to its live environment.

Delivering to Operation With the appropriate transition information and planning in place, and with the authorisation of CAB, a new or changed service will be able to ‘go-live’. This is a piece of work that will draw in a number of staff from across the department, many of whom will have been involved throughout the lifecycle.

It will be critical for the deployment to live to have a unified plan in place, with clear understanding of the activities to be undertaken, their timings and the responsibilities and accountabilities of the people involved.

Communications and preparation for the Service Desk are key to successful delivery of services, along with clear success criteria for the deployment. Some projects may be structured to offer a project ‘warranty’, and meeting the success criteria or successfully exiting the warranty period marks the end of the transition to live operation.

How We Run Our Services

Having accepted transition of services into the live environment, we will need to manage and run those services for the benefit of our users, and to the expectations of our customers. Users will expect that incidents that prevent or degrade their use of a service will be addresses in a timely fashion, and that recurrent underlying issues will be managed professionally and appropriately.

Users will have negotiated and agreed a series of requests that can be made of a service, and these will need to be undertaken in a timely fashion, but with clear lines of authorisation and approval.

Service Desk The Service Desk we will provide can be thought of in two differing ways:

1. A group of dedicated service support staff who act as the first point of all for our users

2. A function shared by all staff involved in the support of our services.

It is important that both definitions are given equal weighting by all IT staff. Our users must use our physical Service Desk as their first point of contact – we will provide suitable service knowledge and service status information to allow the physical Service Desk to respond to in increasing proportion of incidents and service requests without any functional escalation. However, when an incident or service request is escalated, all IT staff involved are acting as an extended virtual Service Desk. It is the responsibility of all staff to communicate with our users when dealing with support calls, and wherever possible to provide more information to the physical Service Desk to prevent escalation of similar support issues in the future.

Provided with good quality information and knowledge, the Service Desk provide users with access to two key processes, Incident Management and Request Fulfilment.

RestoreRecoverDiagnoseDetect Repair

Inci

dent

Inci

dent

Mean Time to Restore Service Mean Time Between Failure

UptimeDowntime

Mean Time Between Service Incident

Time

The overarching aim of Incident Management will be to allow the user to continue their work as quickly as possible via the restoration of service. It is acknowledged

that this may not take the form of a complete and permanent fix to the underlying issue, which may be resolved via Problem Management, but is instead focussed on minimising the time taken to restore a service and maximising the time between service interruptions. The above diagram details the key steps in the incident lifecycle.

The overarching aim of Request Fulfilment is to allow users to easily request that simple, pre-defined tasks be undertaken for them. Examples of such tasks include providing access to a piece of software, or providing of a new desk phone. Each of these requests are defined upfront as part of the service, and publicised to the user allowing them to easily take advantage of the request options available to them. The process is focussed on speedy delivery of service to users with minimal, but clearly defined barriers. Each of the pre-defined requests available for fulfilment should be assessed for self-service opportunities.

IT Operations Management Staff involved in IT Operations will ensure that the underpinnings of our services are maintained, available, and managed in keeping with capacity plans. It will be critical to ensure that the Service Desk are aware of underlying technical issues that are, or have the potential to impact live services, and to ensure that Service Desk are able to respond to support requests that may arise from such issues. Where the root cause for the issue is not immediately obvious or resolvable, it will be necessary to proactively engage the Problem Management process to track and resource the solution.

In the absence of a dedicated IT Operations team, it will be important for staff involved in functions such as systems patching, backup, monitoring and other standard operational procedures to work as a virtual team, and to co-ordinate communications to the Service Desk. The communications involved should be broad in scope (e.g., patch cycles, backup status, known faults), but should be collated and communicated in terms of services affected. It is preferable that operational issues are assessed and communicated at the start of the working day or when there is a significant change in operational status, and mechanisms to facilitate this will be put in place.

Managing Underlying Issues Each incident for which a complete and permanent fix is unavailable will give rise to the reactive raising of a Problem record. It will be particularly important to manage problems where multiple occurrences of an incident are noted, and therefore this will likely be detected by the Service Desk.

Problems, whether reactively arising from incidents or proactively arising from operations management, will be given elevated prominence and will attract resource from across teams to resolve. The Service Owner will remain accountable for the problems with their services and their resolution.

How We Maintain and Improve Our Services

Throughout their lifecycles, our services will be monitored, assessed and improved in line with changing customer needs. We will use evidence to quantify the users’ perception of our services, and will ensure that the improving external technology environment leads to positive service improvements and improved cost efficiency.

Services will be subject both to proactive and reactive review, and we will ensure both users and customers can present their opinions. We will provide roadmaps and development opportunities focussed around strong service ownership.

Monitoring Performance We will grow a strong understanding of the critical success factors users perceive for our services, and seek to find measures that adequately measure these. We will review these periodically, and seek to address significant variation prior to impact on end users. We will share this information with Service Management Groups, and present our plans to address such variation.

Letting the customer lead The customer will develop a stronger understanding of their requirements over time, and will seek to get more from the services we provide. This is a key function of service management, and the key way in which we ensure that our services continue to provide value for money.

In support of the customer’s ongoing needs from the services we provide, we will establish a Continual Service Improvement Register, and seek for Service Management Groups to add, prioritise and curate items on this register. We will seek to fairly incorporate these improvements across services, and will ensure a balance between project work and improvement work.

Letting IT lead Notwithstanding the previous section, IT staff in general, and Service Owners in particular will have specialist knowledge about technologies and services acquired through their professional understanding of the subject. The pace of technological change will mean that users don’t yet understand the ‘art of the possible’.

In such cases, IT can provide important insight and illuminate the way ahead, however the principles in this document remain; early presentation to users of new functionality will allow them to understand the ‘art of the possible’, and allow them to re-gain the initiative in improvements.

Accountability throughout the lifecycle The Service Owner remains accountable throughout the lifecycle of a service for its performance, measured both in terms of warranty and utility. However, it is clear that this cannot be the responsibility of the Service Owner alone. Each and every person

involved in IT may be called upon by a Service Owner for input into their Services, and it would be normal for this to cross organisational boundaries.

Improvement Plans and Roadmaps From an ITIL perspective, both the Deming cycle and the 7-step improvement process provide mechanisms to iteratively and continually improve our services. These cycles can be set in context against the ‘Loughborough Way’ for managing change, which has its underpinnings in the Deming cycle, whilst being focussed on larger organisational change projects. In each case the cyclical approach to improvement provides an avenue to continually improve.

Identify

Define

Gather

Process

Analyse

Present

Implement

Plan

Do

Check

Act

Deming Cycle 7-Step Improvement

Roles and Responsibilities

Process Owner The Process Owner takes ultimate accountability for a given service management process, defines what the process and describes what it should achieve. The Process Owner ensures that the process meets both internal and external stakeholder needs, promotes and champions the process, and is the ultimate reference for any queries or concerns. In keeping with the principles of continual improvement, the Process Owner is also accountable for periodic review of processes, and receiving feedback on the process.

Accountabilities and Responsibilities:

• Designs the process • Provides training for the process • Provides process documentation and example forms • Ensures the process interacts with other processes/frameworks • Ensures the value of the process • Defines the roles needed to run the process • Identifies, measures and reports on the process’s critical success factors • Advocates widely and identifies local champions for the process • Continually improves the process and communicates changes

Example

The Support Team Manager will own the Incident Management process, and will be accountable for writing the process documentation, advocate for its use and monitoring the process’s performance

Process Manager A Process Manager has responsibility for managing a given service management process on a day-to-day basis, as defined by the process owner. It is likely that there will be one Process Manager for a process, although this is not mandatory. The Process Manager will co-ordinate and manage the resources needed for a given process, and may also play a role in the operation of a process (i.e., may take part in the work rather than just managing it). The Process Manager will be the first point of escalation for processes.

Accountabilities and Responsibilities:

• Ensures the process is executed as designed • Ensures that the interaction with other processes/frameworks takes place • Provides support to Process Practitioners • Provides key performance data to the Process Owner

Example

A Senior IT Services Specialist may manage the Capacity Management process, and will ensure that the capacity of several services are monitored appropriately, that the information is fed to the process owner and the service owner, and that steps are taken by practitioners to alleviate capacity issues according to capacity plans.

Process Practitioner A Process Practitioner is the person undertaking a given service management process or task. All members of IT staff are Process Practitioners, and may undertake tasks drawn from any service management process on a day-to-day basis. Using the documentation provided by the Process Owner, and under the guidance of the Process Manager, a Process Practitioner is responsible for following a process and understanding the steps required for successful completion.

Accountabilities and Responsibilities:

• Undertakes the process • Understand the context and significance of the process • Ensure that appropriate triggers/inputs/outputs to other processes and

frameworks are observed • Maintains records and information as described in the process design

Example

An IT Service Specialist may be a Problem Process practitioner, and will be responsible for investigating, analysing, resolving and completing problems.

Service Owner A Service Owner takes overall accountability for the delivery of a given service. They are responsible for the initiation, transition and operation of a service, and are accountable to the Director of IT for the performance of the service. The Service Owner role is not a specifically hands-on role, and instead will draw on expertise from a broad range of IT professionals and suppliers to ensure that services meet their expected utility and warranty.

At Loughborough, we will sub-divide service ownership across two broad categories – an infrastructural category that includes the multitude of components needed to underpin a modern IT Service, and an IT Service category that includes the customer and user facing services that are built from the component services.

Infrastructure Service Owner An Infrastructure Service Owner will be accountable for an underpinning component that is used across one or more business-facing IT Services. This includes specific technologies (i.e., block storage, active directory, internet connectivity) and also

other components services (i.e., software procurement, Service Desk). This role involves managing roadmaps, technology lifecycles, capacity and availability management and other service performance accountabilities.

Accountabilities and Responsibilities:

• Ensures that the service meets its capacity and availability targets, and any additional agreed operational-level criteria

• Ensures that the Service Catalogue Process is observed such that the service entry is correct and up-to-date

• Owns a roadmap for the service and ensures it is up-to-date • Ensures that appropriate documentation exists for the service to be managed

and operated • Manages the relationship with 3rd party providers • Understands proposed changes to the service • Schedules and runs service reviews • Engages with reviews of business facing IT Services • Identifies opportunities for enhancement of services

Example

A Senior IT Services Specialist may own a Technical Service and will be accountable for keeping an up-to-date roadmap, arranging and running supplier reviews and meeting with the Academic and Business Partnering team to brief them ahead of meeting with Service Management Groups.

IT Service Owner An IT Service Owner is accountable for a business-facing service that utilises and packages a number of infrastructure services. This role includes managing service roadmaps, arranging service reviews, meeting with customers and users and other service performance accountabilities.

Accountabilities and Responsibilities:

• Ensures the service meets its agreed service levels • Understands the patterns of business use and periods of criticality • Ensures that the Service Catalogue Process is observed such that the service

entry is correct and up-to-date • Owns a roadmap for the service and ensure it is up-to-date • Ensures appropriate internal and external documentation exists for the service

to be managed, promoted and consumed • Manages the relationship with the customer • Understands proposed changes to the service • Engages with stakeholder groups and other fora to understand concerns with

and demands of the service

• Schedules and runs service reviews

Example

The Head of Corporate Systems will be the IT Service Manager for our financial support service. They will be accountable for raising and managing change proposals for the service, understanding when users need the service and the underlying business processes and working with Academic and Business Partnering to liaise with the customers.

Standards for Documentation

Introduction For the purpose of ensuring that all service practitioners are able to locate and use simple, easily understood process documentation, certain minimum standards and styles should be used. This will ensure a consistency and ease of access that will allow processes to be understood and followed consistently.

The use of specific styles and cues as outlined in Appendix C will make documentation more easily related and more usable. Examples of documents will be made available to process owners in order to guide their development.

Process and Policy Descriptions For each process, a policy and process description must exit. Usually these will be separate documents in order to make the process document more accessible. The content of these documents should include the following sections:

Policy Description • Purpose

Details of the reason we have the process in place, and general statements on the benefits

• Principles The principles of application and use of the process, such as when and when not to use the process, which teams are involved in the process and when the process relies on other processes

• Roles and Responsibilities Details of the individuals who have specific roles and responsibilities within the process (for example, the process owner, process manager, etc.), with an emphasis on successful operation of the process

• Critical Success Factors and Key Performance Indicators Details of what makes the process successful (e.g., consistent, positive experience for end users) and how we will know if we have been successful (e.g., decrease in the number of support calls re-opened)

Process Description • Process Flowchart

A flowchart detailing how the process should run, to an operational level of detail which can be followed by a process practitioner

• Procedure Details

Details of the exact procedure that a process practitioner should use at each stage of following the flowchart, including inputs, outputs and interfaces to other processes

Introductory Guides Each process should have an introductory guide of no more than 2 sides of A4, preferably including a high level flowchart. This document is aimed at all IT staff across the University, and should be written in a simple and easy to follow manner. Each member of IT staff will be expected to read all introductory guides, and this should be taken into account when authoring these guides.

Additional Artefacts Each process will inevitably require a number of other documentary artefacts that either detail the process or are templates for use during the process. Some examples of such artefacts may include:

• A Major Incident workbook for use when a Major Incident occurs • A Terms of Reference document for the Change Advisory Board • An Incident quick reference guide for the Service Desk • Customer-facing introduction to Service Levels

In keeping with the other documentation produced for a process, the same styling should be used to ensure that all the process documentation created for a process has a homogenous look and feel and is easily identifiable.

Assessing and Baselining our Service Management Maturity Over time the aim of Service Delivery will be to improve and mature all our service management processes to a point where we have a coherent and mature set of well-embedded processes. In order to achieve this it will be important to assess the processes in three ways:

1. The processes are objectively assessed against best practice to establish their maturity

2. The processes are subjectively assessed against each other to ensure that no processes become more or less mature than others

3. The processes set is subjectively assessed against the maturity the IT function of the University and against the overall administrative maturity of the University to ensure that the processes do not become significantly out of step with their environment

Assessing the environment On the journey to becoming a trusted partner of the University, the function of IT must move to being more business centric. In order to do this, we must honestly assess our location on this journey to ensure the processes we employ are fit for purpose at the current maturity level.

From time to time we will need to use a model similar to the one depicted in the diagram above to undertake this assessment. Alongside this model we can also map out the maturity journey of each of our processes. For example, Change management undertakes a similar journey from change control through to strategic change management via many steps.

Assessing the Processes Each individual process will be assessed against the Capability and Maturity Model Index (CMMI), which allows for an honest appraisal of the performance of each process against set descriptions.

Initial(Best Efforts)

Managed(Basic Management)

Defined(Standard Processes)

Quantatively Managed

(Value and Success Known)

Optimising(Continually Improved)

In each case the process will be looked at by the Process Owner and the Head of Service Delivery to arrive at a realistic understanding of the level of maturity, and will mark the start of a review of the process. It is expected that each process will be subject to review annually in this manner to ensure that the processes are given the correct resource to mature and provide best value. The aim is not to reach any specific level of maturity, and it is fully acknowledged that a process being deemed ‘good enough’ may be all that is required.

Appendix A – Process Ownership and Mapping

Fitting Processes to the Lifecycle

Much of this document has focussed on lifecycle phases, functions, roles and other considerations, whilst providing the framework within which the various service management processes can be designed and delivered.

In outline, the following diagram depicts the relationships between the various processes and the lifecycle phases.

Designing Our ServicesChoosing the Services We Provide

Building and Delivering Our Services Running Our Services Maintaining and

Developing our Services

Business Relationship Management

Demand Management

Service Portfolio Management

Change Management

Service Level Management

Capacity management

Availability Management

Service Catalogue

Management

Incident Management

Major Incident Management

Problem Management

Request Management

Knowledge Management

This should be used as a guide for process owners to establish the scope of their process.

Process Owners

Process Owner Demand Management Head of Academic and Business Partnering Service Portfolio Management Project Portfolio Manager Business Relationship Management Head of Academic and Business Partnering Service Level Management Head of Academic and Business Partnering Availability Management Capacity Management Change Management Head of Service Delivery Knowledge Management Incident Management Support Team Manager Problem Management Request Fulfilment Support Team Manager Service Catalogue Management Head of Academic and Business Partnering Major Incident Management Head of Service Delivery

Appendix B – The Service Lifecycle

ITIL v3 is founded on an underlying 5 part lifecycle, which underpins and co-ordinates the various controls and functions needed to manage modern IT services.

The lifecycle stages are:

• Service Strategy – The definition of the overall strategy for IT, assessing the demand for new or changed services, and producing the overall portfolio of services.

• Service Design – The design of the various services within the service catalogue, including agreeing the service levels required, the availability model for the service, and the security requirements of the service.

• Service Transition – Usually aligned with the technical build of a service, Service Transition includes the management of the service being built and tested, the recording of any new assets, management of the change and the planning and execution of deployment.

• Service Operation – The day-to-day management of services after they have completed deployment. Including the management of incidents and problems, monitoring and event management, providing access and fulfilling standard requests.

• Continual Service Improvement – The analysis of ongoing changes to business needs and our ability to provide and improve a service. Ensuring that service owners have service improvement plans in place, and that services are provided in as efficient a manner as is possible.

Appendix C – Communication Style

In order to better communicate the relevance of given documents and communications, we will adopt a thematic style for each Service Management process such that all communications and documents relating to a process can immediately be identified.

In order to achieve this, both a colour and an icon will be associated with each process, and should be used in all formal communication surrounding this strategy and our processes. The icons overleaf are the icons chosen, and are shown in the colours chosen to represent the various processes. These icons are available in Visio format.

Additionally all documentation written and reviewed to ensure that it is appropriately worded for its audience.

Process Icons

Change ManagementR:31 G:71 B:125

Incident ManagementR:192 G:80 B:70

Major Incident ManagementR:171 G:154 B:192

Service Catalogue ManagementR:157 G:187 B:97

Service Level ManagementR:245 G:157 B:86

Problem ManagementR:75 G:172 B:198

Knowledge ManagementR:165 G:165 B:165

Service Portfolio ManagementR:0 G:176 B:80

Business Relationship ManagementR:146 G:57 B:49

Demand ManagementR:255 G:0 B:0

Availability ManagementR:0 G:176 B:240

Request ManagementR:84 G:66 B:106

Capacity ManagementR:112 G:48 B:160