In the time I have been working in providing ITSM solutions to a multitude of clients, there is one constant that seems to cross all manner of industry, size, and maturity. The Service Catalog is far and away the most likely missing piece of every IT organization’s puzzle. Recently, my colleague Amanda Casteel discussed the importance of this vital link in the IT Business Relationship chain by providing concrete ways having a Service Catalog helps the overall relationship, and enumerating the many ways a well-understood catalog can show the value IT brings to the business at-large.
How Many Services Should be in Your Service Catalog?
This is a very subjective question, and it does tend to vary from organization to organization, but one thing it is very important to remember is that too many choices lead customers to make bad decisions – or even worse, no decision – when requesting services. Additionally, when you provide a massive menu of services to your end users and/or customers, chances are many will assume your Service Desk can accommodate a lot of variance from what is listed. And then you have begun a painful, likely back-breaking journey down the path of doing many tasks that either should belong to another part of the organization or should not be done at all.
So, when tasked with designing (or overhauling) a Service Catalog, keep it as simple and straightforward as possible. At least for those services you wish to expose to the business (there are different types of Service Catalogs, and you can use that concept to rein in the amount and type of work you are providing), try to keep the total number of top-level Services to 15 or fewer. If you bleed over, never fear. No one is really keeping count. This is just a reasonable number to start with, and you will likely make many changes before the final catalog is released.
How to Structure a Tiered Service Catalog
“But,” you may say, “My Service Desk provides many more than just 15 services. How can I just eliminate things from the catalog?” Catalog construction is a key component in being successful while still providing your customers a reasonably scoped list of services. A top-down approach is the generally accepted method for this. Most ITSM tools provide a hierarchy of catalog classification in some form, often in a three- or four-tiered approach like this: Line of Service; Service; Category; Sub-Category.
Lines of Service can be very useful when placing services under specific ‘umbrellas’. This is especially true in very large, diverse IT organizations where top level services may be clustered together, but vary wildly in scope otherwise. The key here is to push the specific offerings further down the chain. So, instead of listing applications as services (this is one of those rabbit holes that can balloon a catalog beyond manageability), push them down into a lower tier, or eliminate specific applications from the catalog altogether, providing them as a list to be selected upon request. A classic example of this is to start listing out every enterprise application in the company as individual services: Exchange, Active Directory, JD Edwards, etc. Rather, make these part of a more general Service type, such as (drum roll) Enterprise Applications. Most end users and customers want a simple interface to deal with, not a labyrinth of irrelevant application names and terms. When I need something to do with authentication to my computer, or a server, or a specific application, chances are I’m going to look for something like ‘Account Management’ in the Service Catalog. A sea of individual account management related services would likely just cause me to dial the Service Desk directly. And that is a problem, since our goal is to reduce the number of direct contacts by providing an easy-to-understand Service Catalog.
Simplicity is really the key to a successful Service Catalog implementation. The Service Desk may provide a multitude of value-added services to the business, but the business understands these in much more general chunks of information. E-mail is a great example of this. If I were to add every component of the E-mail service to the business-facing Service Catalog, the Service Desk would probably receive more calls about what each component means or does than they would about actual E-mail requests/incidents. It is very doubtful that normal end users care what kind of mail server is used, let alone all of the server components and databases that make up the underlying system. They really just want to ensure e-mail gets sent and received reliably. If it doesn’t, those same users are going to want to submit an incident to the Service Desk that calls out ‘Corporate E-mail’ as the service, not ‘Exchange Server (MSSQL) SMTP’. Nobody knows (or frankly cares) what that could mean.
There is no magic number of services to be placed in the Service Catalog, but if the Service Desk is struggling to keep up with the wildly varying types of requests, and customers are constantly calling to have the Service Catalog explained, chances are it is too large. When discussing design on this level, I have always tried to live by the following quote, perhaps it can help guide your efforts, as well:
A designer knows he has achieved perfection not when there is nothing left to add, but when there is nothing left to take away.
—Antoine De Saint-Exupery