SLAs are not as widely applicable as ITIL would have us believe. The Catalog is.
SLAs work in large siloed formal organisations such as ...oh um... big British mainframe sites of the 1980s. This is a prize example of the cultural bias of ITIL and how it is non-representative of the broad user base it purports to appeal to. The Service Catalog is a better central mechanism, and SLAs should be an optional addendum.
A recent comment was dead right about the limited appropriateness of SLAs. Abigail said
"SLAs may work best ...in corporations, particularly those which have a cultural bent towards robust documentation, like maybe Big Pharma. However, in other types of firms (and specifically those in which you don't have a defined CEO type of role, such as in the case of Partnerships, e.g., legal or accounting services firms) I don't think it's either as feasible, or a particularly good idea. "
Absolutely. Some cultures do not readily accept formally negotiated contracts, and the "us and them" structure is actively counterproductive in some organisations.
But tell that to the authors of ITIL. This isn't just a case of adopt and adapt. SLAs are a fundamental part of the ITIL structure. They are used everywhere to define the responses of processes, to define and measure OLAs and UCs, and as the benchmarks for service performance.
There needs to be a more general mechanism in ITIL, and there is: the Service Catalog. Instead of being a tiny throw-away mention on one page of the blue book, the Catalog should be the centre of the ITIL world (not the Service Desk tool or - spare us - the CMDB).
The Catalog drives the early cultural change of the IT people. It is their touchstone for what does and doesn't matter as they find their way through the new world of service management. It gives them something to align to.
There are two levels of Catalog: the brochure and the technical document. In brochure form, it gives the CIO and Service Delivery Manager something to show users as a tangible illustration of what they are on about.
In technical form, the Catalog defines all the service level objectives that eventually end up in the SLAs, if you have SLAs. But objectives can be mere attributes of a service definition and be arrived at by whatever mechanism the organisation chooses - they don't need an SLA.
The Catalog defines all the service targets for the ITIL processes. It prioritises the services for the ITIL processes. It documents the key dependencies (yeah yeah: "or the CMDB does" if you are nutty enough to attempt one).
Finally, the Catalog is the thread that weaves all the technology together. If you are going to federate data into a CMDB (somehow) it will be via the service objects as the common element. The service is one of the highest objects in a service management hierarchy: all tools will consolidate data up to a service view, or draw inference and information down from the service.
If you must have SLAs, start from the Catalog: Once the technical Catalog has enough body to it, you can extract the SLAs from it and take them to the business.
But first, make sure you know what you can emasure, what levels of those measures you are achieving now, what levels you can achive and at what cost to get there. Only then are you ready to have an intelligent conversation with the business about service levels - using SLAs as a framework for that conversation only if that is culturally appropriate to your organisation.
The Catalog is the singularly most important object in service management, and SLAs are a non-essential addendum to it. But ITIL doesn't see it that way and that is solely an artifact of the narrow culture and hence limited IP base from which it was (and still is) drawn.