SIAM and SLAs

How far should your organization take service level agreements in a service integration and management world, i.e. what’s the need for SLAs in SIAM? SIAM is when an organization adopts a multi-vendor sourcing approach to IT services. This approach requires the creation of a new service management function – a SIAM function – with this having the ability to span a multi-vendor environment and integrate the services provided by these vendor “towers” into a set of end-to-end service outcomes.

With more organizations seeking to take a SIAM approach, an organization’s service architecture model must be well understood. In other words, the services provided by the third-party service providers, the SIAM function, and internal service providers work well together to form a coherent whole. And, importantly, that all understand this need.

Creating a service architecture model

A service architecture model is required to achieve this. This model not only shows the topology but also describes, at a high level, the services provided by each of the vendor towers. From this organizational starting point comes the question of SLAs (plus operational level agreements (OLAs) and underpinning contracts (UCs) if your organization is still using ITIL v3/2011 terminology).

This area is fraught with pitfalls, in my experience, and there’s a risk of seriously over-complicating what’s required. This situation is typically due to various conflicting requirements from different camps:

◉ Legal teams – When a SIAM function is created because of multi-vendor sourcing activity, the various legal teams of the parties involved will work together as part of the deal. However, their low appetite for risk (and some would say, high appetite for fees) will place a heavy emphasis on OLAs and contracts not only between the SIAM function and their respective vendor tower but also between the towers.

◉ The SIAM function – The SIAM function, as custodians of the services, will want – and maybe need – to create SLAs with the business. This “want” is highly commendable, but to develop these it could be argued that they first need to obtain a statement of service capability and performance from each service provider, be they internal or external, in the supply chain.

◉ Service providers – The service providers, both internal and external, will want to avoid being involved in a lesser-known ITIL process – “blame management.” The service providers will want to ensure that their dependencies on others in the service model are called out. This is usually achieved via a contract or OLA. It’s typically defined within the “ops-book” or “service manual,” which accompanies the contract as a practical set of day-to-day operational guidance.

◉ The customer – This is perhaps the most important stakeholder in the service model. But sadly, one that’s often overlooked. I should have placed them at the top of this bulleted list, not the bottom! The customer might be skeptical of the perceived restructuring and reorganization (in IT) that comes with the revised sourcing arrangements. Consequently, they’ll want or need reassurance that the new service will be reliable and available, plus able to deliver the business operations and outcomes it enables.

Bring this around to SLAs in SIAM: The customer will want their SLAs tied down, and tied down very tightly. So, where do SLAs too often go wrong?

Common SLAs in SIAM issues

First, the SIAM function will likely listen to everyone’s requirements and then try to accommodate them all. However, without a service model in place to verify them, there’s no “sense-check.”

Second, in their keenness to make a good impression, the service providers decide to start engaging directly with the end customer. This engagement undermines and bypasses the role of the SIAM function when the service provider exposes too much of the service’s “inner-workings” to the customer. This approach usually opens up lines of communication and escalation that the SIAM function would prefer to be firmly closed!

Third, the service model is drafted “on-the-fly” – where multiple workstreams for developing SLAs, OLAs, underpinning contracts, and other documentation are initiated in parallel.

And what happens to all this SLA documentation?

It’ll likely sit on a shelf, gathering dust even if it gets finished. It might also be missing a supporting governance model that ensures all understand the report requirements, meetings, and rules of engagement. However, commonly the “SLAs in SIAM project” never gets finished because it’s just too complex.

It’s why we recommend that organizations developing or sourcing a SIAM function need to first define their service model end-to-end. This model describes the relationship between the many parties and the services provided by each. This model can then be used as the basis for prioritizing the most important documents and their contents – the ones that will add the most value to the SIAM ecosystem. Those that don’t will be created in a later phase.

The best piece of advice I can give anyone on SIAM service models is “keep it simple.” If you can’t describe your service model to the customer, or even your parents, then you’ve overcomplicated it! This complexity will then adversely affect your SLAs.

Source: itsm.tools.com