In my earlier post, I explained what Service Integration & Management (SIAM) is, and why it’s suddenly taking on more prominence in the industry.

In this second instalment, I shall explore who can perform the Service Integrator role.

I last spoke publicly on this subject at the itSMF UK Conference, where I presented on my experiences of Implementing SIAM in the real world. I touched on the subject of who could perform the Service Integration function, and this really divided the audience. Let’s break down the options, and in my opinion, the pros and cons of each.

1) Service Integration delivered by an existing vendor

Many of the big sourcing vendors are making a big Service Integration play, and my conversations with some of them give the impression that many see this as a strong revenue stream in the future. But I would urge caution to CIOs here, because I’ve seen some big pitfalls of this approach from a customer perspective.

My first concern here is that Service Integration is rarely big enough in its own right for a vendor to be interested in it as a single contract. So, you have to bundle it up with another service tower (networks, data centre, application support, etc) or with the Service Desk contract.  In my view, the SI function needs to fulfil an independent role, and if it has another service tower to deliver the vendor will certainly have a conflict of interest in keeping to their contractual commitments and having to play the independent arbitrator role. I simply cannot see a way around this.

You could, of course, give SI to the Helpdesk vendor, but again I have misgivings about this for the same reasons outlined above. They have a critical service to deliver, and I don’t see how they can also independently arbitrate over the end-to-end service, delivered by multiple vendors, and readily admit when they are in the wrong.

Also, I would say that one of the key roles of the SI function is to produce consolidated business facing reporting, and to facilitate this we would need to get multiple vendors to share their data with the SI vendor. In my experience, this is easier said than done, as there are often political and contractual issues which prevent some vendors from wanting to share their underlying data with anyone else.

2) Service Integration delivered by a new vendor

Just one simple question here: Can you find a vendor who would be interested in delivering just SI on its own?
I recently got involved in a vendor selection project for SI, and I recall that we really struggled to find a vendor who was just delivering SI services, not combined with any other service, to a global client base.
I think that this is due to a lack of maturity in the market and I am hopeful that we will see more evidence of this in the future. I’m not disputing it’s happening today, but merely it’s not happening in huge volumes or on a global basis, from my vantage point.

3) Do-it-yourself

As you may have guessed by now, this is my favoured approach.
I think if you are looking for independence, objectivity and customer focus, there is nowhere better to achieve this than with your own in-house teams. Many organisations are coming to the same conclusion, and I am aware of lots of Service Integration development going on to build SI as an internal function.

The benefits of this are:
– The customer designs and operates SI to their own specification
– The customer owns the Service Management tool (I think this is critical for having a “single version of the truth” for all Management Information)
– The customer owns the delivery resource, and they have no other motives other than to deliver excellent service to the business. After all, they will own the SLAs against which these services are being delivered, and they will want to ensure that SLA failures can be attributed to the respective service contract failure.
– There is no risk of service performance issues being masked by a vendor desperate to preserve their “Sea of Green” service performance report and avoid contractual penalties.

Doing SI internally also facilitates some other key deliverables of a good SI function, such as:
Arbitration over incident/problem ticket ownership
Assessment and authorisation of proposed changes
Prioritisation and scheduling of releases
– Production of truly business focused service reporting which shows how IT supported the business in delivering its business processes
Consolidation and aggregation of capacity and availability data from multiple vendors to produce business focused forecasting and reporting

In my next blog, I shall address some of the Service Integration implementation issues, focusing specifically on the mystery of the Service Catalogue!

To find out how we help organisations like yours design and build highly effective operating models, read our ultimate guide to Design + Build.