During the 1990s I had a recurrent conversation with clients that went something like this:  “We need your help selecting a new Service Desk tool.  Originally we had tool X but that did not do what was claimed and so we replaced it with tool Y and that’s no use either.”

It didn’t take me long to realise that either (or indeed almost any) tool would have worked for them had they first properly defined their requirements and performed an appropriate implementation, just as they would have done for a business application.

I have been reminded of this several times lately when talking to clients about introducing Service Integration.  They want to talk about the tooling, about what is ‘best of breed’, whether they should buy them themselves or use those of a provider and how to integrate them.  In one or two cases they have already taken out a subscription to a Cloud-based service management tool. 

Service Integration is a subtle concept, still immature in the market and not widely understood.  Perhaps it is unsurprising that there is a tendency to focus on something as tangible as  toolset.  Unfortunately, as in the case of the Service Desk tools that I mentioned, it is unlikely to deliver the desired benefits.

An appropriate Service Integration model has to be designed in the context of the desired outcomes; the data needed to measure that those outcomes are being achieved can then be identified and tools configured to generate that data.  Data and process touch-point specifications can be shared with the other service providers in the Ecosystem and the overall integration is thus accelerated.