SearchCIO.com recently asked ITIL Chief Architect Sharon Taylor and IT service management (ITSM) specialist Pierre Bernard to address some common questions we get from CIOs about the IT Infrastructure Library
In this companion interview, we explore the fundamentals of the IT service catalog with David Cannon, co-author of the Service Operation book in ITIL version 3, and head of the ITSM practice at Hewlett-Packard Co. When SearchCIO.com reached him, he was busy updating the Service Strategy book for ITIL version 3.1. ITSM and the IT service catalog are foremost about service, he explained. In the 1960s and even into the 1980s, professionals who thought about managing IT often borrowed from concepts applied to manufacturing environments, such as the assembly line, he said. In his view, a more apt analogy is the restaurant, which presents a menu to customers and on any given day, must be prepared to respond to their demands adroitly. Here is a condensed version of the interview.
What is an IT service catalog?
Cannon: When we talk about an IT service catalog, we are really referring to two things. One is the list of services that we provide to our customers. It is like a restaurant menu.
The second part of the service catalog is that you really have to know how to deliver the services in the catalog. So, if you look at the catalog as the front end, one position behind the catalog is a list of what it takes to deliver the services. In the restaurant analogy, that would be the ingredients and the recipe. In IT, it is the same: We need the service, we need the network, some sort of middleware, applications and so on.
So, when I in IT am providing a specific service, I can look behind the service catalog and say, "Ah, the customer has ordered one of those; in order to deliver that, here is what I need to be able to do. These are the components I need, these are the processes I need to follow, these are the people I need to communicate with in order to do it."
Where do you advise companies to begin when building an IT service catalog?
Cannon: The very first thing -- and this is not as easy as it sounds -- is to list services that you think you are providing. You don't need a sophisticated tool to do this. You can do it in a Word document or Excel spreadsheet.
Here is why it is more difficult than it sounds. When you speak to different people in the organization, they all think about the service somewhat differently, and they all call it something different. So, if you go and speak to the application developers, they will give you the names of applications and tell you, these are the services we provide. When you go and speak to the users of those applications, very often they do not know the name of the application. They'll say, "Oh yeah, we use a service that prints this monthly report." And they call the service by the name of the monthly report. You go to the application guys and ask them how they manage the monthly so-called reconciliation report, and they say, "What? We don't do that!"
It is further complicated because sometimes a service is a combination of applications. To get one service -- for example, to print a price list -- you may need to access five different warehousing systems or distribution systems to get the information needed for a single report. In other cases, the opposite is true. One application provides several different services, because each user uses the application differently.
Do you find that most organizations need outside help to do this?
Cannon: Yes, they do. The simple reason is, most people inside the organization are within a particular unit, and it is very difficult for them to stand outside that unit and look at the organization as a whole; whereas a consultant can come in and pick up pretty easily these differences between the units.
Should an IT service catalog be written from start to finish, or can you build it as you go?
Cannon: Build it as you go.
Establishing a service catalog is really not something you want to do in isolation. Establishing the service catalog should be closely linked to activities happening within the organization, such as when there is a change management process or implementation happening, or somebody is doing configuration management or implementing service-level management.
In many organizations there is a service management office, or SMO, which may take responsibility for the service catalog. Every time they launch a new phase of the ITSM implementation, they make sure they have got that ITSM catalog with them and are updating it to make sure it stays relevant.
Can the updating be automated?
Cannon: Yes and no. If the services themselves are automated, the organization can automate the updating of the service catalog. However, a lot of the services we provide are not in fact automated, and are dependent on manual interaction between customers and service providers.
Some people will give you a categorical answer: "Absolutely, you can and should automate your service catalog." But nine times out of 10, the services they are talking about are technical services. There is a theory out there that holds, for example, that [with] a database resident on a database server, the database server is providing a service to the database. But it is skewed thinking.
There are technical services, like the network, like application hosting, but those kinds of services should never be in a client-facing service catalog. You can put them in the layer behind that, but the customer should never be exposed to that, because it adds no value. The first thing a customer says when they look at all this stuff behind the scenes is, "Wow, that must cost a lot." And the first they want to do is cut their cost.
Do enterprise companies tend to begin with a particular set of services?
Cannon: Yes, they do. The IT group is very aware of the business-critical services and their impact on the business. So, they would tend to start with those.
I have also seen companies use projects that they are busy working on. They may not be business-critical, but because the project has funding and is uppermost in people's minds, they use the project as a starting point.
It depends on what is going on in the organization at the time. Both are good.
The CIO is in fact the service manager of the organization. If services are not articulated within the organization, the CIO is accountable for that.
David Cannon, head of the ITSM practice at Hewlett-Packard Co.
What is the role of the CIO in this effort?
Cannon: The CIO is in fact the service manager of the organization. The CIO is accountable for the provisioning of services, which enable the business to run its operations and maintain its competitive advantage. If services are not articulated within the organization, the CIO is accountable for that.
If I were a CIO, this would be one of the things on the top of my list. There are a whole lot of things that CIOs cannot do if the service catalog is not there. They cannot account for the spend of IT: They can tell you how much money IT spends, but they can't tell you why. They can't tell you the exact business value that was derived from that expenditure. They cannot prioritize the activity within IT. You have 300 projects going on. Which one is going to derive the biggest business value? Which ones can I cut? The service catalog, to my mind, is a really important information tool for the CIO.
How do IT service catalogs go awry?
Cannon: There are all kinds of things that go wrong. One is that people who are defining services don't actually know what a service is, so they end up with one of these situations where the database guy defines his database as a service, and the server guy defines his server as a service.
When the service catalog project is embedded in the technical groups, you generally find that while a service catalog may be helpful to their individual departments, it is really not very good at describing how IT provides services to its end users.
Let us know what you think about the story; email Linda Tucci, Senior News Writer.