Service Catalogs

Service catalog templates and examples

The number one Google query that points to this site and our community site are:
Service catalog template
Service catalogue template
ITIL Service catalog
ITIL Service request
etc, etc, etc.

To make it simple for every one. They are here:  Service Offerings & Service Requests - ServiceCatalogs

You will find blank service catalog templates for portfolio service offerings and for service requests. There are also filled examples.

Remember to contribute your examples to this community. You are welcome

ITIL V3: Service Strategies

Majid Iqbal, Senior Project Scientist, IT Services Qualification Center, Carnegie Mellon University (now with Gartner) gave a presentation at the itSMF Great Lakes Local Interest Group introducing the service life cycle concept.

ITIL V3 presentation.

ServiceCatalog versus Service Web Site

This is a great discussion at the community. I'm late posting, but it's so relevant and the answers are very thoughtful.

Best of the community at work.  ServiceCatalog versus Service Website (Free registration required).

Request Fulfillment - Managing Service Requests According to ITIL v3

I wrote this article for the ITSMf newsletter The Forum.

Request Fulfillment - Managing Service Requests According to ITIL v3

Today’s IT operations must deal with a multitude of application options, new mobility options, and the increasing demands of a continually connected workforce. Not only is there more technology per user, but the applications, devices, and options are more complicated than ever.

As a result, the volume and complexity of service requests – requests for everything from access to applications, to software enhancements, to computer upgrades, to email and network access – have expanded dramatically.  That challenge is compounded by the fact that each IT silo typically has a different system in place for managing requests.  Many large enterprises have dozens if not hundreds of different Web forms, intranet pages, Lotus Notes databases, and homegrown request systems.  This creates chaos and confusion for both the requester and the IT service teams.

The burden is often on the requester (or designated coordinators) to navigate through these disparate service request mechanisms, manage the various tasks associated with every service, and ensure that the request is ultimately fulfilled. And the service delivery teams spend an inordinate amount of time responding to requests, researching requirements, validating information, and providing status updates.

Figure 1: Typical Service Request Process = Complexity, Confusion, Complaints

The rest of the article is located here The Forum - 03/17/2008.

 

Service catalog templates and examples - Valentine edition

These are the top queries people are looking at this blog. So it seems you really want templates.

	Num	Perc.	Search Term
	45	1.64%	service catalog template
	45	1.64%	service catalogue template
	37	1.35%	service catalog example
	34	1.24%	product manager role
	34	1.24%	request fulfillment
	27	0.98%	itil service catalog
	26	0.95%	itil service request
	25	0.91%	it demand management
	23	0.84%	itil request fulfillment
	22	0.80%	service catalog blog
	22	0.80%	service catalogs
	16	0.58%	itil v3 service catalog
	15	0.55%	service catalogue example
	15	0.55%	service catalog templates
	14	0.51%	service catalog
	14	0.51%	service catalog examples
	13	0.47%	it service catalog template

So in the spirit of valentine, here's are simple gift. Service Portfolio and Service Requests templates are here:  Service Offerings & Service Requests - ServiceCatalogs (free registration required).

You will find blank service catalog templates for portfolio service offerings and for service requests. There are also filled examples.

Remember to contribute your examples to this community. You are welcome

Service Request Catalog: Strategic or Tactical? (part 2)

There are cases where you can achieve success with a tactical implementation of a service request catalog.

If your company is small enough, and you set your expectations appropriately you can get a tactical service request catalog project to work; particularly if it's a small deployment to your IT staff.  For example, the storage team may deploy a service request management tool for requests from the application development group.  This would be a sensible small project.   Keep it small enough and you can get some success; the issue I've seen is that the ROI is not there, so it's hard to get funded. 

The other way to succeed is to keep the catalog wide but super simple.  Here are a few tips:

• Use a tested accelerated deployment methodology. If you don't have to invent it, it will save you a lot of time. Your vendor should have one or your consultant.
• Use standard, pre-packaged content. This saves you from the laborious effort of creating descriptions, pictures, forms, data models, messages, portals, etc, etc.
• Keep complex scripts out of the first roll out. This enables you to use lower cost internal resources to maintain the catalog.
• Don't touch or change back end workflow.  In fact, it's easier if you don't integrate with the existing stuff.  You can always do that later.  This issue is even true for the "pre-integrated" vendors; the catalog products are separate enough from the back end that you end up with a field mapping exercise along the way, error messages, etc, etc.  Lots of discussion about the types of issues all over the net.

In other words, the faster and cheaper you go, the more likely you will succeed.  The problem with this approach is that it's not really doable at the Global 2000 enterprise level.  But it's doable in smaller organization, or divisions.

Finally, as you evaluate your catalog software vendor, you ought consider this:

When I'm ready to expand the scope of my request management deployment, will they scale with me - or will I need to migrate to another enterprise-class product?

When we are ready to do a Service Catalog compatible with ITIL V3, will it get me there or do I need to throw out all my work?  Can the service request definitions be used as components of my service portfolio to drive consumption and cost visibility? 

Good question to kick off the year

This question was asked on our community site here.
I've provided a interim response, not an answer. Please help Nigel out as this is a common issue.

Hi,
Just posting a few questions about the setting up a service catalog over four divisions in two geographic locations. I have renamed the divisions to A, B, C for simplicity and outline what country contains each division.

Country 1
Division A
Division B
Division C
 
Country 2
Division C
Division D

Up until now we have not had to worry about Country 2 too much,now I have been tasked with creating 250 services for Division D.  Division D will only be interested in ordering these 250 services, how would you present them to the customer?
 
Option 1
Top level of the catalog create a category for each division, then let them see a catalog structure underneath, possible cons with this is that there might be some of the Service Items quite a few clicks down as the structure is quite deep already
 
Option 2
Set ordering permissions at a service group level. This may be the best if the LDAP information is correct else but there will be a percentage that will have incorrect information and therefore will see the wrong services.(Still trying to estimate percentages, but its going to be over 20% after initial investigation)
 
Have people out there been in a similar position….?
If you were in a similar situation what would you choose…..?
Is there another way….?
 
Looking for any feedback
Thanks in advance
Nigel

My reply

 

What tool are you using to publish your catalog?  Some provide this capability. That would make a huge difference.

Some of the tools support Business Units, hierarchies, territories, groups, etc. So that makes it easy to publish a service offering to a particular group, territory, or any other grouping that you need. Common sub - groupings that I've seen are:
- VIP services only to VIPs.
- Datacenter services only published to App development groups.
- Business unit segregation due to cost, or regulation.

For example, if this type of structure gets connected to LDAP or Active Directory, then you don't really need to worry about managing that overheard. Unless, as you indicate, your LDAP structure is not right.  Then the answer is to create a separate database that brings it all into one source of truth. Our consultants are often required to do this because there's no single source of truth for people.  While this might not be your charter, you might get a lot of support because everyone needs this clean repository. 
Also, sometimes we have been able to discover that a group had solved it but just had not made the solution public -- worth an investigation.

If everyone in division D is in a different country, you could redirect their traffic to a specific landing page (got to write a script, though).  If not, then that's not going to work.

Regardless, you could just put it in a category (services should be able to be under multiple categories) and deal with it that way. The downside are:
1- Breaks your search
2- People get curious as to what the "other" guys get, leading to unpleasant discussions.
3 - Sometimes the terms and conditions vary leading to... very awkward conversations. For example, employee termination services are VASTLY different outside the U.S., with a lot less protection and benefits for U.S. employees. That is just a fact of law, but one that few executives want to publish in their internal catalog.
4 - Too many levels of hierarchy

An inventory of applications is not a catalog

No more than an inventory of the refrigerator is the catalog of a restaurant.
Applications or systems are viewed primarily from the point of view the maintenance and operations people. What those applications do for customers is quite another thing.

A New Model for IT Demand Management

More and more people are concerned about the growing demands on IT.

There are two categories of demand: planned and unplanned.

Planned demand arises as part of the annual planning process, which results in the "IT Plan" (which is what IT is supposed to deliver) and the corresponding budget for the next financial year. This would be the case for large, departmental or enterprise-wide projects which cannot be funded on-the-fly during the current budget cycle, but also for keeping the lights on.

Unplanned demand corresponds to the huge amount of unpredictable work that IT does which is not contained in well-defined project structures. These include things like change requests, feature requests and bug fixes which arise from changing business and regulatory environments, changes in strategy, company reorganizations, mergers and acquisitions, insufficiently tested systems, etc. Some of these requests will become input for the next planning cycle, but most will have to be done inside of the current budget cycle.

These distinctions miss a point... There are whole set of requests that are neither part of the "IT plan" nor are they unplanned.  Heck, 80% of the IT budget goes to these type of requests: standard provisioning and response requests.  They should be in the catalog. 

It's a nice article. But insufficient .

Link: A New Model for IT Demand Management.

It's about Requests not Incidents. ITIL V3 still give short shrift to requests.

As usual, I am in agreement with the IT skeptic. He writes:

Well put and long overdue that ITIL gets with the program. I was one many who were hopeful that ITIL V3 would get it right and give service request management the full respect it deserves. Instead, 'Request fulfillment' gets just over one stunted and stale page. As your article illustrates, the majority of operational workload and cost is as a result of the (humble) service request.

Our practical work has indicated that as much as 85% of the traffic hitting a 'service desk' operation is not related to a break-fix (incident) situation. The % factor between incident and service request for any service is proportional to the amount of 'customer hugging' designed into the service offering. As improvements are applied one might also expect the overall ratio between incidents and service requests to change and for requests to become the dominant items, as quality improves.

This maps to my experience. Of the top of my head, here is my classifications:

1. Many of the calls are service requests (30-40%)
2. Many are are status follow ups to those service requests (15-30%)
3. There are escalations because of failed service requests (some %). These are painful and very time consuming.
4. Often not counted in help desk statistics are the number of outbound calls (e-mails, etc) from the help desk to silos, app. dev, following up on what happens.  Don't believe me?  Check out the tale of the traveling laptop. Count the number of people, and interactions. Now add the cost. It's more than the cost of the laptop.
5. Some amount is also "shepherding" the little service requests so they don't fall into black holes and get lost.

My only difference is this may not even be about the service desk.  With the proper tooling, many of our customers bypass the help desk entirely: They go from self-service configuration to automated provisioning -- never passing through help desk hands.  And yet others, still keep the catalog but outsource the service desk.  If this is the case, then we need to think of the service request catalog as separate from the service desk: it could be there or not. More and more, the answer is not.

Link: When will ITIL wake up that Service Desk is about Requests not Incidents? | The IT Skeptic.