There are hundreds of ways for a service catalogue implementation project to fail spectacularly.
We’ve seen them all.
From local government to big business every industry has its own peculiar stumbling blocks, and trying to list all of them would be almost impossible.
But there are two issues in particular that come up time and time again. Nearly every organisation attempting to implement a service catalogue runs into them, so we thought it was about time we addressed them once and for all.
Service or CI?
Confusing services with configuration items is without a doubt the single most common issue with service catalogues.
And if you’re yet to start your service catalogue implementation project that might seem odd. After all, how hard can it be to tell them apart?
Just in case you aren’t familiar with these terms, the difference is seemingly quite simple. A service is an outcome that enables some aspect of your organisation to function. Email is the most commonly cited example of a service, and it’s easy to see how removing the email service from your organisation would cause significant issues.
A configuration item, on the other hand, is a component which (usually in combination with other CIs) makes up a service. For instance, in the case of email, an Outlook Exchange server might be one of the CIs that facilitates the service.
In organisations where these two separate elements are confused, service catalogues often become nothing more than a list of assets and applications, rather than a record of employee or customer facing services. As a result, an unhelpful focus can be placed on fixing issues with specific assets or systems, rather than the overarching services that are essential to the organisation’s primary functions.
But it seems pretty simple, right? Services and CIs are quite clearly different things, so why do people get them confused?
And the thing is, it usually is simple to tell them apart. The problem comes when we start to consider more complex services, which can comprise dozens of disparate and otherwise unrelated assets, systems, and applications.
Take, for instance, a mobile telephony service. For a start, it’s not immediately clear what should be included. Blackberries and ‘dumb’ mobile phones seem obvious candidates, but what about smartphones? Or tablets? And what if your organisation makes use of VOIP services like Skype for Business? Does that mean laptops should be part of the mobile telephony service?
These might seem like unnecessarily complex questions, but they really aren’t. If mobile telephony is essential, and to many organisations it is, you’ll need to establish an SLA to guarantee uptime and incident/issue response times. After all, it isn’t the individual CIs that are important, it’s the availability of mobile telephony as a whole.
And if you think that’s complicated, just wait until you get started with industry specific services.
Ultimately, if you want your service catalogue to perform a valuable function for your organisation, you’re going to need to allocate the necessary resources to ensure your services are defined properly, and include the right CIs. Once that’s done, it will be much easier to understand what SLAs you can expect to deliver.
Chasing Perfection
At this point you’re probably thinking that implementing a service catalogue is going to take forever.
And you’re not wrong.
After all, you need to define every single aspect of every service your organisation relies on, and that’s going to take some serious time.
But the big mistake that nearly every organisation makes is assuming that everything must be perfect before go-live. In fact, if you try to do this, you’ll probably never reach go-live.
Apart from anything else, effective service catalogues are not simply written once and then left alone for years at a time. They’re constantly evolving.
New services and CIs come along all the time, and they need all the same documentation, processes, and SLAs that your existing entries have.
So rather than trying to include every single service from the start it’s a much better idea to go-live with a service catalogue that only includes the core business services upon which everything else relies.
Your company network, for instance, is a core business service. Every one of your applications, however critical, is totally reliant on your network, and without it they would be unable to function. There’s no doubt that financial or procurement systems are critical to your organisation, but your network should be considered more important from a continuity point of view, because an outage would affect nearly every aspect of your business.
Likewise your company email, desktop computing, and Internet connections are most likely to be core business services. Almost every electronic service your organisation has will rely on most (if not all) of these, so it makes sense to document these before moving on.
And it’s not just about their relative importance. If you don’t have your core business services documented first, it’s going to be almost impossible to define SLAs for your secondary services, until you have established the availability of the core services they rely on.
For instance, if you determine that your company network must be 100% available but only during business hours, you can’t then set targets for dependent services that require them to be available outside business hours. It seems obvious when put in this context, but believe it or not many organisations don’t distinguish between core and secondary services, and as a result they record wildly inconsistent SLAs.
But What About MY Problems?
If you’re about to (or have already) embarked on a service catalogue implementation project, you may already have come across the issues discussed in this post.
Unfortunately you’ve probably also come across a bunch of other issues that we haven’t discussed. If that’s the case, you may be interested to know that we’d already considered that eventuality.
If you’d like to learn more, call us on +44 (0) 208 050 3165
