The 2 Most Common Service Catalogue Issues … (And What To Do About Them)
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.
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.
Over the next few weeks we’re holding a series of seminars in central London, and we’d love for you to come along. The seminars will be hosted by Chris Hodder, one of the leading experts on service catalogue design, and a real ITSM veteran (we’re not kidding, he’s worked with government and health organisations all over Europe, not to mention Barclays, JP Morgan, BskyB, and more).
But here’s the thing. In order to attend you MUST bring at least three interesting service catalogue questions or problems which Chris will help you solve there and then.
Not sure what problems to bring? Well, so far we’ll be covering topics such as:
- How to decide on the initial “scope” for your CMDB design
- How to maintain your CMDB using Change Management
- How to maintain relationships in your CMDB
- How to manage your myriad of CMDB data sources
There will be no cost to attend, but don’t let that fool you — Your investment will be in prep time. We want you to bring along your real life examples (data, processes, etc.) so that we can work through it “live” during the session.
If you’re interested in attending, click here to register… but don’t delay, places are very limited and will be allocated on a first-come, first-served basis.