Defining the Services you Deliver

This is a follow-up to Wednesday’s post about Service Level Management for Beginners. What I’m going to talk about now is how we might approach the creation of a Service Level Agreement (SLA), again assuming that you are a complete novice.

Please note, this is not the only way you can approach things, or necessarily the best way to approach creating an SLA. I’m trying to suggest ideas which those attempting this can use.

Define the Services you Provide

This is one of those things that sounds easy but often isn’t. Ask yourself what Services you provide to customers/end users, and try to document them. Examples might be:

  • Email access (local and internet)
  • Http (web) access
  • Accounts system

The difficulty in defining a Service is one of perspective. Do we use a customer’s definition – something meaningful that they use – or adopt a provider view where the components of a service is considered a service in its own right? I’ll illustrate by example. Suppose you have an accounts system delivered (say) by Windows Terminal Services. For it to be used you need a working software system on the server and a working network infrastructure. Does that equal one service (‘the accounting system’) or two (‘the accounting system’ and ‘the network’?).

The ITIL Service Delivery book (Pub. by TSO) provides a useful definition: ‘A service is one or more systems that enable a business process’. This puts the emphasis firmly on the user perspective.

Whatever view you take, define the Services you provide. Then add additional information such as:

  • The departments, customers or companies using the service
  • Number of concurrent users (just take an average)
  • Any 3rd-party (supplier) contracts that we have in connection with the service
  • Typical hours of use
  • Value of Service

The last one – Value of Service – is sometimes controversial, but something I’ve found valuable. Not all Services are created equal. The disappearance of some Services for a few hours causes inconvenience but nothing more, but failures on other Services cause immediate and widespread disruption to the normal operation of the enterprise. Typically I’ve used Critical, High, and Routine – but of course you can use a numbering scheme 1-5 or any other method.

You can store this in a matrix in something as simple as a spreadsheet. Alternatively, you can usually store this an a CMDB. In Serio, the ‘System’ structure was specifically created to allow you to hold this kind of information within the CMDB – and use it within things like Incident Management.

Those more familiar with ITIL and IT Service Management will recognise this as a Service Catalog.

Whatever comes next in defining our SLA, it’s useful to have information about what ‘the service’ is when we consider the requirements of the business.

I'll continue this thread next week.