The IT Skeptic - Comments for "A menu is not a service catalogue"

More on service catalogue

skeptic — Wed, 30 May 2012 22:28:09 +0000

Hi Stephen

I'm a philosopher not an expert, and a sloppy one at that :) thanks, I'll fix the inconsistencies.

Standard desktop is either an Application service or a Technical service: depends on attitudes. Desktop management is a different thing: standard desktop provides a work environment; desktop management keeps it working. Standard desktop delivers "Generic Productivity Suite" (Office etc) possibly as a SOE. Desktop management provides updates, upgrades, onsite field support, hardware MACs etc. the spreadsheet could use explanatory notes, I know. You get what you pay for :)

Brochure Catalogue is a view of the catalogue. there is only one set of services for an organisation, one catalogue. the differing views of a catalogue (brochure, technical) list subsets of the services, and list subsets of their attributes, depending on the audience. I work with up to eight views and there are potentially more. But there is only one set of services. I'm very clear on that, ITIL isn't.

I've listed broadly the same things as you, yes. But you use the phrase "Technology" in service names. That's not the service, it's only one part of how we deliver the service.

yes request catalogue is definitely a different animal. I'm talking here about service catalogue. Requests come later if you follow a top-down approach, or earlier if you follow a bottom-up approach.

I've never been entirely happy with "Application Services" as a name. it is a sop to IT folk who think that way. "Business Function Services" might be better. Communication is a technical capability we provide which underpins all business activities: it is not a business function in its own right as a hospital Labs or Wards function is. it belongs in Technical. One of the things we need to be careful about is granularity: a 300-service catalogue is useless. It needs to be something people can engage with. i try to create a catalogue with a few dozen services. Hence Communication, not breaking it down. We provide various mechanisms to allow users to communicate. period.

I'd love to upgrade those examples; it has been on my task list for a long time :(

Many thanks for your questions and feedback - you are bringing out good points.

Thanks...

itsm_stephen — Wed, 30 May 2012 16:50:24 +0000

Thank you for the link back to an earlier post. I must have missed that one.

I think most of the things I listed you have listed as well (some like for like) but you did break them up into those different "categories" (my word) which is interesting. Would the "Application Services" line up more with what would be in the Brochure Catalog(ue)?

Also, I realize this is not a final product or anything so you may not be much bothered - you have "Standard desktop" listed 2x - once under App and again under Technical and you also have "Desktop Management" under Technical - is this on purpose or is it due to the nature of this just being filled with examples of various sorts?

I ask because I wonder if it is good to list a service under the different categories - can a service be both Application and Technical? Is that what you are indicating?

I like this concept. But it all still is not crystal clear

http://www.itskeptic.org/service-catalogue-nutshell#comment-8638

That comment really makes me wonder - is "Send Mail" really the Service Catalog(ue) entry? I like your much better at "Communication" but the issue is then under that you'll have:

Telephony
E-Mail
IM
DR Communication System
System Ops Alerting System
Other...

Would those services be captured under the Technical Category? And then related to "Communication" in the App Category?

A Menu is NOT a Service Catalogue

ITIL Zealot — Wed, 30 May 2012 00:40:41 +0000

The menu in a restaurant is used by all, i.e. the users. Therefor it more resembles the Request Catalogue (something sadly missing in ITIL).

After all, the meals on the menu are merely the products delivered (comparable to an application). And it is not the product the customer wants, but the value he or she derives from this.

For instance a bowl of chips is the same product whether it is obtained in the drive-through of a fast food restaurant -with screaming kids in the backseat-, in a pub during the Sunday-session -with mates and a beer-, or as part of a romantic dinner-for-two in a seaside a-la-carte restaurant; same product but the value is completely different (convenience, atmosphere, privacy,view, ...).

Thus the ‘real’ Service Catalogue of a restaurant is the style, location, opening hours, interior, ambience etc.etc. ... All those things that make someone (i.e. the Customer) decide to go to that particular restaurant in the first place, rather than pick a specific dish of the menu.

Sample service catalogues

skeptic — Tue, 29 May 2012 21:42:00 +0000

Hi Stephen

I think you need to take that list of IT services up a level: that's an inward-looking list. The catalogue should see IT from outside, as a black box. Technology on its own is not a service. it is a thing. the services we provide are (a) to host and nurture that technology on behalf of the organisation, or (b) to steward the underlying corporate data (in which case the technology is just a tool we use) or (c) to facilitate organisational activities which use the technology and data. Which one depends on your organisation's role for IT as a service provider.

I provide some (old) samples here. The spreadsheet provides a starter list of IT services. Note that

Application Services: you could call it "Information Services' or "Business Services" or...
Application Services will almost always include some industry-specific services. For example, my hospital clients provide the following services specific to their industry, along with all the usual generic ones like desktop provision, connectivity/communications, and productivity tools: clinical systems, ward management, outpatient services...
Services are about what we DO, not what we HAVE or GIVE. Actions not objects. So we PROVIDE desktop, we HOST apps, we STEWARD data, we ENABLE transactions, and we PROVIDE advice and consultancy
Network access is a service. The network is not. it is a component (CI) of services.

The "service-to-customer relationship" is the SLA. This can be one or many at either end of the link depending on your business model: one SLA per customer-service pair; one SLA per customer for many services; one SLA per service for many customers; or other variants.

Service Blueprints are about "service" in the old-fashioned sense of something performed over a counter, the activity of touching the user. It does have the outside-in perspective, but it is a lovely example of how limiting that persective is if it is all we have. We need to be much more holistic about a service, e.g advisory services, intergity protection...

All of the above is my opinion. It may or may not correlate to the holy books, or to mainstream opinion (often two different things).

Question...

itsm_stephen — Tue, 29 May 2012 19:32:22 +0000

Skep,

Using your example of a restaurant's service catalog above would an IS/IT provider's service catalog be something like (or contain):

Electronic Messaging (to include EMail and IM)
Telephony (POTS or VOIP/IPT)
Common Desktop Environment (to include Word Processing, Spreadsheet, Presentation Program)
Identity and Access (Password, rights/access management)
HR Technology/Software?
Sales Technology/Software?
Accounting Technology (Bills Receivable/Bills Payable, Payroll?)
Core Business Technology (Whatever is core/crucial tech/software to the company)
Accessory Business Technology (could be other items that "help" the business but are not actually core to the business - like maybe SharePoint, or Remedy)

But not really "exposed" to the 'customer' but required to provide other services are things like:

Networking(inter/intranet)
Data Center Power/Cooling/Space
Computing (physical/virtual)
Operating Systems
DNS

Would that stuff be listed at all or is that like your restaurant listing that they have ovens, grills, knives, microwaves, power, a dishwasher, and stuff like that?

I put "technology/software" because I'm not really sure which it should be. Or maybe it is neither of those things - I don't think it is "service" because IS/IT is not actually providing the HR Service - just the tools used by the HR Service...

And by "packages" are you meaning something like:

Telephony package 1 = Virtual phone, Physical phone, Voice Mail and Email Integration, Call waiting, Caller ID, other stuff

Telephony package 2 = Physical phone, Voice Mail, Call waiting, Caller ID, maybe other stuff

And does "service-to-customer relationship" describe how it is consumed or something else? Would this be something like the Service Blueprint (http://en.wikipedia.org/wiki/Service_blueprint)

Thanks,

Stephen

Service catalogue step 1

skeptic — Mon, 21 May 2012 23:55:00 +0000

Thanks.

I don't doubt a nice service catalogue can be presented in a tool. It's a glossy brochure, which is useful marketing for any org.

The vendors and their victims need to understand it's not step 1. (actually vendors understand it is not step 1 but they can't sell step 1)

Step 1 is to define a list of services if you take the top-down approach as I do
(or define a list of requests that users can make, if you take the bottom-up approach).

The first technology I use for defining and documenting is Word. Excel can be good too though we usually need lots of narrative to get useful info.

Once we have consensus from stakeholders on what the services are, we can then start adding
- packages
- service-to-customer relationships
- service levels
- options
- requests
- configuration: CI relationships to service

...in about that order unless business needs rearrange it.

Somewhere in there it gets too complex for Excel to be cost-effective.

And at some point we want to present it in a pretty way to customers. Word is good for that too :) but of course an HTML webpage is easier to keep current and accurate.

At a high level of maturity in complex environments, i can see that it would be effective and efficient to build an interface that customises the view according to the customer or does other clever interactive things. in those few cases the vendors finally get to make some money off me.

Objectionable Service Catalogue

RichPem — Mon, 21 May 2012 21:03:23 +0000

Thank God someone's said that out loud. I'm going to share this article with a colleague or two.

You know I think the US ITSM tool market has screwed this one for us, servicecatalog.com for a start. Not that ITIL helps. Menu indeed.

Anyway, I have used [part of] a tool to present the service catalogue data in a nice way for business consumption. Service catalogue management looked after the data, the tool automated nothing more than its presentation. A request catalogue was built alongside it, and where it made sense requests were associated with services. Nice, simple, intuitive - amazing how much stuff just works when you take the BS out of it.