I’m currently working with a client to help improve their processes using ITIL as a guide and benchmark. We started with a maturity assessment and used the results to identify major gaps (as defined by business value, not ITIL’s textbook). Serve Desk and Incident Management were two of the key foundation areas for improvement, so we started there first.

If you’ve worked with ITIL much, you know it didn’t take long for challenges to show up. Specifically, one of the key requirements of a good Service Desk is enforcing the defined SLAs and OLAs - as defined by the Service Catalog. Well- this client doesn’t have a Service Catalog. Not yet, anyway. So we had a long series of conversations about “What is a Service Catalog?” and “How can we define a Service Catalog that supports the business?”

The key, I believe, is to look at everything from the business’s perspective. The CEO of the company wants to receive a relatively few services from IT. Things like email, internet and core application availability. As a shortcut to finding out which services are really key, take a look at your disaster recovery plan. The services they you restore first are, by definition, most critical. So you could start with your highest priority services (as viewed by the customer) to define your basic Service Catalog.

Of course, there’s a lot more to it- like SLAs and OLAs and Underpinning Contracts. And now we get to the catch: How can you define realistic SLAs if you don’t understand all the underlying infrastructure that supports a service?

Let’s take email for example. From the business perspective, it’s simple - they want to be able to instantly, always send and receive email. Behind the scenes, that requires a wealth of infrastructure and resources - servers, applications, spam filters, firewalls, network gear, ISPs, administrators and on and on. How hard would it be for you to complete this list for your environment - and keep it complete and accurate at all times?

Pretty hard, I suspect, if you’re like most medium and large IT shops. The rate of change is simply too high, there are too many people involved and there is no single place where the information is stored. Now you see why the CMDB is a critical underlying requirement for true, solid SLAs and OLAs and, ultimately, a real Service Catalog.

Sure, you could do what many shops do and simply ‘declare’ some SLAs that you know you can meet. But what does that accomplish? For one thing, it’s only a matter of time until the CIO or CFO or CEO starts asking, “How much would we save if we reduced our availability SLA for email from less than 15 minutes per outage to less than 60 minutes per outage?”

Here’s why that’s important: the business will always seek to optimize its investments in IT, and as service providers, it’s our responsibility to have good data and solutions to help them do that. If you don’t have this information, you’re guessing. Executives don’t like guessing.

Also, check out our new White Paper on “How To Develop a Service Catalog”.

Till next time, keep up the good work.

Scott Braden

Technorati Tags: itil service level agreement help desk

—–