Intro
Just how far should you take service level agreements in a SIAM world?
Service Integration & Management (SIAM) is the name given when an organisation adopts a multi-vendor sourcing approach. This approach requires the need for a Service Management function to be created, with the ability to span this multi-vendor environment and integrate the services provided by these towers into a set of end-to-end service outcomes.
As more organisations seek to adopt this SIAM approach, it is vital that the Service architecture model is understood. In other words, the services provided by the managed service providers, internal service providers and the SIAM function form a coherent whole and are understood by all parties.
In order to achieve this, a Service architecture model is required, which not only shows the topology of the model but also describes, at a high level, the services provided by each of the towers.
From this starting point comes the thorny question of Service Level Agreements (SLAs), Operational Level Agreements (OLAs) and Underpinning Contracts (UCs), as espoused in the IT Infrastructure Library (ITIL™)
My experience of this area is that it is fraught with pitfalls and risk of seriously over-complicating what is required.
This is typically as a result of a number of conflicting requirements from different camps:
- Legal – Typically the SIAM function is created as a result of sourcing activity and as such, the various Legal teams of all the parties involved will come together as part of the deal. However, their low-risk appetite, (and some might say, their appetite for higher fees!) will drive a heavy emphasis upon OLAs and contracts not only between the SIAM function and the respective tower but also between towers
- SIAM – The SIAM function will want to develop SLAs between themselves, as custodians of the service, and the business. This is highly commendable, but in order to develop these, it could be argued that they need a statement of service capability and performance from each of the Service Providers, be they internal or external, in the supply chain
- Service Providers – The Service Providers, again internal or external, will want to mitigate the risk of being part of a lesser-known ITIL process – that of Blame Management[1]. They will want to ensure that if they have dependencies on anyone else in the Service Model, that this is called out. This is typically achieved in a Contract or OLA. In practical terms, it is normally defined within the “ops-book” or “service manual” which accompanies the contract, as a practical set of day-to-day operational guidance
- The Customer – And then we come to perhaps to the most important stakeholder in the entire service model. The one who is often overlooked. I apologise for placing them at the bottom of my list; they should absolutely have been at the top!!
The Customer, perhaps sceptical of this perceived restructure and reorganisation in IT as a result of the revised sourcing arrangements, will want some reassurance that the live service will be reliable and available, and able to deliver the business processes it enables.
The Customer will want their SLAs tied down very tightly indeed. So, where does it all go wrong?
Firstly, the SIAM function listens to everyone’s requirements and tries to accommodate them all. Without a Service Model to verify them against, there is no “sense-check”.
Secondly, the Service Providers, keen to make a good impression, decide to start engaging directly with the Customer. This effectively undermines and bypasses the role of the SIAM function, as the Service Provider is tempted to expose too much of the inner workings of the service to the customer, and unwittingly opens up lines of communication and escalation which the SIAM function would prefer to be firmly closed!
Thirdly, the Service Model gets drafted on the fly. In parallel, a number of work streams aimed at developing SLAs, OLAs, Underpinning Contracts and all manner of other documentation is initiated.
What becomes of the documentation?
Well, in rare cases it gets finished and sits on the shelf. In some cases, it is bereft of a supporting governance model to ensure that reports, meetings and rules of engagement are understood.
Most of the time, the project never gets finished, as it’s just too complex.
Organisations looking to develop or source a SIAM function, need first to define the Service Model, end-to-end, which describes the relationship between the various parties and the services provided by each. This model can be used as the basis for prioritising what documents are important, and which will add value to the overall SIAM ecosystem. Those which don’t can be developed in a later phase.
The single most important piece of advice I can impart is “Keep It Simple”. If you can’t describe the Service Model to your Customer, or even your mother, you’ve overcomplicated it!
[1] This is not really an ITIL process and is included here in a poor attempt at humour!
