The IT Skeptic - Comments for "There is only one service catalogue"

And you wonder the business gets fed up with us

ianclayton — Fri, 22 Oct 2010 05:14:49 +0000

Ok - a useful thread but... why is it so tough to explain the purpose of a service catalog. As I blogged forever ago - there are 5 myths about this unicorn - see here: http://ianmclayton.com/?p=446

The biggest myth is that you need one - you don't. Not to start - we have survived in IT for 50 years without them. What you might need is a 'service request catalog'. This is as close to the customer/end user activity as you can get without doing the job for them. It aligns easily with the application view and frankly forces you to use customer language. Now let me be clear - by customer I mean ANYONE who consumes the service provider (IT) resources.

There is only one physical catalog of services and as some of you have said, there can be as many views into this as you have customers - just make sure you support a view the customer needs, understands and will use. One of the reasons its hard is because we allow ourselves to think 'inside-out' as someone noted - and be driven by what technology can do. When will we EVER take the time out of our day to actually work out what we and our customers need and build requirements based upon that????

Frustrated - you bet. We are too often inventing things the business has already worked out. Look around you - the business (service) world is accelerating away from us like the galaxies in the universe. Red shift. I was recently bailing out an ITSM project where the IT organization had developed a 311 service request system for their end users to be used by local taxpayers - the end customers. Yet when faced with the must do of their own service catalog - encouraged by a local software vendor - they were trying to do it completely different. Aarghh.

Remember - you need to write down the uses of your 'catalog' artifact - to what extent will it be for internal use to remind IT folks what they are responsible for - what do you need to expose to customer communities and why - to upsell, explain your value, control service levels.... expectations... why? Always start with why... please... thats the beginning of the outside-in thinking you will tire of me saying....

We make this all so difficult and no wonder the business management folks are so keen to punt on all this and just go 'cloud'... what chance ITIL edition 3.1 will get it right next time around... and what will be done, if anything, to repair the storyline written and distributed to the tens of thousands who attended training and rely on ITIL Experts to get them through this - where is the research project the professional associations could undertake to help members... aargh!

Out of the box...

Kory G Smith — Thu, 21 Oct 2010 01:56:01 +0000

Safe to assume that I had though the same thing and drunk from the same ITIL v3 aligned tool suite Kool-aid as you. The last two tools I've worked with out of the box did not have direct integrations between incident categories and asset types/categories. I'm clearly not the tool guy, but it seems like common sense. If there is one that has this integration oob and is "how they roll" I'm all ears.

ERP4IT

skeptic — Thu, 21 Oct 2010 01:10:00 +0000

Wow, you mean the vendors can't do that?

Actually i think one or two do have it to that level of integration. It's the ERP4IT model and I'd drunk enough KoolAid to think a few vendors had engineered it. of course I won't be surprised to learn that where there is smoke there are mirrors.

Sorry I missed the conversation!

Kory G. Smith — Wed, 20 Oct 2010 23:42:43 +0000

Wow. Bravo and kudos to all. Very good discussions, opinions, points, counterpoints.

This is what I wish the ITSMF was all about. Skep - Maybe you should buy ITIL! or at least the gain the managing rights to the "how" side of the equation.

Not to make the Service Catalog (bus/tech) discussion more difficult or harder, but I have a dilemmna that is loosely related to the above discussions. Why is it when you work with ITSM "Integrated Tool Suites" that they have all three components (Service Catalog, Asset/Config Management, related Tickets that care about Services/Assets) as distinct but supposedly related objects and attributes, very rarely are they built to be easily or out of the box interconnected. Here's what I'm wanting to do, but have yet to see, read or get any good guidance for how to do it.

1. The one authoritative and centralized business facing Service Catalog list. Each Service tracked as a CI in the CMDB with a category of Business or Customer Service.
2. Defined "system" CIs that provide the next level below the list of Service CIs (thus Parent to Child relationship between Service and System). LAN, WAN, User System, DB System, Application Systems, Cluster, heck even Cloud System(?)
3. Distinct Asset CIs (that make up the Systems) tracked and captured in the CMDB with relationship to the System CIs upstream.
4. Each Asset CI having a type (HW/SW/DB/Facility/Etc.) and the set of descriptive attributes you care about (even relationships to location, vendor, model, user objects/CIs.
5. Then, on your Incident ticket, you have a category structure that pulls directly from (not just duplicating or corresponding) to your Service Catalog / Asset structure. As opposed to a category structure that the Service Desk makes up that doesn't one-to-one match your Asset categories and relationships?
6. Capture symptom and cause categories/descriptors on the tickets separate from the primary Service/System/Asset/Type category.

Am I missing a huge gaping hole as to why we don't want it (or can't have it) this way? To the point of the above discussions, it is all 'one' service just with different views at different (but related) granular levels. Why would we in Incident (or Problem or Change for that matter) want a different (or our own) categorization structure that isn't consistent?

Tell me I'm wrong and that I'm just showing my non-technical, non-data architect roots and I'll be quite.

-Kory

Or, if this is a gap, maybe a bunch of us can buy a big whiteboard at Pink '11 and lock ourselves in a room and figure it out (from Catalog to System to Asset to Attributes to Tickets to orderable requests to the glossy brochures)...maybe a really big whiteboard.

Not so easy

aroos — Thu, 02 Sep 2010 08:23:00 +0000

Rob, Mark

This discussion got me interested in the state of things in real life. According to my new study, only a few get it right, see: http://www.itsmportal.com/columns/service-catalogs-are-difficult . I fully agree that it should be a easy concept but somehow it seems to be quite difficult.

Aale

Easy concept

Mark O'Loughlin — Tue, 31 Aug 2010 09:29:43 +0000

I think are views are more aligned that you care to day – possibly due to taking the extreme view. But hey – if that is how you roll the dice ...

I read recently of an IT director who gave back his budget and starting charging for services. In order to charge for services you need to do this fairly and be transparent about the costs. A catalog of IT services that is linked to the supporting business processes (and services) and customer services is a good way to do this. Costs can be broken down easily, understood easily and charged for easily. There is value in IT service catalog and I don’t mean purely for IT’s sake but for the business overall.

On this issue, I'm trying to get heads away from self-centred geek "catalogues" and focused on the "one true catalogue" ---. There is a time and a place for the IT catalogs I guess you refer to them as “self-centred geek "catalogues" and a time and a place for the "one true catalogue". The tricky bit is who is pushing the agenda and paying for the effort?

You say it yourself and I say it (see we are not too far apart as you try to make out) “IT's true customer is the business”. Yes it is. So how is IT supporting the business? By what it enables the business to do within the business service catalog. How does it do this? By it does (supports, provides etc) within the IT Service catalog. Easy concept.

counter-productive

skeptic — Mon, 30 Aug 2010 21:56:00 +0000

I'm listening and I'm thinking, which is why I'm not reviewing :)

I take an extreme position on things to try to tip the balance of public thinking. Much like Greenpeace, except I like to think i have more respect for fact-based reasoning than Greenpeace - I cancelled my membership years ago.

On this issue, I'm trying to get heads away from self-centred geek "catalogues" and focused on the "one true catalogue" which delivers to OUR Customers, whatever "our" means in any organisational context. It is only in some contexts that "our" means the end customer. If IT is of a lower maturity then the business regards that sort of approach as odd: IT's true customer is the business. It is an advanced organisation if IT and the business share the same customer - most orgs just aren't there yet. Your book links catalogues up at all levels in a holistic catalogue model, and allows IT to have its own little internal "services". That may be theoretically a good thing, but I view both of those (I think) as counter-productive to the main aim of a catalogue: to focus everyone on what matters. That's not necessarily a criticism of the book but I do want to present the counter-view

Note that I am NOT advocating one catalogue per organisation. I'm advocating one per frame of reference, per boundary. Units within an org may have their own catalogue, IF they are truly running that unit on a SM model, if it really is service that they produce and deliver to a "customer". I'm saying one catalogue per discussion, per context. On that we agree.

Still mulling on it....

P.S. yes Word-based catalogues are definitely maturity-level 1. As you say, it's a start.

Drawing to a close

Mark O'Loughlin — Mon, 30 Aug 2010 10:06:15 +0000

Hi Rob,
As I asked when I first posted a comment on this thread – are you lecturing or listening. I seem to be correct in my assumption that you are lecturing. Don’t get me wrong you are quite entitled to have your opinion and say it (especially on your blog) – equally others will also have a view – whether you agree with it or not.

I don’t think that our views are as misaligned as you purport. I was going to reply on some of your comments directly but just think we will be going around and around in circles. If you look at the model I represent up to 8 possible service catalogs under the label of The Service Catalog (one overall catalog). The model I have included in the book is scalable. Each service catalog type e.g. IT, Business, Customer can have many catalogs that describe and record the services for that type. There can be many IT, Business and Customer catalogs in one organisation. I see one complete catalog in a large organisation a difficult task – much like one CMDB (you know what I am talking about here and the difficulties faced).

Already I feel a biased review of the book could be on the cards as you have a strong personal opinion on the subject matter. Time will tell.

Be careful with those Word based catalogs. I have seen ones that while they record information about services, you cannot easily report on anything about the service e.g. missing information, number of services, services lacking SLA’s, UC’s, business units served, owners etc. However if it is all the organisation has to catalog services it is better than nothing!

clarification: technical vs. business catalogue

skeptic — Sat, 28 Aug 2010 22:53:00 +0000

Another clarification:

Ergle Corp makes those little plastic bubbles that pills come in. Ergle has a service catalogue that describes its services to its external customers, the Red Catalogue. Its IT department has a catalogue of services that IT provides to Ergle staff and to external users of Ergle's IT, the Blue Catalogue. These are two different catalogues at two different organisational boundaries. In any one particular context, from any one frame of reference, there is ONLY ONE RELEVANT catalogue.

The IT department writes SLAs with its customers against the Blue Catalogue. Ergle's Finance department measures IT Department's costs against the Blue Catalogue. Ergle publishes the Red Catalogue on its website.

There is a Blue Business Service Catalogue and a Blue Technical Service Catalogue and a Red Business Service Catalogue and a Red Technical Service Catalogue (and a Blue User Service Catalogue and a Red User Service Cataloge and a ...). They are VIEWs.

It is wrong to say the Business Service Catalogue describes what Ergle does and the Technical Service Catalogue describes what Ergle's IT does. This model muddies the whole situation and does not scale in the complex value chains of today. The model must be fractal and must be clean and complete at any frame of reference, i.e for any one boundary. "Business" and "Technical" are views of the one catalogue at the one boundary.

yes there is a Blue Business Service Catalogue and a Red Technical Service Catalogue. But they are talking about entirely different sets of services. The only connection between them is that they will reference each other as related documents, and there will be "depends on" relationships between Blue Services and Red Services.

The ITSM Library publication The Service Catalogue: A Practitioner Guide does this muddying. It has three catalogues: Customer and Business and IT (and at times treats them as one and at other times as three). Sorry Mark, I passionately disagree. It's not fractal, it's not scalable, and it confuses the already confused terminology. Yes those three catalogues exist, but they exist in three distinct contexts as three distinct systems, not as an inter-related system. It might happen that they share a storage technology - likely not. Even if they do, that is all but coincidental. [Book review to follow one of these days]

clarification: one catalogue

skeptic — Sat, 28 Aug 2010 22:42:02 +0000

Clarification:

there is one VIRTUAL catalogue per organisational unit. It may consist of multiple physical catalogues, e.g. one per customer market segment. It may appear as one physical catalogue but be federated across multiple sources of data. Or it may be a Word document. Whatever.

But for ANY ONE catalogue, it should describe the services crossing ONE and only ONE organisational boundary. The mapping of catalogue to boundary is many-to-one, not many-to-many.

pink elephant

mbuzina — Thu, 26 Aug 2010 14:24:53 +0000

Forgot the connection between pink & pink. I meant the pink elephant as in http://www.amazon.co.uk/Drop-Pink-Elephant-Personal-Communication/dp/184....

Somehow ITIL is trying to talk about configuration management process, but only talks about CMDB. In that way people tend to forget what was said about the process and remember only CMDB. (Just as when a certain president talked about not having sex with someone, everybody rememberd Clinton - Sex - Levinsky and forgot about the "not").

And you are right with last statement as well.

And I still believe catalogue management systems are not helping much when setting up service catalogue(s). My recent consulting assignments have been more along the line of developing a service catalogue. And for that to achieve its goals you need to discuss the same services on both sides suits & geeks. I guess we agree on that as well.

none taken

skeptic — Wed, 25 Aug 2010 22:48:00 +0000

What's a "pink elephant cmdb"? I'm the one who says we should talk about config process not cmdb artefact.

Although I haven't gone into it here, my consulting engagements around catalogue are all focused on implementation of a catalogue management system. The catalogue itself is a product of that, usually a Word document initially.

I agree we're talking about things not processes here. Things may not be the most important things, as it were, but they still deserve discussion, especially when the popular perception of a Technical Service Catalogue is that it described different service entities than a Business Service Catalogue. that's just plain wrong and it is what this post sets out to address. On that I think we agree.

Yes exactly, but who started talking about tables & datamodels?

mbuzina — Wed, 25 Aug 2010 10:39:55 +0000

You said:

if one's head was firmly wedged into a model where there are services that only technical people know about with no data of relevance to customers, which is exactly the self-serving inside-out BS I'm trying to stamp out here.

Yes, Yes, Yes! But you are promoting the wrong "tools". I would not start a discussion about the one service catalog, but I would start sharing the service definitions from the business with the tech people...

I am not promoting the two table design, but I am saying: It does not make a friggin big difference, it is implementation detail (or physical implementation or whatever). Use powerpoint, excel sheets, database catalogs or plain paper, as long as you get everybody to talk about similar (note: not the same) things, you have done a great job.

Greetings to the itSMF folks down under!

Marc

P.S.: Somehow your talk reminds me about the differences on configuration management. It has been reduced to your pink elephant cmdb, but in best practice it should be a process. You are doing something similar right now. - no offense meant - ;-)

total failure

skeptic — Tue, 24 Aug 2010 21:53:33 +0000

I may not recall all the data modelling terminology from when i did this stuff in int he 1980s but I recall the principles. You have taken us down from the logical model to the physical implementation - that is a different discussion. there is but one logical entity.

Splitting it into two tables would work only if the two sets of records always had no common data, i.e. if one's head was firmly wedged into a model where there are services that only technical people know about with no data of relevance to customers, which is exactly the self-serving inside-out BS I'm trying to stamp out here.

I don't have access to a drawing tool - I'm at a conference - so here's how it looks:

+--------+-------------+-----------------+-------------------+-------------+---------------------+
ServiceX Stuff-both-customers-and-suppliers-care-about Stuff-only-techs-want-to-know

The technical catalogue presernts a superset of the attributes that a business catalogue presents, not a distinct set. if your tech catalogue is not presenting the business-related info too then that's a total failure of ITSM to introduce customer-centric thinking

Mysterious Ways

Visitor — Tue, 24 Aug 2010 11:21:38 +0000

Well they certainly move in mysterious ways!

Agnostic

mbuzina — Tue, 24 Aug 2010 11:05:17 +0000

We will never know. If you implement all the advice given by the trimvirate exactly as defined, you may find yourself in ITIL-Heaven - or not. There is no way of knowing that for sure.

The ways of ITIL are unfathomable.

The Devil Incarnate?

Visitor — Tue, 24 Aug 2010 10:40:45 +0000

OGC, APMG and the itSMF is hardly an all knowing, all seeing, all perfect triumvirate! More like the opposite.

In the name of the OGC, APMG and the itSMF

mbuzina — Tue, 24 Aug 2010 07:43:26 +0000

Amen

But that model is not helpful

mbuzina — Tue, 24 Aug 2010 07:30:00 +0000

Hmmm, you accept a sample of a model I have given to show that you can still misuse the "one entity" and not reach the goal of getting the geeks to talk about business services as the correct one.

The business people and the tech people see no difference between the model above and a model with 2 tables. Lets reuse the table shown above:

So thehe business sees a table called Service Catalog which contains:

while the IT sees the following Service Catalog table:

can you tell from these views if the physical storage is in one or in two tables? Yes, there could be someone who has the overview over both worlds, but which organization would this service overlord be in? And what could he do with that information? Could he talk to the business about it? Would the IT listen & understand him?

My reasoning is: Having a single storage / entity of services with different views does not stop you from discussing two (or more) seperate sets of services, thus not achieving the goal of involving the "geeks in the basement" with the services the business expects.

Getting the geeks and the suits together can only be achieved by communication, not by tools (like a database table).

Same entity, different views

skeptic — Mon, 23 Aug 2010 22:51:17 +0000

Marc

that model is exactly what i am talking about. Same entity, different views. Although hopefully we also present some or all of the business perspective in the technical view. I think of it more as there is technical info that customers and users don't need to worry about but technical staff should see the busienss description of the service, and especially the impact and importance ot it.

And as i mentioned earlier, certain individuals will see different subsets of the service entities depending on their roles as well as different views of the attributes as you have described