Services Supplier Integ V1a PDF

IT Service Management
A Methodology for
IT Managed Service Supplier Integration
White Paper
Author: Nicholas Collier

Date 19th August 2018
Version: 1.0
© Copyright 2018 Nicholas Collier. All rights reserved.

Duplication or content extraction of this document by permission only. Referencing is permitted.
Managed Services Supplier Integration
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
Page 2
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.
Page 3
• 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.
Page 4
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]
SIAM OSI view Integration map
Public Business
Service Integration
Insurance Insurance Providers Group IT

Business Process
Group Digital Ancillaries Providers CMC
Third Party Integrations Experian HSBC Nectar Worldpay DVLA
Polaris Bottomline Aggregators PAF Web Service

CDL Webhelp
Lexis Nexis Rapidmine Whitespace
Application
Elastic Search API (Autorek)
Database
RR Donnelley
Hosting
(& Core IT)
Network
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).
Page 5
Business processes
End-to-end ITSM processes
Application dev support &
change
Application Support L2
Application Monitoring
Platform business comms
Application platform integration
Application patching
Application SACM
Platform ITSM processes
Service Desk
Server Applications
Middleware – configuration Platform Cloud BPM
Database – configuration Managed type:
Services – SaaS
Operating System – Fully IT
configuration Platform integrated
Managed
Middleware - platform Services –
management Managed
Database - platform Cloud Platform
management type: only
Cloud PaaS
Operating System management type:
Virtualisation IaaS
Server hardware
DC Network
Colo
Datacentre
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.
Page 6
• 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.
Page 7
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.
Page 8
Platform Request Application Development

Team & Management
Host
Business
Dev User
End-User
Platform IT Self-Service
IT Self- Incident
PR Team Solutioning
Request
Requirement Service Portal Portal
Vendor Incident
ManageMe Problem
Request
AD Access MIM Portal Orchestration Change
Portal Interfaces Configuration
PaaS
Provisioning
Vendor
Business Office
Vendor Project PaaS

Team Units
Systems
Integration Host
Vendor
ManageMe
ServiceNow
Toolset
Host
Vendor Resolvers
Vendor Service Desk
(Platform)
Managed Infrastructure
Atos
Host Access
Management Host IT
controls
Operations
Host Resolvers
(Application)
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.
Page 9
Supplier IT Assurance Requirements
Lights on Efficient Strategic / KPO

Outsourcing Outsourcing e.g. Outsourcing BPO
(e.g. desktop, IT infrastructure E.g. specialist E.g. manage
file & related Application back-office
& print, devices) processes Management
IT Policy, governance & compliance
Supplier IT Service Processes
Supplier IT Operational Processes
Supplier IT solution
Supplier teams
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.
Page 10
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

• Fully host activity
• Host must govern,
A Above the line
control and operate
activities
• Principally host
activity, operated by
B At the line, Above supplier
• Host must govern and
control activities
• Principally supplier
activity, interfaces
C At the line, Below with host
• Host must govern
activities
• Fully Supplier activity
D Below the line
• 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.
Page 11
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:
Page 12
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
Page 13
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 Supplier Incident Criteria Example

Priority Priority
P1 (4h) P1 (4h) Widespread loss of A major office is

Vital business offline
functions
P2 (8h) P1 (4h) Widespread outage of A major office is
a single service significantly degraded
/ 5 retail stores offline
P3 (5 days) P1 (4h) Widespread service A single retail Cat A
degradation store is offline
Moderate number of
users outage
P4 (10 days) P2 (12h) /3 (20h) /4 Widespread minor A single user has
(30h) faults network issues
Small number of A single retail Cat
users outage 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.
Page 14
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 Number of software licenses required
Management Number of software licenses held
Page 15
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 Minor changes list
(BAU) 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 Number of Business Content Changes
Management” (Business % of failed Business Content Changes
Content Change) 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 & Number of Configuration Items
Configuration Management 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
Page 16
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
Page 17
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.
Page 18
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.
Page 19
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 & Service Level Management A process for defining and maintaining service levels for
Management controls services, components and external providers, including
issuing penalties for non-performance
Page 20
Account Management & Compliance A function which ensures that the activities of the
Management controls organisation are compliant with current legislation, for
example GDPR, and FCA.
Account Management & Service Management The set of activities that are performed by an
Management controls 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 & Account Management A supplier role that is responsible for the maintenance of
Management controls the relationship between client and supplier, as well as
conducting additional sales.
Account Management & Service Risk & Issue Management A process for ensuring that risks and issues relating to
Management controls the service are identified, reviewed and acted upon.
Account Management & Financial Management A process that provides the ability to budget for IT and to
Management controls charge the business for IT services as per the IT strategy
Account Management & Service Review meetings A continual set of meeting between client and supplier
Management controls whereby the service delivery scope, quality and cost are
reviewed. Service credits may be addressed in these
meetings.
Account Management & Audit Planning & Response The process of defining audit requirements, and
Management controls 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
Page 21
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 The point of liaison between IT and the business. A BRM
Management (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.
Page 22
Technology Ops Security Incident & Event An incident process specifically tailored for security
Management (SIEM) incidents which collects state, status, and exception
information from security devices and generates
incidents from these.
Technology Ops Application Development & The application team functions which develop software
Management 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 & The process of selecting and customising technology for
Roadmap the organisation in accordance with the organisation's
strategy.
Technology Operational Blueprint Orchestration A method for providing a simple request interface for
Process application teams to request platforms, and rapid
automatic provisioning of the platforms.
Technology Operational Platform provisioning solutioning Whereas platform orchestration provides individual
Process 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.
Technology Operational Batch Job Management The process used to manage predefined routine system
Process jobs which include batch file, scheduled tasks and file
transfer jobs.
Technology Operational Backup Management A process used to routinely write machines images, data
Process and application code to an alternative location in order
to provide a duplicate copy in case the source copy is
lost or corrupted.
Technology Operational Patch Management A technical process for obtaining, reviewing and applying
Process software updates for operating systems and
applications.
Technology Operational Environments Management The process and work involved in managing the various
Process hosting environments that form the release procession
path from development to production.
Technology Operational Software Packaging A process which reconstructs applications for specific
Process environment or purposes, for example Citrix
environments, or SCCM desktop software push.
Technology Operational IP Address Management (IPAM) A process for managing IP addresses assigned to a
Process specific firm or service. This includes tracking specific
assignments and addressing supply and demand of IP
addresses.
Technology Operational Datacentre Hands & Eyes A process and function that undertakes emergency work
Process in datacentres usually according to a precise script or
work instruction provided by the client.
Technology Operational Anti-Virus A class of program that will prevent, detect and
Process remediate malware infections on individual computing
devices and IT systems.
Technology Operational Build Management A process for managing build images, the release
Process versions, embedded software and features, and which
may include an option for the client to request builds or
changes to builds.
Technology Operational Collocated Hosting (Co-Lo) The provision of datacentre space as a managed service
Process which usually includes colocation facilities,
accommodation space, power, cooling, physical security,
storage, and networking.
Page 23
Technology Operational IT Currency A process to ensure that software and hardware versions
Process are within the allowed limits of age in relation to the
newest versions
Technology Operational Certificate Management A process for procuring, storing, validating, renewing and
Process 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)
Page 24

Services Supplier Integ V1a PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Services Supplier Integ V1a PDF

Uploaded by

Copyright:

Available Formats

IT Service Management

Author: Nicholas Collier

© Copyright 2018 Nicholas Collier. All rights reserved.

What is a Managed Service?

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

Relationship with Service Design

Define your SI/ SIAM organisation

SIAM OSI view Integration map

Insurance Insurance Providers Group IT

Third Party Integrations Experian HSBC Nectar Worldpay DVLA

Polaris Bottomline Aggregators PAF Web Service

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

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

Secondary Supplier Relationships

• Commercial Management responsibility – Identification of the party which commercially

Table 1, Supplier Relationships Table

Table 2, Example Service Level Mapping

Platform Request Application Development

Vendor Project PaaS

Supplier Assurance Requirements

Supplier IT Assurance Requirements

Lights on Efficient Strategic / KPO

IT Policy, governance & compliance

Supplier IT Service Processes

Supplier IT Operational Processes

Service Activity Demarcation

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

Activity Category Activity Definition Meaning

Defining Service Activities

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

Table 4, Sample of Supplier Activity Tracker

Process Reference Data Mappings

Host Incident Supplier Incident Criteria Example

P1 (4h) P1 (4h) Widespread loss of A major office is

Process flow / service RACI for joined activity

Figure 5, Example Supplier RACI

Reporting & Governance Processes

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

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

Number of software licenses purchased in

Major milestone dates and delivery dates

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

• Programmatic integration - Full toolset integration using Application Programme Interfaces

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

Validation and Acceptance

Appendix 1 – process list

Process Area Process / Function Name Definition

Define you SI/ SIAM organisation:

You might also like