IT Service Management a Methodology for IT Managed

A Methodology for IT Managed Service Supplier Integration

White Paper

Author: Nicholas Collier Date 19th August 2018 Version: 1.0

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

Managed Services Supplier Integration

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.

Managed Services Supplier Integration

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

Managed Services Supplier Integration

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

Managed Services Supplier Integration

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.

Managed Services Supplier Integration

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

Managed Services Supplier Integration

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.

Managed Services Supplier Integration

Platform Request Application Development Team & Management Host Business

Dev User End-User

Platform IT Self- Incident IT Self-Service Solutioning PR Team Request Requirement Service Portal Portal Incident Vendor Problem ManageMe Request AD Access MIM Portal Orchestration Change Portal Interfaces Configuration PaaS Provisioning

Vendor Business Office

Vendor Project PaaS Team Units

Systems Host Vendor Integration 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.

Managed Services Supplier Integration

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.

Managed Services Supplier Integration

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

A Above the line • Host must govern, 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.

Managed Services Supplier Integration

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:

Managed Services Supplier Integration

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

Managed Services Supplier Integration

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.

Managed Services Supplier Integration

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

Managed Services Supplier Integration

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

Managed Services Supplier Integration

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

Managed Services Supplier Integration

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.

Managed Services Supplier Integration

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.

Managed Services Supplier Integration

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

Managed Services Supplier Integration

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

Managed Services Supplier Integration

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.

Managed Services Supplier Integration

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.

Managed Services Supplier Integration

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)