Are you getting stuck in the blame game?

Service integration is becoming more common with the increase in multi-sourcing, hybrid-cloud and off-shored services. There’s a growing need for organisations to have a service integration and management function, either internally or externally, to avoid getting caught in the blame game. This paper explains the different service integration models available, what the responsibilities are, and how to plan for success.

As a modern CIO, you are likely to be managing a number of suppliers delivering services, or components of a service, that make up your whole IT service estate. It wasn’t always like this. In the past, CIOs and IT managers were responsible for delivering services end-to-end, internally. Some would suggest the pendulum has swung and that we are returning to those insourcing practices, but it simply isn’t true. Multi-sourcing is in fact on the rise. The annual study, IT Outsourcing Statistics 2012/2013, reported that the number of U.S. organisations outsourcing application hosting, for example, had increased by nearly 37% year-over-year (Computer Economics, 2012). The booming “as-a-service” subscription economy is an obvious reflection of how organisations and managers are approaching decision-making and procurement. Modern managers are operating in leaner, more agile work environments and vendors are responding by allowing shorter contract lengths and more flexibility.

Service integration (SI) is the art of tying service components and supplier teams together to provide services to the business in a seamless manner. It involves managing the vendor relationships and hiding the complexities of integrated service delivery from the consumers of those services. Success is focused on outcomes, and service level agreements (SLAs) are the means by which multi-vendor sourcing is managed and measured.This paper explores the different service integration models, and explains the responsibilities of the service integration and management function (SIAM) and how to find success.

“You can delegate responsibilities…but you can never outsource accountability.”
– Lt. Colonel (Ret.) Rob Waldman

Outsourcing is on the rise!

Of course, software isn’t the only IT service being outsourced. Infrastructure, management functions and service desks can be outsourced too. CIOs and IT managers have more choice of suppliers than ever before. The increase in competition and flexibility is what motivates organisations to outsource IT service components, and outsourcing and off-shoring are growing at fast rates, because of the resulting cost-efficiencies. With IT departments challenged to do more with less, hybrid IT and cloud computing solutions are now a significant part of the enterprise ecosystem. IT management is becoming less of a gatekeeper role and more of a brokerage and co-ordination role, as Gartner confirms in their Top 10 Strategic Technology Trends for 2013. However, while outsourcing may achieve a reduction in responsibilities, it doesn’t equal a reduction in accountability.

Pitfalls

A primary challenge of service integration is ensuring that you are realising the full potential of your mix of vendors, but you must also consider the inherent risks, just as you would if you were responsible for delivering all services in-house. Is one supplier’s potential downtime a risk you are willing to carry, or will you need to consider paying a secondary supplier to be on standby? As well as the financial considerations, you also need to manage the expectations of your customers, users and each of your vendors. It’s not easy and things can, and do, go wrong. What do you imagine happens when a service failure breaches SLA; or a vendor sends sub-contractors that don’t turn up; or corrupt data ends up in reports? Unfortunately, it’s not uncommon for organisations to become embroiled in the blame game. We’ve had two major industrial organisations in Sweden outsource some of the service management, including a significant amount of service integration. In their minds, they expected a prime vendor scenario. In practice, they each contracted a guardian. However, with none of the rigour in place, they have both been left to do the service integration themselves (or to pay for external help).

The service integration models

Before we take a close look at each of the service integration options, we should point out some things you need to consider before making a choice. First of all, you’ll need to understand the level of process maturity of your operations, as well as that of the vendors. Secondly, how well defined and documented are the contractual positions with each of your vendors? That includes service descriptions, operational level agreements (OLAs), SLAs, and pricing mechanisms.

Type 1: Retained integrator (Client responsible for service integration)

Your first option is to build and maintain your service integration function internally. You’ll be able to directly control the component delivery teams and their performance. This option also allows a direct prioritisation and transparency of all service integration activities. The challenges include building a relatively small specialist capability that may not be close to your core. Moreover, the demand for the service integration function will vary over the sourcing lifecycles and as the process maturity improves, so you may have trouble from time to time justifying any ongoing costs related to dedicated staff.

High visibility of supplier performance Price competition Leverage each suppliers competence area Disadvantage: Customer risk in operational responsibility for the total sum of services delivered Risk in detailed investigation to determine which vendor has failed

Type 2: Third party (Integration is delegated to an independent third part)

The second option is to have an external party, which does not have a component delivery responsibility, to manage service integration. There are many vendors with strong process management capabilities built on recognised frameworks such as ITIL and COBIT; and by choosing a third party, you’ll avoid the bias of a supplier with component delivery responsibilities. The benefit lies in having SI expertise available on a more flexible basis, allowing your staff to focus on the strategic sourcing of the vendors, the tactical operations, and business-as-usual. However, this model requires managing one additional vendor and their delivery.

Specialist vendor focus entirely on integration Would be perceived as fair Reduce retained organization Disadvantage: Risk in delegate service integration. Need complex contracting

Type 3: Guardian (Single vendor responsible for service integration)

The third option is to ask one of your component providers to deliver service integration across all delivery teams and vendors. The benefit is similar to the third party option, and this arrangement is appealing to those organisations wishing to work with one vendor in the spirit of true partnership. The more skeptical, however, would disagree. How will your guardian vendor manage its own delivery fairly, compared to other vendors in your sourcing mix? It could become a complicated relationship, with competition already built into the intent of multi-sourcing. The guardian model also requires focus on two additional areas:

• The SLAs, OLAs, and delivery processes will need more rigorous definitions and details. They are best defined up-front, or at least very early, because an evolutionary approach may introduce debates when each vendor tries to optimise their delivery.
• The commercial ownership and management could become a battlefield for scope and responsibilities disputes.

Each vendor has contractual responsibilities Retained org can focus on strategic issues Disadvantage: Customer still need to maintain multiple contract and vendor relationships

Type 4: Prime Contractor (Single vendor accountable for all services)

The final option is to ask one of the vendors to accept full operational responsibility for service delivery, thereby becoming the prime vendor. This transfers all aspects of contract management to the prime vendor. Naturally, the concept of a prime vendor SI relationship introduces a commercial challenge, but good examples do exist—Shell is one of them. The benefits to you involve simplifying the IT sourcing function, so that in-house operations teams can focus on providing good service to the business. As you might imagine, there are drawbacks to the prime vendor model

1. The setup and implementation requires compliance with the prime vendor’s way of working, and most other contracts will need to be rewritten to accommodate the change in responsibilities and the required collaboration with the prime vendor.
2. In the long term, this relationship will eventually look and feel like single sourcing. The service and operational knowledge, and the ability to benchmark service delivery, may diminish over time, especially if you step too far back from the management and governance responsibilities.

Single interface customer Clear responsibility for SLA Disadvantage: Supplier have not strong capabilities in all areas. Commercial lock-in and inflexibility. Low transparency.

Responsibilities of the Siam

Distancing yourself from the management of service integration by involving a third party or component provider does have its benefits. You’ll be able to reclaim time for other operational duties, especially where resources are in short supply. You’ll also save on the energy required for the multitude decisions that occur over the sourcing lifecycle. External SIAM forces you to make the bigger strategic decisions, thereby avoiding becoming bogged down in more trivial decisions that so often consume too much time and attention. Regardless of the model, the SIAM function has significant responsibilities to reap these benefits:

• It must define service management processes and procedures that apply to all internal and external services to ensure consistent and seamless delivery.
• It must understand demand and supply to be able to forecast and co-ordinate capacity planning for cost-effectiveness.
• It must be active in change management and disaster recovery planning, ensuring all internal and external suppliers adhere to requirements.
• It must enable flexibility for the business and vendors through uniform and solid processes, governance and support. The centralised management means providers can be introduced or retired without disruption to business activity.

Achieving successful service integration

There are a few considerations to make to continue to operate successfully in a multi-sourced environment. We can’t stress enough, how important it is to plan for things to go wrong. Budget for and build resiliency into your partnerships and processes. You also need to allow resources for process improvements, vendor integration discussions, and contract adjustments to cater for the ever-changing service landscape. As a summary, here are the steps to go through for your SI model.

1. Define the standard service delivery model
2. Understand and clearly communicate the responsibilities, scope and handover requirements between component service delivery teams
3. Monitor and control service performance
4. Allow resources for deviations
5. Clearly communicate service expectations
6. Control and optimise cost

Ultimately, the guiding principles are pragmatism and a fit-for-purpose approach. SIAM requires an understanding that maturity levels will differ across suppliers and within the service model, itself, and then accounting for that.

Conclusion

The experience, at least in Nordic markets, is that few organisations have the contractual security and process maturity in place to allow a guardian or prime vendor to successfully manage their service integration. If service integration management isn’t a core competency of your organisation, involving an independent third party is the best step forward. In any case, be aware of the responsibilities of the service integration and management function, so you are well placed to see the rewards and avoid the pitfalls. It is our hope that this paper will help you do that.

Download the whitepaper

Peter Wahlgren
CEO 3gamma
peter.wahlgren@3gamma.com

Aprill Allen
Speaker, author, IT knowledge management consultant
Knowledge Bird
aprill@knowledgebird.com