IT Service Management A Methodology for IT …...providers and BPO (Business Process Outsourcing) type suppliers that provider business process and all required IT capabilities behind

© Copyright 2018 Nicholas Collier. All rights reserved.

Duplication or content extraction of this document by permission only. Referencing is permitted.

IT Service Management

A Methodology for

IT Managed Service Supplier Integration

White Paper

Author: Nicholas Collier

Date 19th August 2018

Version: 1.0

Managed Services Supplier Integration

Page 2 © Copyright 2018 Nicholas Collier. All rights reserved.


Introduction

This paper provides a methodology for defining and implementing IT outsourcing arrangements.

Due to the complex nature and large scale of outsourcing activities, one of the benefits from the use

of a methodology is to ensure that the complete breadth of activity is methodically addressed and

controlled. The method was derived from various experiences of supplier assessments, onboarding,

planning, and implementation of large scale outsourcing arrangements for high profile

organisations. The paper is written from the perspective of the host organisation, and not the

supplier perspective.

Why Outsourcing?

There was a time, not long ago where IT was considered to be both an internal function and an

optional tool enabling greater efficiency in the business. In today’s organisations, the business

reliance on IT is such that an IT organisation alone would not suffice to create a competitive

advance, and in fact only a business aligned IT organisation is required to gain a competitive

advantage. [1] There is a fusion whereby IT is effectively integrated and entwined with the fabric of

the organisation [1], from door entry to book keeping, sales, accounting and recruitment, from

storing customer details to running business processes, and can be run as an internal or external

function.

IT is a critical yet highly complex, specialised and costly part of almost every organisation that

exists, and it therefore requires a large management footprint. Many businesses chose to focus on

their core business and leave IT to the specialists. Outsourcing has become a popular way to

manage IT due to the fact that organisations can benefit from the specialism [2] and economies of

scale of large service providers, and save themselves the effort of providing and managing the

specialised capabilities. The primary purpose of outsourcing is to allow the firm to concentrate on

its own internal competencies where it can achieve definable preeminence and provide unique value

for customers. [3] The additional purposes of engaging with a managed services supplier is to

benefit from externalising the specific effort, costs and risks with regards to delivering a service.

In outsourcing situations, the supplier is typically responsible for delivery of the agreed service

scope, and host (the client or principle organisation) is responsible and accountable for performing a

service integration role, and supervising the supplier’s service delivery. In order to achieve the

benefits of outsourcing IT, an organisation must undergo a complex service integration with a

managed service provider. A number of firms that are well versed in outsourcing use a number of

suppliers which deliver the same services in order to create an internal market, and therefore price

competition among suppliers which is intended to lower costs. Thatcher NHS internal market: A

creation of an internal market served by outsource partners was considered to be a major change

that Margaret Thatcher made to the UK National Health Service. [4]

What is a Managed Service?

A managed service is an outsourcing arrangement whereby a large scope of work is undertaken by

an external organisation as opposed to specific defined activities. The external provider works with




autonomy and provides oversight to its own delivery scope; the process and functions moved from

the host organisation which is proactively managed. Managed services are intended to improve

operations, reduce costs, externalise risks, provide specific expertise, and allow the host to

concentrate on its core business. Managed Services are usually charges with a single fee for the

entire scope as opposed to for each activity. They are usually defined in a contact and underpinned

with Service Levels (performance and quality metrics).

Relationship with Service Design

ITIL Service Design tends to be very comprehensive in a number of ways, however it doesn’t tend

to cover Managed Services supplier integration in depth, hence this methodology compliments

Service Design to cater for the outsourcing world. Planning for managed services outsourcing tends

to fall under Service Design in ITIL terms, however this work may be carried out by a Service

Design function as a specific piece of work, or alternatively, and more usually it may be carried out

by a dedicated project.

Assumptions

This paper is about service integration, and it is therefore assumed that design and implementation

of the technology stack is performed elsewhere. It is assumed that supplier due diligence has taken

place and that the supplier has been evaluated for policy, governance and compliance by the

Supplier On-boarding process.

Define your SI/ SIAM organisation

A significant outsourcing arrangement means significant organisational changes and often an entire

reshaping of the organisation. The organisational changes required include among other things

changes to roles, processes, interfaces and tooling.

The point at which a decision is made to perform a major outsourcing initiative or significant

changes to IT outsourcing arrangements is a good time for the organisation to define the new

organisational SI or SIAM integration model which may span wider than the specific change taking

place. Once the target organisation is defined, it then needs to be put in place. The first question that

needs to be addressed is the question of what IT functions are to be retained as opposed to

outsourced. Often the retained IT organisation includes senior management, service management,

and the projects organisation and design authority.

This methodology looks at delivery of various elements by a chain of service providers upstream to

the host organisation. Where there are multiple service providers involved, the many streams of

delivery are aggregated by service integration points, which are usually operated by the host

organisation. The points of integration should be defined in the new organisation using the

categories below which are broad definitions rather than absolutes.




• Commercial Management – The point at which outsourced services are managed in terms of

cost and adherence to contacts.

• Service Management integration – The point at which outsourced services are managed in

terms of delivery scope, quality (Service Levels) and issue management.

• Service Integration/ SIAM (Service Integration & Management) – The point of integration

of service providers, meaning the point to which day-to-day operational service is

considered to be delivered to and therefore this point combines the various services from

various providers into a single service or set of services.

• Process Integration – A process is a set of routine work activities which may span multiple

parties. The point of process integration is the point at which the end-to-end process is

controlled and managed so that a disparately delivered process is integrated into a single

point of delivery. (This is not necessary the same role as Process Owner). For example, a

service provider may be responsible for the end-to-end incident process meaning it will

triage incidents to other suppliers, tracking the incident through a chain of providers and

providing follow up where other suppliers have not responded in the correct way, or within

the required timescales.

Note: These integration points are defined in this section on the organisation level. A number of

these integration points will be repeated in the supplier relationships section because some of these

integration points may exist in supplier organisations as well as the host organisation.

There are a number of other considerations for setting up an organisational service integration

framework and these relate to policy & process, desktop computing, ITSM toolset and business

onboarding. The adoption of a common operating framework may involve building new resources,

or it may simple involve adopting existing resources belonging to one of the parties and applying

these to the other parties.

A common set of policies and processes allows all of the participants in the integrated organisation

to work to the same standards and adhere to the same set of rules, thus allowing interactions to

operate in an expected manner.

A consideration is the stipulation of the use of common desktop computing Common Operating

Environment (COE), IT networks, IP address ranges, computing domains, internet domains, email

domains, email messaging systems, instant messaging systems, collaboration portals and document

formatting standards.

The use of ITSM toolsets between the suppliers must be considered, and the common options for

this are usually for the host or a key supplier to provide a single ITSM toolset, or for individual

parties to use disparate ITSM tools which are integrated.

It may be necessary to onboard suppliers into the organisations business operating framework, and

this may exceed the use of computing environments and tools, for example it may include the

issuance of organisational training, which may contain background information about the business,

the organisational structure, organisational charts and compliance training.




An SI/ Siam diagram can be used to express the fact that a number of different organisations are

delivering various elements of IT to a service integration point which delivers an aggregated service

to the host’s businesses and customers. [5]

Public

SIAM OSI view Integration map

Business

Service Integration

CDL

Group ITInsurance

Experian

Polaris

HSBC

Bottomline

Nectar

Aggregators

CMCGroup Digital

Business Process

Third Party Integrations

Application

Database

Hosting(& Core IT)

Network

Webhelp

Elastic Search

Lexis Nexis Rapidmine

Worldpay

RR Donnelley

API (Autorek)

Ancillaries Providers

Whitespace

PAF Web Service

DVLA

Insurance Providers

Figure 1, SIAM diagram showing the various layers of outsourced IT delivery

Supplier Types

Supplier type refers to the outsourced activities performed by the supplier. Each supplier type is

broadly aligned to a level on the Open Systems Interconnect model (OSI model- a model design to

characterise layers of a network communications stack but is also useful in defining technology

architecture layers in terms of an ordered and layered stack). Supplier types range from colocation

providers who just provide datacentre space, managed platform providers, managed application

providers and BPO (Business Process Outsourcing) type suppliers that provider business process

and all required IT capabilities behind this).

In terms of delivery level, there is an equivalence between managed services provides and Cloud

providers at various levels. For example a managed platform service which provides servers for the

client to configure and use corresponds to cloud type IaaS (Infrastructure as a Service). A managed

platform service which provides ready to use platforms which only require application code to be

overlaid, corresponds to cloud type PaaS (Platform as a Service). A managed service provider

which develops, manages and publishes an application for use by the host corresponds to cloud type

SaaS (Software as a Service).




Business processesEnd-to-end ITSM processesApplication dev support & changeApplication Support L2Application MonitoringPlatform business commsApplication platform integrationApplication patchingApplication SACMPlatform ITSM processesService DeskServer ApplicationsMiddleware – configurationDatabase – configurationOperating System – configurationMiddleware - platform managementDatabase - platform managementOperating System managementVirtualisation Server hardwareDC NetworkDatacentre

Colo

Cloud type: IaaS

Cloud type: PaaS

Platform Managed Services – Managed Platform

only

Platform Managed Services –

Fully IT integrated

Cloud type: SaaS

BPM

Figure 2, Chart showing the various different types of provider organisations

Secondary Supplier Relationships

The supplier to host relationships examined till this point have been primary relationships i.e.

supplier to host relationships. In more complex outsource situations, secondary relationships exist,

meaning that supplier may have relationships with other suppliers that are contracted by the host.

The suppliers which have a relationship with other supplier, rather than the host are known as

secondary suppliers. It is important to understand the secondary supplier relationships because these

relationships will need to be put in place, often by means of agency agreements.

It is advisable to produce a list of all suppliers involved in the solution or IT organisation which

catalogues the set of relationships. Below is a list of supplier relationship attributes:

• Commercial Management responsibility – Identification of the party which commercially

manages the supplier

• Service Management responsibility – Identification of the party which service manages the

supplier

• Operational handoff responsibility – Identification of the party which operationally hands

off work items to the supplier, for example the party that triages incidents or passes a

requirement for request fulfilment to another party

• Hosting provided – The systems or applications that are hosted by the party or for which the

party arranges hosting for.




• Systems integration – Identification of systems and applications that are integrated between

the provider(s) and host organisation.

Table 1, Supplier Relationships Table

Service Levels

The IT organisation will have an implied or defined set of service levels that are delivered to the

business. In order to deliver the required service levels to the business, any outsourced IT must be

underpinned which service levels that are at or better than the service levels offered to the business.

A system of service level mapping should be undertaken, where by the output service levels of IT

are mapped to the inputs from the various suppliers in order to ensure alignment. The service level

mappings table below provides an example of mapping service inputs to the outputs.




Table 2, Example Service Level Mapping

Service Architecture

A service architecture definition may be useful in order to help define the integration of key

providers and consumers of the service from a summary process perspective. The service

architecture depicts the front-end tools and interfaces for end-users and development users

(application teams), as well as the flow of events through the key tools & resources in the back-end

of the aggregated service solution.

Examples of use cases for a service architecture are incidents and requests that originate from end-

users, and platform requests that originate from development users. The key use cases defined will

illustrate that end-users need interfaces and tools for incidents and requests, and development teams

may need an orchestration portal in order to request platforms.

The diagram below provides an example service architecture for an IT outsourcing situation.




Dev User

IT Self-

Service Portal

Vendor Orchestration

Portal

End-User

Host

Service Desk

Host

ManageMe

Toolset

IT Self-Service

Portal

Host Resolvers

(Application)

PaaS

Units

Vendor

Managed Infrastructure

Vendor Resolvers

(Platform)

Atos

Host

Business

Application Development

& Management

Host IT

Operations

Vendor

ServiceNow

SystemsIntegration

Vendor Project

Team

IncidentRequest

IncidentRequest

PaaS Provisioning

ManageMe

Interfaces

ProblemChange

Configuration

Platform Solutioning

Requirement

MIM PortalAD Access

Host Access

Management

controls

Platform Request

Team

PR Team

Vendor

Business Office

Figure 3, Service Architecture Diagram, depicting key use cases from a process perspective

Support Model

A support model refers to the organisational design of an IT organisation with regards to support

capabilities, and this includes incident origination points e.g. Service Desks and monitoring

systems, component teams and the route of functional and hierarchical escalation. A support model

approach should be used to compare the component types required for the solution to the internal

and external support capabilities in order to determine that the required capabilities have been

covered, and that therefore every component type is supported.

Supplier Assurance Requirements

Supplier Assurance refers to the requirement for the host to govern supplier activities. The extent of

assurance required for a supplier activity depends on the activity and the supplier type. The

following chart is a reckoner which depicts the varying levels of assurance required from the host

organisation towards various elements in four differing supplier situations.




Supplier IT Assurance Requirements

IT Policy, governance & compliance

Supplier IT Service Processes

Supplier IT Operational Processes

Supplier IT solution

Supplier teams

Lights on Outsourcing

(e.g. desktop, file

& print, devices)

EfficientOutsourcing e.g. IT infrastructure

& related processes

Strategic / KPOOutsourcing

E.g. specialist Application

Management

BPOE.g. manage back-office

Figure 4, Supplier IT Assurance Requirements Guidelines.

This chart should be used as a guideline for the next section which defines the process of grading

supplier activities in terms of assurance and operational ownership.

Service Activity Demarcation

In order to integrate a managed services supplier it will be necessary to define the specific activities

that take place, to understand how these will work, then implement and test the activities. It will be

necessary to understand the distribution of responsibility in terms of implementing, performing and

assuring each activity.

The types of responsibility for each work item are as follows:

• Govern - Ensure that the activity is carried out and in accordance with the business, policy

and compliance requirements.

• Control - Control the outputs of the activity using process controls e.g. approvals, oversight

or reporting

• Operate - Implement, manage day to day operations and control the outputs of the activity

The host must operate, control and govern over the line activities because by their very nature, the

activities are within the host space. Under the line activities may be operates by the supplier,

however controlled and governed by the host. A single definition of where activities fall on the

supplier line is not possible to the various types of supplier in existence and the unique nature of

outsourcing arrangements. The activities that fall into the supplier scope differ according to the type

of supplier, for example resource only suppliers, light-on providers, managed service providers,

Cloud providers or BPOs.




Each work item must be assigned in terms of responsibility and the method of categorising the

zones of responsibility between host and supplier uses the concept of “above” and “below” the line.

The “line” being described here is the organisational boundaries which also demarcate task

ownership responsibility. Work items which fall above the line are within the host area of

responsibility and work items below the line are in the supplier area of responsibility.

In actual terms, many of these areas have blurred boundaries with shared ownership and interaction

between the parties. For this reason the classification system used is not a binary value but a

gradient scale.

The table below defines the supplier line categorisations to be used for each process step:

Activity Category Activity Definition Meaning

A Above the line

• Fully host activity

• Host must govern,

control and operate

activities

B At the line, Above

• Principally host

activity, operated by

supplier

• Host must govern and

control activities

C At the line, Below

• Principally supplier

activity, interfaces

with host

• Host must govern

activities

D Below the line • Fully Supplier activity

• No host involvement

Table 3, Supplier Activity Categorisation

Contract

At this point, the mode of supplier integration, service levels and supplier activities have been

defined. It is necessary to crystalize these definitions in a legal contract which sets the scene with

respect to delivery expectations and forms mandatory obligations between the parties. The first

edition of the contract is normally produced by the supplier and it should be robustly reviewed by

the host to ensure that it contains the desired delivery state. A formal cycle of contract review,

change and agreement should be undertaken and this should be part of the design and

implementation phases.

All project workstreams, related BAU teams and IT managers must be encouraged to review the

contract for the operational areas and feed any requested contract changes to the project. As the

design and implementation workflow progresses new requirements may emerge which not in the

contracted and need to be reflected in the contract scope. It should be noted that changes to

contracts become harder to make as the timeline past initial contract production progresses,

therefore contract review should be undertaken early on during the design phase.




Defining Service Activities

It will be necessary to define the specific service activities required under the outsourcing

arrangements and to categorise these in terms of the supplier line. Supplier activities are based on

processes and process steps, which are the work items which underpin processes. The required

process list for the outsourcing arrangements in question should be determined and this forms a

scope of integration activity. (You may refer to Appendix 1 which provides a full process list out of

which the relevant processes can be selected). Processes should be broken down into their required

elements or process steps, for example the Request process can be broken down into capture,

validate, approve, assign, fulfil, communicate and close.

A Process tracker is used to capture the supplier & host position for each element of each process.

The process detail in the tracker involves a definition of the required actions, data inputs, processing

activity, interfaces and communication routes. Process detail can be initially aligned generic process

definitions and current host and supplier practises in order to form a basis for discussion. It is

advisable to conduct workshops involving the supplier, the project, related process owners and

technical teams in order to determine the specific process detail.

Each service activity must be classified A to D according to its position on the supplier line. The

items in category A do not require supplier interaction and therefore do not need to be addressed in

supplier discussions. The host must perform the design work defining how these activities operate.

Items which are category B & C, need to be considered by host and supplier in order to assure that

the activity is designed correctly and meets the operational needs of both organisations. All process

activities which relate to category D processes are put to one side by the host because are below the

point of reasonably requiring any client oversight or involvement during transition or operations.

The following table is an extract from a sample process tracker:




Table 4, Sample of Supplier Activity Tracker

Process Parameters

Process parameters refers to details of specific work item types that are specific to the host’s needs

and fall under a process, where relevant. Examples of process parameters include Request types

under Request Management, incident scenarios under Incident Management and standard change

types under Change Management. Where possible the existing organisational process parameters

should be obtained from the various existing process areas.

The existing process parameter should be tabularised according to process steps, for example in the

request process, a table should be defined which includes request type name, approver, and columns

for fulfilment details showing the various fulfillers and actions for each request type. The

tabularised process parameters should be reviewed for completeness and accuracy. The final

process parameters should be passed to the supplier for implementation.

Process Reference Data Mappings

Processes contain various static parameters such as priority under Incident Management, and

change types under Change Management, and there will be referred to as process reference data.

Examples of process reference data differences include support queues, incident priority, change

types, change timescales and change CABs. Process reference data will often not map directly

between parties because each party may different definitions because there is enormous variation of

reference data across the industry. The differences must be understood and equivalent data types




between the parties mapped against each other so that these can be built into the joint processes and

integrated toolsets.

The table below is an example of incident priority mapping between host and service provider

organisation.

Host Incident

Priority

Supplier Incident

Priority

Criteria Example

P1 (4h) P1 (4h) Widespread loss of

Vital business

functions

A major office is

offline

P2 (8h) P1 (4h) Widespread outage of

a single service

A major office is

significantly degraded

/ 5 retail stores offline

P3 (5 days) P1 (4h) Widespread service

degradation

Moderate number of

users outage

A single retail Cat A

store is offline

P4 (10 days) P2 (12h) /3 (20h) /4

(30h)

Widespread minor

faults

Small number of

users outage

A single user has

network issues

A single retail Cat

B/C/D store is offline.

Table 5, Example mapping of incident priority

Process flow / service RACI for joined activity

A definition of specific process steps with specific ownership should be produced either in terms of

a service RACI (and/or swimlane process flow). The service RACI will act as a user friendly and

communicable artefact that can be used to allow the wider stakeholder community to review the

intended operating model, provide feedback and propose changes were necessary. The information

collected in the finalised process activity tracker should act as the basis for the initial population of

the RACI.

The service RACI table will show the key steps across service processes and all of the involved

parties. The RACI will depict a flow of activity for each process, for example a request ticket

routing between the various request, capture, approval, fulfilment functions.




Figure 5, Example Supplier RACI

Reporting & Governance Processes

The outsourced service is governed by the host organisation, and governance is largely carried out

by feeding the state of the operational management to the host’s IT management functions by

means of reports, and having the IT management provide feedback to the supplier operational

environment. Examples of supplier reports tend to include SLA performance data, process

performance, technology element status (e.g. patch version and Anti-Virus version), and work item

pipeline details, risks and issues. During the design phase, the required report types, metrics, format,

audience and frequency must be agreed between host and supplier. Managed Service suppliers will

provide the host with a number of periodic service reports to facilitate management of the supplier.

The following table summarises possible areas to be covered by supplier reporting:

Operational Reporting Anti-Virus Compliance Percent of servers within AV console

compliance

Anti-virus DAT versions report

Anti-virus software version report

Operational Reporting Patching compliance Percent of servers within agreed patch level

Percent of devices within agreed patch level

Operational Reporting IT currency compliance Percent of devices within currency level

Percent of applications within currency level

Operational Reporting Certificate Management Number of digital certificates

Number of certificates renewed in reporting

period

Number of certificates expiring in next 3

months

Operational Reporting Software License

Management

Number of software licenses required

Number of software licenses held




Number of software licenses purchased in

reporting period

Service Reporting Incident Management Number of minor incidents

List of major incidents

Categorisation of incidents

List of security incidents

% of incidents completed within SLA

Backlogged incident ticket report

Service Reporting Service Requests Number of Service requests

Categorisation of Service Requests

% of Service Requests completed within SLA

Service Reporting Access Management Number of access requests

Number of non-approved access requests

% of access requests completed within SLA

Service Reporting Problem Management Number of Problem RCAs

Categorisation Problems

% of Problem RCAs completed within SLA

Service Reporting Change Management

(BAU)

Minor changes list

Major changes list

Open changes list

Failed changes list

% of Changes that failed

List of incidents arising from changes

Forward Schedule of Change

List of changes approved by SB CAB

List of change freeze periods

Service Reporting “Configuration Change

Management” (Business

Content Change)

Number of Business Content Changes

% of failed Business Content Changes

List of incidents arising from Business

Content Changes

Service Reporting Release Management Forward Schedule of Releases

Failed releases list

Testing reports

Service Reporting Service Asset &

Configuration Management

Number of Configuration Items

Number of CI’s added/ removed/ changed in

reporting period

Service Reporting Capacity Management Daily capacity summary

Monthly capacity summary

Service Reporting Availability Management Daily availability summary

Monthly availability summary

Service Reporting IT Service Continuity List of services with/ without ITSCM plans

Last Disaster recovery test performed per

service

Service Reporting Risks & Issues List of open risks & issues

Service Reporting Service Improvement items List of CSIP items in pipeline

List of CSIP items completed in reporting

period

Service Reporting Finance Monthly IT Service Invoice

IT Service financial forecast & budget

Service Reporting Project List of on-going projects an initiatives




Major milestone dates and delivery dates

Service Reporting Customer Satisfaction Level of customer satisfaction

Number of complaints

Number of hierarchical escalations

Table 6, Example Supplier Reporting structure

Tooling

The ITSM toolset refers to the tool used to provide interfaces and workflow processes for service

processes (e.g. Request, Incident, Problem, and Change). ITSM Toolset architecture requirements

should be driven by the service integration requirements for the multi-party organisation. A single

toolset may be used across parties or disparate toolsets may be used.

Where disparate toolsets are used, integration may be carried out by various methods, which

involve differing levels of complexity as shown below:

• “Swivel chair” integration - An operator rekeys work items between systems

• Simple message - A simple message that carried work items between systems, for example a

ticket is parked in a vendor queue which automatically generates an email which in sent to

the supplier system which subsequently auto-generates a ticket

• Programmatic integration - Full toolset integration using Application Programme Interfaces

(APIs)

• Enterprise Service Bus – A toolset intermediary systems used to integrate the various

disparate systems and to translate the reference data and parameters between toolsets.

The integrated tooling should be specifically designed including the technical integration methods

between the parties. Any other tooling requirements that are required as a result of process

integration should be considered and designed, for example software license systems belonging to

the supplier may be integrated with the host’s software licensing system.

Implementation

The implementing phase involves putting in place required tooling, interfaces, roles, process flows

and Work Instructions. The service integration project should plan and resource implementation as

process aligned project workstreams which follow the design phase. The implementation

workstreams should contain staff members from both the host and supplier organisations, and

should either involve or liaise with process owners and related technical specialists.

Any roles requires to perform the process workflows or support capabilities should be put in place,

and this may involve hiring on the host side, or requesting additional roles on the supplier side. The

project should work with human resources in order to address resources that are no longer required

in the new organisation so that the employment options for the staff are considered and the

processes that are required by law are followed. The process aspects should be operationalised by




circulating the service RACI (and/or process definitions) to all parties who are involves with the

processes.

Where transition is taking place from in-house teams other suppliers to the nominated supplier,

Knowledge Transfer (KT) should be undertaken. A KT agenda should be drawn up and this should

be based on organisation specific information (for example custom server login and shutdown

procedures, and application start scripts), as opposed to generic IT information (for example

supporting Windows server). Any organisation specific knowledge should be documented in the

appropriate format. (For example application operating manual, Work Instruction, or Kb).

Agency agreements will need to be put in place to allow suppliers to interact with other suppliers,

and the supplier relationships view helps shape the requirements for agency agreements. The

integrated ITSM Tooling should be implemented as per the agreed architecture, and populated with

the agreed reference data and process parameters. Processes should be configured in the logic of the

toolset as per the agreed process tracker. Required process controls such as validation of requests or

workflow approvals should be configured in the toolset.

Any process communication, for example notifications for request approvals or request completions

should be configured in the tool. Any other tooling requirements to enable the parties to work

together should be completed at this point.

Interface points such as End-user Self-Service portals, platform orchestration portals, and Service

Desks for end-users should be tested from the host organisation and the contact details (e.g. phone

numbers and URLs) recorded so that these can be used in the communications to end-users,

development users and support teams. Reporting mechanisms should be activated and the agreed

reports scheduled for production, and published through the agreed routes e.g. email or portal.

Any known risks and issues regarding integration with suppliers must recorded, reviewed and

tracked and for each risk or issue, an agreed position will be action will be agreed i.e. mitigate the

gap, accept the gap or carry the gap forward.

It is necessary to provide routine communications throughout the IT organisation and to nominated

business representatives at key milestones in the change.

Validation and Acceptance

Validation refers to end-to-end process testing to ensure that all of the required elements are

performing as required. Acceptance refers to a set of acceptance gates which ensure that an agreed

set of criteria have been fulfilled before the service is declared live. The supplier integration need to

be tested using key test cases that test each toolset, key process and elements for each process.

Test cases should be selected on the basis that they capture the key elements and resources in the

solution, for example an incident test case for each supplier involved with the solution, and Request

test cases for the top 15 request types. Following testing, a set of agreed readiness and acceptance

criteria should be used to demonstrate readiness for each process and the acceptance process should

maintain a log of all issues against each process.




Operational Phases

In the case of complex IT outsourcing, service readiness is usually delivered in multiple phases,

however for simplicity we will use two phases, IMO (Interim Mode of Operations) and FMO

(Future Mode of Operations). There may be strategic or tactical reasons why an interim phase of

operation is needed. A an example of a strategic reason for in interim phase is the delivery of a new

outsourced platform service where into which applications are migrated over a long period of time,

and for which platform readiness is needed in time for the first application migration batch. A an

example of a tactical reason for in interim phase is to deliver a minimum service based on limited

level of project completion during IMO (Interim Mode of Operations) in the interests of time and

during this phase to carry out the remainder of the implementation work, as well is resolving the

outstanding issues.

The minimum level of readiness for IMO includes readiness of the core technology stack and

processes to the point that they are usable by the consumers of the service. Any elements which

pertain to the full service and which have not been addressed are to be addressed in the IMO phase

and therefore delivered in FMO (Future Mode of Operations). Open items in the IMO phase may

include complex technology elements such as automation of tasks, and various work items relating

to full process readiness. The IMO phase provides an operational service which is handed over to

the support organisation to support.

It would be advisable to consider enhanced support during the IMO phase, for example with any

new suppliers providing an enhanced level of support (Hypercare). It would be necessary to

coordinate the Hypercare team with the functions behind any recently changes elements (e.g.

application migrations), and existing support structures and teams, in terms of the incident and

major incident process. The IMO support relationships should be precisely defined for all involves

support teams including Hypercare for the IMO phase. This includes a definition of any shadowing

(support involving the old and new teams in order to facilitate knowledge transfer), reverse

shadowing, ownership point, escalation points and advisory points.

Because the IMO phase is an ever changing situation, there is a need for an IMO management

system to continually capture the current position (e.g. technology stack readiness, process

readiness, and application migration status) and communicate this position to the support

organisation. Any unexpected issues from initial service acceptance should be carried forward into

the IMO phase for remediation.

The FMO phase is specifies the full and final service, and therefore all activity must be completed

and all issues resolved, or accepted before entry into the FMO phase.

Conclusion

In the right set of circumstances managed services bring about large benefits by freeing the host

from the involved scope, however realising the benefits involved the correct implementation and

ongoing management of the managed service. A successful implementation depends upon bringing

the various perspectives together; the service integration perspective, the capability perspective, the

process perspective, and the tooling perspective, the required governance system and the project

delivery perspective. Providing a robust implementation will allow the firm to realize the benefits of

outsourcing and avoid storing up problems for the future.




Appendix 1 – process list

The following table provides a list of possible service processes and operational processes that are

for consideration when performing outsource supplier integration:

Process Area Process / Function Name Definition

Strategy & Integration ITSM Toolset An IT Service management tool used to manage the workflow pipelines associated with work items for the Incident, Problem and Change Management processes within IT.

Strategy & Integration Service Integration / SIAM Service Integration and Management (SIAM) is an approach to managing multiple suppliers of services (business services as well as information technology services) and integrating them to provide a single business-facing IT organisation.

Strategy & Integration Strategy Management Providing analysis and guidance on the direction of IT operations and expenditures, and ensuring that IT is aligned with the business requirements.

Strategy & Integration Service Catalogue A service Catalogue is an organised and curated collection of any and all business and information technology related services that can be performed by, for, or within an enterprise.

Strategy & Integration Exit Plan Statements and contractual provisions in managed services arrangements which define the terms and conditions as well as operations of exit, meaning a severance of the relationship between client and service provider

Strategy & Integration Continual Service Improvement A process for identifying, capturing, tracking, and progressing improvement items in an IT organisation.

Design & Transition Support Model A definition of support arrangements in place for an organisation or service including incident inputs (e.g. Service Desks, or monitoring systems), and support teams which may depict the routing of incidents through the various functional layers, and which may contain contact information for teams and managers.

Design & Transition Programme transition processes The processes used for an IT service move, which may include the implementation of underpinning infrastructure, supporting processes and application migrations.

Design & Transition Service Validation A form of testing which tests service use cases ranging from completion of a business process to service use cases such as specific request or incident scenarios

Design & Transition Service Acceptance A processes used to govern services which are being introduced which ensures that defined organisational acceptance criteria are met before the new services are declared live.

Design & Transition Service Design Service design is the activity of planning and organizing people, infrastructure, communication and material components of a service in order to improve its quality and the interaction between the service provider and its customers.

Account Management & Management controls

Service Level Management A process for defining and maintaining service levels for services, components and external providers, including issuing penalties for non-performance





Compliance A function which ensures that the activities of the organisation are compliant with current legislation, for example GDPR, and FCA.


Service Management The set of activities that are performed by an organisation in order to plan, design, deliver, operate and control IT services offered to customers. These activities are directed by policies, organised and structured in terms of policies, processes and operating instructions.


Account Management A supplier role that is responsible for the maintenance of the relationship between client and supplier, as well as conducting additional sales.


Service Risk & Issue Management A process for ensuring that risks and issues relating to the service are identified, reviewed and acted upon.


Financial Management A process that provides the ability to budget for IT and to charge the business for IT services as per the IT strategy


Service Review meetings A continual set of meeting between client and supplier whereby the service delivery scope, quality and cost are reviewed. Service credits may be addressed in these meetings.


Audit Planning & Response The process of defining audit requirements, and cascading these to relevant technical functions to carry out the audits, reporting on audits, tracking and managing issues that arise from audits.

Service Support Event Management A process for monitors all events that occur through the IT infrastructure to ensure that system exceptions are captured and acted upon.

Service Support IT Self-Service portal A tool used to provide a direct interface for users to log incidents, make requests and which often provide self-help facilities.

Service Support Service Desk A primary function within an IT organisation that provides a Single Point of Contact ("SPOC") to meet the communication needs of both users and IT staff, and also to satisfy both Customer and IT Provider objectives.

Service Support Incident Management A process used to restore service as quickly as possible in the event of an outage, often using workarounds.

Service Support Major Incident Management A process for managing major incidents which usually involves a dedicated team who coordinate and manage the incident, directing the involved support resources.

Service Support Interim Mode of Operations (IMO) A definition of the operating mode during the transitional state of an environment, for example the support model for applications during the application migration process.

Service Support Software Asset Management A process which is used to ensure compliance with software licensing requirements which compares licenses held against licenses consumed for each licensable software product.

Service Support Request Management A process for capturing and executing computing requests that originate from end-users, for example hardware request or desktop software installation

Service Support Access Management A process sued to control physical and logical access to resources using controls to ensure that only authorised users have access to resources.

Service Support Configuration Management A process used to capture and record specific IT assets and resources and their relationships in order to provide an asset centric view of the IT organisation




Service Support Knowledge Management A system for gathering, consolidating and presenting knowledge in order to ensure that knowledge is navigable and current.

Service Support Change Management Change Management is a process used to ensure that standardized methods and procedures are used for efficient and prompt handling of all changes to control IT infrastructure, in order to minimize the number and impact of any related incidents upon service.

Service Support Release Management The process of managing, planning, scheduling and controlling a software build through different stages and environments; including testing and deploying software releases.

Service Support Problem Management A process for capturing and investigating the underlying causes of incidents, and managing the work involved in correcting the underlying issues.

Service Delivery Resilience Resiliency is the ability of a server, network, storage system, or an entire data centre, to recover quickly and continue operating even when there has been an equipment failure, power outage or other disruption. The term is usually used to denote a component which runs alongside another (e.g. router, server or power supply) which is to be used as an alternative as opposed to alternative components across datacentres which is referred to as Disaster Recovery.

Service Delivery Supplier Management A function for managing suppliers through the engagement lifecycle including supplier due diligence and onboarding, to ensuring that the supplier performs against the contract, renewals, actioning service credits and renegotiations.

Service Delivery Business Relationship Management (BRM)

The point of liaison between IT and the business. A BRM deals with customer satisfaction, feedback & complaints, strategic change, and the business perspective of IT. Provides technology guidance to ensure maximum return on investment (ROI) for IT business strategy requirements.

Service Delivery IT Service Continuity Management The process for managing risks that could seriously impact IT service delivery including, agreeing acceptable risk, minimum Service Levels, and planning for disasters.

Service Delivery Capacity Management A process for measuring the utilisation of components and services in order to prevent outages caused by over-utilisation

Service Delivery Demand Management A process for assessing future business demand in order to assess technology demand which used to plan for the sale of service delivery.

Service Delivery Availability Management A process for measuring the propensity for a service to be useable by business users, and for managing issues which cause service outages

Service Delivery Service Reporting A set of reports routinely produced by service provides against technology elements, technology teams, service processes and operational processes in order to communicate the health and status of the operational environment.

Technology Ops Desktop Engineering A function which develops and maintains the end-user computing desktop environments which include operating system builds, standard software, customisations, and user profiles.




Technology Ops Security Incident & Event Management (SIEM)

An incident process specifically tailored for security incidents which collects state, status, and exception information from security devices and generates incidents from these.

Technology Ops Application Development & Management

The application team functions which develop software using a full lifecycle approach, including requirements gathering, development of code through successive phases, and orderly release of the code into the live environment. Additionally, the application lifecycle management including governance, ongoing development changes, and maintenance of software.

Technology Ops Technology Engineering & Roadmap

The process of selecting and customising technology for the organisation in accordance with the organisation's strategy.

Technology Operational Process

Blueprint Orchestration A method for providing a simple request interface for application teams to request platforms, and rapid automatic provisioning of the platforms.


Platform provisioning solutioning Whereas platform orchestration provides individual platform units on demand, platform solutioning provides consultancy in order to provide platforms for complex provisioning requests e.g. enterprise applications or deviations from standard product sets requiring specific security configurations.


Batch Job Management The process used to manage predefined routine system jobs which include batch file, scheduled tasks and file transfer jobs.


Backup Management A process used to routinely write machines images, data and application code to an alternative location in order to provide a duplicate copy in case the source copy is lost or corrupted.


Patch Management A technical process for obtaining, reviewing and applying software updates for operating systems and applications.


Environments Management The process and work involved in managing the various hosting environments that form the release procession path from development to production.


Software Packaging A process which reconstructs applications for specific environment or purposes, for example Citrix environments, or SCCM desktop software push.


IP Address Management (IPAM) A process for managing IP addresses assigned to a specific firm or service. This includes tracking specific assignments and addressing supply and demand of IP addresses.


Datacentre Hands & Eyes A process and function that undertakes emergency work in datacentres usually according to a precise script or work instruction provided by the client.


Anti-Virus A class of program that will prevent, detect and remediate malware infections on individual computing devices and IT systems.


Build Management A process for managing build images, the release versions, embedded software and features, and which may include an option for the client to request builds or changes to builds.


Collocated Hosting (Co-Lo) The provision of datacentre space as a managed service which usually includes colocation facilities, accommodation space, power, cooling, physical security, storage, and networking.





IT Currency A process to ensure that software and hardware versions are within the allowed limits of age in relation to the newest versions


Certificate Management A process for procuring, storing, validating, renewing and revoking digital certificates to ensure that outages are not caused by expired certificates.

References

Why Outsourcing?:

[1] Tomasz Smaczny, (2001) "Is an alignment between business and information technology the

appropriate paradigm to manage IT in today’s organisations?", Management Decision, Vol. 39

Issue: 10, pp.797-802, https://doi.org/10.1108/EUM0000000006521

[2] A. Sloper, "Meeting the challenge of outsourcing," in Engineering Management Journal, vol. 14,

no. 3, pp. 34-37, June-July 2004.

doi: 10.1049/em:20040307

Abstract: URL:

http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=1334706&isnumber=29427

[3] Quinn, James Brian; Hilmer, Frederick G. Sloan Management Review; Cambridge Vol. 35, Iss.

4, (Summer 1994): 43.

[4] Talbot-Smith, Alison, and Allyson M. Pollock. The new NHS: a guide. Routledge, 2006.

Define you SI/ SIAM organisation:

[5] Peter Wiggers (Author), Dave Armes (Author), Niklas Engelhart (Author), Peter McKenzie

(Author). Siam: Principles and Practices for Service Integration and Management. Van Haren

Publishing; 01 edition (18 Nov. 2015)

https://doi.org/10.1108/EUM0000000006521

http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=1334706&isnumber=29427

Documents

IT Service Management A Methodology for IT …...providers and BPO (Business Process Outsourcing) type suppliers that provider business process and all required IT capabilities behind