Shock horror: the IT Skeptic endorses a technology - service catalogue

[Updated with a Health Warning] Recently I wrote "It seems Technical Service Catalogue is often misunderstood to mean a catalogue of different services from those in the Business Service Catalogue. It's not. It is a different view of the same services". And those views are quite complex.

As defined by ITIL V3, the catalogue includes both services that are currently being provided (let's call it SProv) and services that are available but not yet provided to anyone (SNew). Some of SProv are no longer offered to new customers. So all of Snew plus only some of SProv = the services accepting new customers SAv.
catalogue setscatalogue sets
So if sitting down with a customer X to discuss current SLAs and potential future services, we want a Business Catalogue that contains the subset of SProv which are services currently at client X (SProvX) unioned with SAv. We don't want the catalogue to include services other customers are receiving but this customer can't have.

The Technical Catalogue includes all of SProv union SNew; all services currently supported.

The User Catalogue should be customised to each customer to only include SProvX, only what that user can request.

It is perfectly possible to sit down with a customer or prospect with a document containing a Business view of all services and explain why some are no longer available to new customers, but a customised view would avoid that natural human desire to want what you can't have.

So vendors like my friend Rodrigo at NewScale are right: this is one place where technology can really help us. [No I don't necessarily endorse their product. Rodrigo is very active in the ITSM community as a contributor not a vendor so he sprang to mind]

[updated with the following HEALTH WARNING for all my friends I upset with this post :)

I wrote today on a thread on LinkedIn:

Start with a business goal.

Then look at the people. Who has which roles, what accountabilities are there? What do they need to get their job done to achieve that goal and what is getting in their way? (Ask them)

Following from that, how can you improve/transform process and procedures to help them be more efficient and effective? (sometimes using bits of frameworks such as ITIL etc - "ITIL" is not the answer)

Finally and only after you have answered those questions, can you look at: will tools help here, in making people more efficient and effective at what they need to do in order to achieve our business goals? OK so what are our requirements for a tool? (the procedure changes will tell you)

Unless you go through those steps there is NO WAY you can know whether any one vendor can help you, or even if you need a tool at all.

Comments

The first thing to say...

...is thank you for your kind words.

You are absolutely right that tools w/o people and process changes just don't work.

There are so many comments below that I'd love to spend time responding but wow! the thread got big!
In the spirit that the more we know about each other, the better the conversation; I'll share that it is now 10 years since I started newScale and I've seen things change quite a bit.

For example, at first, the most common reaction was either: "Services cannot be catalogued" or "We use a procurement system" That's years 1-4. Then it became, xyz vendor has web front end to the help desk.. Then it became; "the CMDB is the center so the catalogue is a feature of that..."

Most of the projects our customers do are aimed at some level of transformation or services improvement. For example, in 2001-2003 and late 2007-2009, the big drivers were cost-cutting and rationalization. Otherwise it's often about customer satisfaction.

By the way, while interest in ITIL v3 is high, it represents only one market segment interested in the service catalog.

Starting mid 2009, we are seeing increasing interest in service catalog driven by virtualization, consolidation and next generation data center refreshes. Cloud is part of that. And though early, we are seeing customers getting their house in order to operate like a cloud. This is not driven by hype, rather it's the effect of the recession. Staff has been laid off and they are not coming back. So they are seeking a leaner operating model and now are open to automation and external service providers in ways they weren't before. Hype does not enter into it; just the new normal.

The issues driving the adoption of a catalog for that segment are technical services standardization, financial transparency and increased business agility. And the desire to use or at least be able to compare to external service providers. Or to provide services.

This is where the actionable part becomes critical. They need to be able to define services form lower level leggo blocks that are are already in use. They need to be able to show different services to different customer groups (this is a big one). And they need to be able to request, trigger and track the provisioning process, and the manage the lifecycle. A large subset needs to do costing of units of services.

Another segment buys the service catalog tool to document business services and then do portfolio management. The general question they get from their customers are: What do you do? How well do you do it? How do you compare to others? There's a lot of reading of data, integration, and analytics involved. So a tool is asked for.

Customers are pretty smart. As I said, the adoption of service catalog is part of a larger transformation initiative. No one buys our product to transform IT. Most of the time people have been working at it for a while before they select a tool or they have been working with consultants to accelerate their transformation.

As you know, I maintain a blog and community for practitioners. The templates have been downloaded 10 of thousands of times. If only a fraction bought newScale, I'd be blogging this from my beach house on the moon!

Rodrigo - Well said. As

Rodrigo -

Well said. As always, I find myself nodding at your insights. In the last month alone, I've taken on half-a-dozen clients where the service catalog formed a key step in a large [F100] transformation journey. Typically it begins with an operating model exercise, as you noted, and often intersects with a major rethink of cost allocation and recovery.

Keep pressing. What gets missed amongst the naysayers is that hype is a critical phenomenon. It serves to capture the imaginations of a broad audience, overcoming corporate resistance and inertia among the decision makers. Hype, like politics, is the art of the possible.

If you are attending Pink Elephant this month, I'd enjoy catching up. Lavish dinner on me.

Thank you.

I'm always up for a lavish dinner. I'll be there with my newScale peeps - so I'm easy to find.

good thread!

thanks to all for a good thread...

John M. Worthington
MyServiceMonitor, LLC

We need the business to pick our service catalog software

Rodrigo - with respect - I am a believer in catalogs and especially service request catalogs but had to be pilloried by the ITIL centric community for years because we needed a CMDB first. Then it was service catalog, now I see more respect given to request management and provisioning. As a product marketer of some experience I am intrigued - how do you guide your customers through the task of defining services without going through service requests?

We do not need a service catalog - Amazon does not need one, nor does my local online bank. They provide me with service requests first. Services are a bundle of request capabilities, deliberately bundled for a market driven reason. ITIL V3 has fumbled the Marketing message, Strategy got it wrong and is suffering the ignominy of being re-written. So please don't refer me to an IT reference when business/product marketing skills are needed to successfully build a catalog.

As for capability - can your catalog product meet the need of Dominos Pizza, Dell, Amazon, name any Fortune 500 company - enterprise side? If not - then do not push this on IT - we need what the business is using... as you can see - my response is filled with the frustration of vendors leading the unwashed and inexperienced in defining and operating service management initiatives. They might implement a tool but they fail both the organization and the customer.

Disagree - then who is paying for them - I bet its not the customer....

Thanks for the questions

Ian,
I appreciate your candor with respect to your frustration with vendors and the ITIL community. It has come loud and clear over years I've read your material. I too share some frustration or perplexity with the way, as Rob puts it, Castle ITIL, works or doesn't.

But there's nothing I can do about it, and it's just not that important to customers. And to be dismissive of vendors like me, is a dis-service to the conversation. I'm pretty open about what I think: 500 blog posts later, it should be pretty clear what I think and contribute.

So let us spend time on what we agree.

First, I agree requests are very, very important. So important that newScale's first product, and still our largest seller, is called RequestCenter. The innovation then, and now, is that it's a catalog-based request system. The majority of our customers have implemented this product.

Second, As for your question of capability: the vast majority of our customers are Global 2000, and 20% of the Fortune 50 across all industries and government. On a daily basis about 2 Million users make requests. There are about 15,000 service definitions in production. It's been proven and re-proven.

And I agree about provisioning being important. As I said in my prior post, we are seeing tremendous interest from the data center and we now have products editions specially for VMware and Amazon EC2 that provide service request, catalog, and life cycle management for those products. The issue: enable business agility.

Where we disagree:

Customers are pretty smart. They don't get led by anyone really. More than ever, the power has shifted to the customer. Ian, they are not unwashed, they are not ignorant. Vendors, particular smaller ones like newScale have to meet the needs better, faster and cheaper or there's no reason to work with us.

They have pretty specific issues they need to deal with. For example, right now we are working with one that's consolidating 100's of data centers to two. Our product is critical to the operation as they are standing up 90 server builds per day. This project has a huge ROI.

And yes, our product does work on the business side for a number of customers who don't make $ if the request doesn't flow. As one said recently, "If I can't describe it & show it, I sure as hell can't sell it."

This whole thing rigamarole gets much more understandable if we think about the power of requests. They were here before, and they will be here after we are gone.

The service catalog serves to standardize requests so they acquire "manufacturing" like efficiencies.

For example, at a large hotel chain, they had a request system for new ID's - many brands, and business models so the request crossed company boundaries. Here's the issue: the system was client server, cost $millions to build, it took 7-14 days to get the request processed, maintenance was very costly ($35k per service definition), and it consumed 20 people full time typing into various systems. But they handled the requests and they had a process. And it was state of the art when it was built.

The changes we brought about were reducing provisioning time to 5 seconds, dealing with all the policies upfront, enabling self-service, providing shopping guidance to the users as to which system, keeping a record of who had what (that was an issue introduced by SOX), tying the catalog to the ID provisioning system. All at lower price of software and lower TCO. And the service catalog is key to that TCO - by breaking up very complex, multi-page processes into discrete orderable products, it reduces the effort to create and maintain by an order of magnitude.

This sounds like a pitch for newScale, but it's not my intention. My intention is to show that there are very pragmatic, everyday issues that customers choose to address and they drive the projects.

Finally, I do agree with you that static catalogs are useless. We stay away from pure brochureware for two reasons: a) they don't achieve anything, b) they don't get funding for tools because theres' no ROI. Those catalogs are usually deployed in Wikis, Sharepoint, PDF, portals, etc. I know several that hire graphic and web designers for more than the cost of my software simply because there's budget for services but not capex.

They don't produce much.

No - Thank You for Leading

Rodrigo

I was far blunter than I perhaps should have been fueled by some frustration caused by some of my fellow ITSMers and their peddling of catalog wares and overly simplistic responses to some questions on blogs. You deserve credit for taking it by the horns and leading where others cowered. I also thank you for a very polite response given my two Heineken laden post (yes I was on wireless again in flight - a dangerous trend here for me!).

As for customer being ignorant - far from it. I hope that was NOT the impression I left. I always adopt a customer thinking view - and that gives me some sort of 'right' to represent what I see, hear and feel working at the coalface. I suppose my badly made point is that ITSM remains a work in progress as a defined target for many in our industry and there are few forums where that has a chance of being changed. The catalog is but one element, important though, but it truly deserves a marketing specialist to design as it often lives alongside a service request (Google 311) facility and resides on a portal, and demands a flexible face turned towards each customer community. Our IT catalogs look a bit crude when compared with what the business turns out.

IMHO we need to look outside of IT more often when trying to understand how to manage the customer experience, even if they are but users and not always end customers. ITSM for me is the application of proven service management concepts and methods (used under the guise of product management) by the business to the challenges of IT. I'm fed up with the ITSM crowd re-inventing (and renaming) things.... but that is our lot for now.

So a thank you Rodrigo for everything you and your organization has done and continues to try to do to transform IT organizations into true service providers. A catalog is a dangerous weapon unless it is designed as a marketing tool (and as you rightfully emphasized) hooked up to a provision management engine.... This is a '0 Heineken' post

Thanks Ian

I take all your comments in good heart. I appreciate the compliment.
Your points are well made. And yes, it's a about the request ...

It isn't the tool

It comes back to the old adage that a fool with a tool is still a fool.

only so much

yes indeed and there is only so much that vendors can do to rectify that :)

Finding a Business Lane for ITSM...

Of course there is value in standardizing on a Technical Catalog of services and automation of Request Fulfillment, and my rants on service catalogs and Skep's endorsement are not targeted here...my frustration in particular stems from a need for a business-driven view of "End-to-End".

When we define Technical Catalogs and focus on provisioning automation the connection to the business can be indirect (and to external customers is often indirect). Your example of the ID processes might apply quite well to externally facing business processes (if I understood the example, the system was internally focused). But the same principals apply; externally facing business processes and the associated transactions are essential for defining "End-to-End" across IT (and business) silos.

Even your book (which I liked very much), 'Defining IT Success through the Service Catalog', states that Step 1 is to Define the Business Processes. However, it just seems like we stop at lower level processes that are not connected to the external customer (and thus directly to the Business). To me, this spells Inside-Out, Bottom-Up, etc. ... So I just don't get the feeling that we're eating our own dog food.

Perhaps it's because with all the work being piled on IT, the thought of getting into BPM is not a welcome one...or perhaps IT is in no position to call the business on a lack of business process ownership...

Regardless of the reason, we will not reach ITSM nirvana unless we come together on the most important business processes (the ones serving external customers), i.e., Outside-In as Ian states. I can say with certainty that when we do, service monitoring intelligence realizes its full potential and can really turbocharge an ITSM intiative.

More often than not, we're left with service definitions that fall far short of what's needed. So when I say we're "Lost in SPACL" I say that tongue-in-cheek; while the effort has merit it's one more thing taking our eye off the External Customer ball...

I'm just a bit frustrated the Catalogs have not been more helpful in this regard.

John M. Worthington
MyServiceMonitor, LLC

multiple levels of maturity

You touch on a very profound issue John.

In the most mature of organisations, IT is an integral and contributing component of the business, and there should only be one true catalogue; the one about the services to the external customer.

At a lower level of maturity (Gartner or ITIL Service Strategy or someone has this 5 level model) IT is merely aligned with the business, and so while the IT Service Catalogue may be shaped to align with the business services (to "plug into" a bus catalogue if it exists), it is distinct.

At the lowest levels of maturity, IT is still dissociated and the IT service catalogue has services like "Host applications" and "Provide communications" and "Look after data". Often the business is equally immature and the concept of a service is met with blank stares

In the worst cases, it is an achievement to get a Business Catalogue of ANY standard into IT - all they want is a Technical Catalogue.

I feel that the comments by you and Ian and Ken and James are setting the bar at that highest level. That's great but you have to wait for folk to catch up, and it takes as long as it does for kids. Trying to build an organisational service catalogue with IT components for some of my clients is like trying to teach my 10-year-old about profit-and-loss accounting or calculus (I tried).

i think you guys gotta get real and accept the multiple levels of maturity out there.

Doomed to the Savage Journey

I just do not want to accept that if we're stuck at lower levels of maturity we must build (design) things from the ground up...mapping business processes (particularly higher-level processes) should not require years of increasing process maturity and an army of six sigma black belts (even if consultant's tell you it will). Using a services based approach to improvement can help break things down into smaller bites.

There's no question that ITIL has failed in the area of providing specific maturity guidance for ITSM, and we've ranted here on this subject before. The ISO 20K PRM/PAM would be great but we should have had something like that in v3 (like we did to a degree in v2).

But I think you give up too easily! Establishing a Business Lane for your ITSM Road Map is a fundamental requirement. At least make this issue visible, preferably right up front. In a world of banksters and bailouts, it's the Right thing to Do.

“Control your fate or somebody else will” - Heinrich von Pierer

This is why Ian rants about SMBOK I suspect; it's not just an IT issue! IT is only one Business Unit, the others must also be along for the ride. All they need is a lane on the Road Map. If IT must start our journey from the Bottom-Up, then we should make it clear that we will not reach nirvana without the business also on the road from the Top-Down.

Otherwise we're doomed to the Savage Journey and all the Fear & Loathing that goes with it.

John M. Worthington
MyServiceMonitor, LLC

on a journey

I don't think I'm giving up: I think I'm sending them on a journey just as I am with my son. Right now my son pays "Nana tax" on any money he makes: he pays half to his grandmother who puts it in the bank for him. This is of course unrealistic as he will one day get his money back but it is a simple principle he can grasp and administer and it is developing money management habits. With the remaining money he makes awful mistakes, buying shiny things he later regrets. This is to prepare him for car and yacht buying in adulthood. (Some of you cynics will also suggest it prepares him for marriage).

Take a current client as example: I can't convince the organisation to adopt service management within any useful timeframe: I have no access to those who count, they have never heard of the concept. They are more likely to do so if they see IT doing something interesting. Right now i have no available definition of organisational services, not even disguised as strategy planning or project portfolio or DR or role descriptions or organisational structures etc etc It is beginning to happen but it is a long way away. Right now there is a bleeding need for IT to grasp the concept of services, and to have something - anything - to rally around as a banner, and that's one of catalogue's primary purposes in my mind. So i do what is within the capacity of IT to define and grasp and make useful. I suspect the first cut will say "host the applications". And that's fine, if we build robust processes for continual evolution, and not just a static document. (yes document: we are a long way away from even considering a tool)

You can't change an organisation overnight any more than you can grow up a son. You have to let them hurt themselves occasionally - you move danger out of the way and you build on the learnings.

My one track mind

How I wish my kids had the concept of a step-dad tax like the Nana tax. Well they do, but it seems to work the wrong way round from my perspective.

Have you considered using ISO 38500 to get some traction in this case? I know I seem to be its only fan in the Northern hemisphere. Like the Nana tax though it is simple to understand and it is there to protect you from your bad decisions.

There are at least two fans!

James,

I'm a fan too, so there are at least two.
Look at how powerful and influential you are -- you doubled the fan base in less than a day! :-D

kengon

To know it is to love it

I seriously think that the low profile is down to people not knowing it is out there. It seems easier to convert people into fans than it was in the early days of ITIL.

It is so much easier, and fun, to do an elevator pitch for ISO 38500 than it is for COBIT/ ValIT.

James

ISO38500 is deceptive

Don't tell me it's that not-invented-here thing again. Is the USA going to drag ten years behind like they did with ITIL just because some foreigner wrote it? I know Kiwis won't let American nuclear ships and weapons in our ports and get a bit hostile about the spy base on our land, but heck the Aussies are almost honorary Americans now aren't they? In some circles Australia is known as "The Deputy". Unlike the Brits we've ALWAYS fought on your side guys.

Seriously, ISO38500 is a deceptively simple doc. it is also deceptively titled. there is nothing "IT" about the governance: it is in fact a generic governance standard. Its weakness is that it is very abstract with no prescription or guidance. It presents only a principle which leaves a lot of work to be done. As we've seen with ITIL etc people want to be told what to do, not left to think.

That explains the slow uptake in Asia: they want a formula and a certification. I'm puzzling about UK and Europe though: they love concepts and models.

Not seen as needed Here?

I did wonder if it was just that people thought ValIT and COBIT meant there was no need for the standard as well.

I'm not sure to be honest. I've got no idea how it is seen in the states, Rob Stroud is the only US based person I know who is active in the area, and of course he's really an Aussie so doesn't count except as one of those honorary Americans.

In the UK I'm tempted to say the only driver for governance has been corporate fraud, not the concept that good governance can add value, which I really believe is what ISO 38500 can deliver. And yes it is deceptively simple, dare I say profoundly so?

But there is no "product". What can the consultancies sell? Where is the supporting software? The expensive training scheme? Even without my cynical head on I think this is an issue.

I think you are right that we love concepts and models, but not at this level of abstraction, at least not in IT..

Finally judging by some of the feedback I've got from my blog post a lot of people simply weren't aware it existed.

Errrr?

So where did this little tirade come from? LOL
Is there something wrong with ISO 38500?

FWIW, I also happen to be a big fan of OCEG. They are very American, very open and very good. Their GRC guidance is worth paying attention to -- not just pictures and fluff.

kengon

YAFBOK

I do like to start the day with some xenophobia.

There's a lot wrong with ISO38500. As James says below, there's not a ready buck in it.

OCEG? On no! YAFBOK! [Yet Another Body Of Knowledge] It's a new one on me. thanks for that. Even though it is American I shall read with interest (wow! impressive credentials and useful looking content. Thanks again) [update: on third thought, the OCEG's GRC Red Book is a useful doc to have but if you want the good stuff such as assessment tools, pay $5000 for an enterprise membership. Almost makes TSO's ITIL Live look cheap. And it makes ISACA look VERY good value for money]

Lowest Possible Bar...

Happy to help.

I think that there are many things worth keeping in mind with any standard:
1. There is no magic. It's still incumbent upon the organization to do the work.
2. Most standards set a minimal bar. Given the potential variation from one vertical to another, that's probably a good thing.

As far as 38500 goes, there's not much difference there from the original Australian one, save the additions in Section 3. Even if one doesn't like the additions, if they can serve as a catalyst to get people to communicate or move their thinking in a productive direction, they will have served a useful purpose.

Lots more to say on the topic. Think I'll blog on this... :-)

kengon

Which might be a bit of a shock....

...to those who think attaining a standard is something to crow about.

ISO standards are designed to be attainable by most organisations. They are not best practice.

That's why I worry when I see organisations who have not put in the basics needed for ISO 20000 but who are telling any one who will listen that they have "implemented" ITIL v3.

They also only evaluate what they evaluate. Complying with ISO 38500 does not make you an ethical IT department. Being ISO 20000 certified does not signify the quality of service actually being delivered.

This is not a bad thing, as long as it is understood.

Great points...

and very well said!

kengon

Oh no there isn't!

I don't think there is a lot wrong with ISO 38500 as long as you do what you should with all standards - take it for what it is.

climbing the corporate ladder

ISO38500 would be a great tool for climbing the corporate ladder, getting audiences at progressively higher levels. So too is SOX. So too is the ISACA Board Briefing on Governance.

but that takes a LOT of time, and is fraught with peril at every step - a real odyssey.

Fertile ground

Rob,

I think we could all have another very long discussion about how maturity models can best be applied to ITSM. My personal view is strongly influenced by the Stadia model we used in Quint.
In particular I believe that even at each level of maturity you can still distinguish between organisations that are in a position to move up a level and those who are destined to endlessly repeat previous mistakes. There are things you can do to make the ground more fertile.

So if you are at the lowest level in your example, where all they want is the technical catalogue, you have tow choices. You can either be absolutely honest that that is what it is, or you can kid yourself it is something else. I think it is the latter position that we are advising against.

what the services are

Even someone whose only teaching is an online CBT of the ITIL Foundations understands the distinction between a Technical and Business catalogue. What i'm saying is that the growth comes not in the kind of catalogues so much as what the services are in them

Do they?

OK, I know you know the difference, but I recently read a book that claimed to be about taking an ITIL centric approach to defining services and then spent over 200 pages detailing technical service elements.

I think most people grasp a theoretical knowledge of the difference, and have a will to embrace it. but in practice they don't recognise that what they are describing in their catalogue is still not a business level view and is insufficiently packaged to meet the business expectation. I once saw the result of this in a boardroom in Frankfurt and it wasn't pleasant. It doesn't mean they aren't providing the business level services, but because they aren't recognised at the right level they aren't managed efficiently and effectively at the right level.

From a user perspective a simple example of this can be how difficult it is to actually find the service you want in the catalogue, which can be down to something as simple as IT and the business having different names for the same entity and having a consistent approach across services.

The growth needed isn't an issue of adding services but of understanding how to re factor them.

The tool is largely irrelevant. We know the technology exists to meet our need when the time comes for it.

I do think that you need different kinds of catalogue for different purposes, which is not to say they can't share an underlying engine. The information needed by a contract manager to sign off a call off contract for another 500 computers is different from that needed by the individual user ordering one of those computers

differing views of one common service definition

I love the test of how well the audience can find a service.

Growth in maturity isn't about "adding" services, it is about new descriptions of services at different levels, just as you describe and as in my previous comment. "Hosting business applications" becomes "hosting the Rental application" becomes "IT supporting the property management process" becomes "properties for rent" in an organisational catalogue.

Sure the tool is irrelevant. In this case I think there's a better chance it will prove to be useful than I've implied in the past. It is exactly my point that a shared underlying engine will mean that a contract manager and a user and a service desk operative and the account manager and the service delivery manager and the service designer are all working off differing views of one common service definition, and seeing only those services that pertain to them.

ten years ahead of the game

I think you're ten years ahead of the game Ian.

I just sent off an article on how IT must stop doing the business's job for it, and your description of service catalogue fits that. Unfortunately I've also assigned the rights for a while so we'll have to wait for that post to appear here :D But rest assured that in future i will be developing the point that so many IT functions aren't IT functions at all; they should be run by the business: risk, compliance, service desk, change, project, release, service, catalogue... in some cases IT shouldn't even have their own standalone version any more than marketing or HR should

But that's the future. Very few firms are going to buy into that today. Right now IT has to develop its own centres of excellence with a view to the organisation catching up one day. Sorry but the idea that the organisation is going to do service catalogue for us today is in 95% of cases pie-in-the-sky. I spoke to a very senior exec in a very large organisation who was in charge of a customer-focus cultural-change program across the whole org. He'd never heard of this "service management" thingy and was intrigued to hear what IT was up to, especially the idea of a catalogue, also an unfamiliar concept (I refered him to USMBOK LOL).

if IT waits for the business to embrace service management concepts we'll fall even further behind. it is a drum I will be banging - as you know I have a generic service management book in preparation. But in the meantime IT has to walk before the organisation runs.

The Martin Peters of Service Management?

Hi Skep

Ten years ahead of its time ... I wish... The USMBOK was an effort, partly out of frustration, to document my view of what service management is, based upon my own personal experiences, what I had used for many years following much training and practical involvement, and the plethora of good guidance to be found outside of traditional IT references such as ITIL.

Rather than ten years ahead, I think its about in time with what we see around us in the business world, and that the current IT tactics might be ten years out of step.... Just look at how we conduct our daily lives - society if surrounded by service management, products and services carefully managed by unseen hands and thrust at us via the internet and our iphones and such. We in IT need to do a better job of lifting our heads and looking around us to understand teh type of service encounter and experience our customers desire....

As for non-IT folks - they have 'catalogs' - another name might be used (brochure, product catalog etc), in my house the most common example would be the slim Victoria Secret's Catalog that flops to the floor every week after my wife's recent online excursion at their store - all carefully tuned to what she has been looking at... also Google 'Service Request 311' to find a plethora of non-IT focused 'catalogs' that have successfully started with the humble service request.... clues abound

big revelation

The "big revelation" is simply that some things are readily automated and some aren't, and automating the customisation of views of a catalogue seems to me one of those things that is.

I have already stated several times that i think Service Catalogue is product du jour in the industry, the next focus of hype as the world realises what a crock CMDB is. I'm not changing that view - I'm just reasonable enough to acknowledge when there is actually merit in the idea.

At no point have I said rush out and buy one now without process or planning. I've just written a fifteen page roadmap for a client on how to get to a functioning service catalogue which is why I was pondering this closer than usual. This technology is as silly as any other without practices, culture, roles, metrics etc etc etc

I'm not recommending newScale. Rodrigo is the most active participating member of the service catalogue community that i can see so i mentioned him.

Chill guys - technological comment is actually allowed on the IT Skeptic. I thought I was the technophobe

Neither A Tech Luddite or Evangelist...

Skep,

My main point, which I may not have made as well as I'd have liked, is that there are things that go into having a service catalog be successful that are beyond what IT can reasonably be expected to be reliable for -- service marketing is one of them. The number of folks who would have this type of experience is small (being generous about it, for the moment) and I suspect many organizations don't even realize that the area needs to have any attention paid to it. Service marketing is only one area of several worthy of attention for any organization serious about a service catalog initiative. I heartily endorse using catalog technology where it makes sense, provided that the net result is more focus on the customer.

kengon

Like it

I like the thinking that service catalog development is more of a marketing exercise than anything else. I think that is also why IT has such a hard time with it. Is not one of the foundational reasons for ITSM as a practice the need to "show the value" of IT to the business? That's marketing as well. IT does not know how to market themselves, hence the Service Catalog difficulties (and definition of a service as well.)

DavidT

spread the word

That's a good point Ken. I'm sure that IT folk can get their heads around the concepts of service marketing as much as anyone - they just need to be informed. Catalogue does indeed lead us into a whole range of stuff not touched on in ITIL, though to be fair Service Strategy does get into the marketing aspects - perhaps not as systematically as USMBOK but it is there

your endorsement...

sorry 'bout the reference to the old BMC WP....I did see your post(s) in this regard and was supportive of your comments...

but some of the Service Catalog banter seems hauntingly familiar to the CMDB madness to me...especially when you consider that starting by creating a catalog of services is a good place to begin an ITSM adoption program...which DOES NOT equate to "buying a Service Catalog tool!"

by including 'the IT Skeptic endorses a technology' I think you may give the wrong impression. Don't you endorse ANY technology when used as required? if you COULD get a working CMDB, wouldn't you endorse that too?

I've used HST references and the Savage Journey to ITSM excellence references for a reason... from what I've seen over the past 4-5 years, most ITSM initiatives have been Inside-Out (or bottom-up, or manufacturing mindset oriented, etc.). Even the Service Catalog vendors succumb to what is perhaps inevitable: IT-oriented service definitions and Technical Catalogs...and I don't see this moving us very far down the road to business alignment either....

The Service Catalog vendors may be in an ideal position to (finally) establish a Business Lane for ITSM Road Maps, but I am (Skeptical) that they will lead this charge. It's simply not the easiest/quickest path to $$$...

In the meantime, I'll agree with Ian on Outside-In, and continue to use service monitoring intelligence to break down those tribal walls. It gets you closer to CSI which is where the journey really is anyway.

Sorry if I overreacted...

John M. Worthington
MyServiceMonitor, LLC

"outside-in" catalogues

It is in the context of "outside-in" catalogues that it occurs to me we want to show a catalogue view that is customised to that specific customer when discussing services provided, and customised to a specific user when providing a list of actionable requests. it is the technical view that DOESN'T need customisation, as in the diagram above.

In other words it is only by having a customer-centric approach to catalogue that one creates a business requirement that might justify buying a catalogue tool.

Two valid reasons to do so

Again I'm confused as to what has changed? Why would you ever have shown your customers, or users, services that aren't relevant to their domain?

The only reasons I could justify are sales related. Pre sales you might want to convince a customer of the full scope of your capability, and post sale you might use it as a ploy to expand the service the customer is buying. Nothing makes someone want something quite as much as being told they can't have it but other people can.

Make it easy for the customer to buy/use...

James,

You're right on this. A well designed catalog should ensure that a customer doesn't have to think to make their "purchasing" decision (whether that's making a request for service or actually purchasing something). Our efforts should help to remove ambiguity and questions during the purchasing/buying process. We need to state things in terms the customer understands -- using their language, not IT language.

I don't think it's as much about one segment can have and another can't. The intent of providing other views are specific to the customer segment being addressed. For example, a business may present different choices to a SMB than to a Large Enterprise. Their wants and needs are different, the way they do business together may be different, etc. In the end, you've still got the same set of atomic "components", you're just positioning them to fit the customer.

kengon

I just sold services A, B and Z

...which is exactly and precisely what this post discusses and the diagram illustrates. If you design your catalogue with different services targeted at differing audiences then you really want to present the correct set to a specific customer.

likewise you will have services that are currently provided to some customers for legacy reasons but you don't want to offer them to any new customers.

i can see that becoming complex and fraught with risk in some organisations;
"Hey guys I just sold services A, B and Z to the new account".
"oh no not Z!"
"And they want to know why we've never offered them Y before"

Don't quite see it...

Skep,

...which is exactly and precisely what this post discusses and the diagram illustrates.

I guess I'm going to have to chock this one up to a difference in interpretation. After looking at it again, I was unable to extract what has come out in this thread from what you used to seed the discussion. If that's what you meant, OK. I'm not here to beat anyone up!

If you design your catalogue with different services targeted at differing audiences then you really want to present the correct set to a specific customer. likewise you will have services that are currently provided to some customers for legacy reasons but you don't want to offer them to any new customers.

With you on both points here...

i can see that becoming complex and fraught with risk in some organisations

Without a doubt!

The hard part about the conversation is how simple the task actually is when we start working things from the customers perspective. That's where I think it goes off the rails. The usual methods have us try to build things from an Inside-Out (from IT to the customer) perspective and that's a sure formula for failure.

"Hey guys I just sold services A, B and Z to the new account".
"oh no not Z!"
"And they want to know why we've never offered them Y before"

Sounds like a team that doesn't understand how to manage a service portfolio or a customer relationship well. In a certain sense, this goes back to a point that I was making earlier about the things that IT hasn't been good at (historically speaking). Effective management of needs, wants and requirements is essential and these are all upstream of the catalog -- they're focused squarely upon the customer. An organization that can do that properly is well positioned to anticipate their need before a customer can articulate it.

kengon

per se

In an idealised world then perhaps everyone in IT will understand everything you allude to. Meanwhile down here on Earth, there are some IT account managers that are no better than some software salesmen I've worked with. You can have the best people money can buy designing the whole emperor's procession of roles, processes, market spaces, requirement analysis, product designs, marketing plans and whatever else that culminates in a service catalogue that is so far up the customer only the shoes show. And then Slick Harry goes off to his customer and f***s the whole thing up for you. A tool that captures some of that smart packaging you've designed and automates the various views might help reduce error. Just sayin'
[Sorry Chris I've stolen your sayin' ...er... saying]

I'm willing to accept that many service catalogue designs are seriously flawed, but I haven't talked about the process at all in this post. My very limited experience of service catalogues has been of working with the customers, and structuring the catalogue around the business processes that IT supports, or at least trying to. But I have also seen technical attempts at catalogues and I can see that a catalogue built in a CMDB or other ops tool could get seriously skewed, so I'm not disagreeing. That doesn't make service catalogues a bad idea per se. Or service catalogue tools.

A tanker size hole

I was doing an ISO 20000 Foundation course today. Between SLM and BRM I explained to the group that ITIL V2/V3 and ISO 20000 have a major part missing, a tanker size hole actually. There is no sales & marketing. Now I got the feeling that you are discussing on the edges of that.

In my experience most IT service today is commercial, the big dinosaur internal IT departments are gone. Sales and marketing define and decide services and SLA's. ITSM has to run to to produce them. One sales guy explained me that of course we got to sell stuff they don't have yet, how else we are going to beat the competition.

The conflict between production and sales seems to be eternal. ITIL ignores it.

Aale

Account managers

Just some account managers who are no better than salesmen? I'm already seeing them sell the concept of the service catalogue as the solution to world hunger...and not delivering.

Yes service catalogue is a great idea, yes it can be done - actually relatively easily compared to say a CMDB - but man cannot live by sprinkles alone, there has to be a cup cake to put them on.

Call it baked...

OK. On this note, I'm gonna call this one baked...

kengon

Where the requirements are

Ian has got me thinking about this with a post he made on Linkedin

The customer requirements are out there, whether IT is aware of them or not. They have an impact on, and are impacted by, both the services we currently deliver and on those that are contemplated, as well as the customer's wider environment and culture. They are also capable of being modified and refined if we get our approach right across both, to the mutual benefit of IT and the customer.

One of the consequences of the shift towards a life cycle model I've seen is a turf war between programmes, projects and service management over non-functional requirements. I think that is quite understandable, though not desirable. I hate to use the cliché but we need a much more joined up approach that makes best use of the skills and perspectives of the different parties. I've been lucky in the past in having worked with various test managers who did a good job of acting as honest brokers between the parties, but you can't rely on that.

There is a role for the service catalogue, or something like it, in this mix.

attitude

The only thing that has changed is my attitude to the technology. I've just thought more about the logistics of user and customer catalogues. I've never done a user one (listing requests), and customer ones have been for one major customer or have been consistent across customers. But I can see that in some situations it would be a pain in the butt editing a document to suit the customer and it would be useful to present a custom view of requests to users. Offering people things they can't have doesn't engender affection, and it requires tedious explanations. Unlike CMDB it appears relatively easy to automate. I worked with ASP user-provisioning "catalogues" a decade ago (ask Rob Stroud). The hard bit is the business model - loading the technology is pretty easy.

Boiler plating

Rob,

Most of the early catalogues I worked on were the product of boiler plating, as were the SLAs they were used to produce. Actually these days I think we did more customisation than was required - in reality it would have been better to establish a good but non negotiable commodity service baseline across all customers and then only focussed on the service differntiators.

My concern with the current hyping of tools in this area is threefold.

Firstly people are seeing it a s a silver bullet
Secondly they going down the service catalogue root without the internal maturity or customer empathy needed to make if successful
Thirdly they are neglecting the functionality of service management tools they already own, or of tools being used by other parts of the organisation.

A common complaint I hear from users is "How come I can order x from the on line supplies catalogue, and it turns up at lunch time, but to order a mouse I have to go to another system that isn't as good and it takes a week to be delivered, if I'm lucky?"

We need to be looking at how we can integrate IT request and ordering with other internal business processes, such as HR's new starter process, and we need to be thinking about how we deliver against the expectations that on line ordering raise with the users.

not a professional look

Agree with all of that. Catalogue is as hyped and techno-fixed as any other area of IT, more so right now. I don't see that my post suggests that isn't the case or that i have promoted a techno-silver-bullet. You guys all know me better than that.

One point of clarification: I am talking about both the customisation of the content of each service to match what has been agreed with the specific customer as you discussed, but I was thinking more about the customisation of WHICH services are presented, as the diagram shows.

It is indeed better to start with standardised service boilerplate and generic SLOs but reality is that we can end up agreeing to variations. This just adds another level of complexity to be tracked. It is not a professional look - and not customer-focused - to take a catalogue to a customer that includes services they don't currently take but it says they do; that offers them services they can't have; or that has the generic terms and fails to include their special arrangements. My point is simply that I can see technology (wherever you find it) being useful here to eliminate human error and support clearer communication.

Be hard

Rob,

Yes technology can help, none of us would dispute that, but it has not magicaly enabled an approach we could not/should not have done anyway.

My big concern is that it is more damaging to appear to offer a degree of customisation that cannot be delivered than to appear inflexible but to deliver what you have promised.

Understanding what you can customise has lots of dimensions; you need to understand your capabilities, your costs, how you charge, the risks of failure, how other customers will react if they find out out customer x has got a premium service that they don't .... the technology issue is actually way down the list.

And then there is the question of whether customisation is actually the right path to take.

I would rather be firm that this is the service we can guarantee than make empty promises.

Out of the Box ITIL

Did you see BMC's latest White Paper titled, "Can you really get ITIL Out of the Box?" They even have a chapter called

Addressing the Skeptics' Concerns

here's one quote you may like:

"The CMDB is the heart of the ITIL implementation. Conse- quently, an ITIL out-of-the-box solution should implement a CMDB automatically, so that the user need only populate the CMDB with the data describing the organization’s IT environment."

:)

John M. Worthington
MyServiceMonitor, LLC

old BMC rubbish

That's an old paper John. Ken Turbitt wrote it when he was still at BMC. I blogged on it here

It's not the technology...

Skep,

Before I say anything else, I'll say that I have no issues with the Service Catalog -- either the concept or any given technology. I think that they are an important artifact. There are lots of ways to implement one and don't have to be complicated.

Where I do have a issues (more like concerns, actually) is:
1. This will be turned into the next "it" technology (as if it hasn't already happened), without a fundamental basis for its adoption. For crying out lout, there isn't even a consistent definition of a what a service is amongst professionals working in ITSM, let alone the ability to define and construct one properly. Is there some "magic potion" that suddenly resolves this? Think not.
2. The responsibility for a service catalog lies within the scope of responsibility of marketing. They are your team members who are responsible for addressing a customers wants and needs.
3. While we're on the topic, I see the word customer, but where are they represented? Who's looking out for what's good for them?
4. One of the key prerequisites for a marketing type is to understand the service portfolio. It's unlikely the marketer will be successful without that input.

Without these things, companies run the risk of turning a perfectly viable concept/technology into the next casualty in the battle of the "next technology wave".

The whole thing about "Outside-In" thinking (and Outside-In Service Management) is that it's all about the Customer. That might be relevant here... ;-)

kengon

And your point is?

Rob,

You've lost me on this one.

We never have needed a sophisticated technical solution to telling a customer what is available to them, even in quite complex areas. If you've needed a technical solution at this level then you've probably been defining your services at the wrong level of granularity.

If you are talking about a user level request/ordering system then there is a greater need for some technological help, but nothing that hasn't been around for ages.

So what is the big revelation?

James

OK, so now what?

Et tu, Skep?

So we should run out and buy a NewScale solution? You planning a career change?

I do not argue your point, only the result it's likely to stir up. Solutions abound, but the fundamental problem may not even be understood (IMHO). I've ranted about IT's manufacturing mindset, the need for Top-to-Bottom design approaches, and even Outside-In perspectives.

[NOTE: The term 'Outside-In' is generic, but in the interest of full disclosure Ian has copyrighted Outside-In Service Management, and I believe he and I are very much on the same page here. I suspect/hope we'll see his comments as well.]

It is not the Service Catalog per se, but the creation of the Catalog that really matters. How are you defining services? From what perspective? Rodrigo's upcoming webinar may touch on this topic, which would be a very useful service to customers if it does; but I think we should separate the tool from the process/technique.

I agree at some point a Service Catalog can be very helpful, but focusing on a solution before we understand the problem is CMDB madness all over again. The silo-ed nature of business and IT organizations, the pace of business and technical change, ever increasing complexity and pressure to reduce costs are driving business/IT to miss the basics that people like Peter Drucker taught us over 50 years ago.

A Service Catalog technology is not going to address that.

John M. Worthington
MyServiceMonitor, LLC

Is this a 'Kick Me' Service Catalog Strategy?

Why, why, why do we do this to ourselves. We now have lots of companies rushing around with another sharp object - scissors in the form of a service catalog. As others have started - we need one - its just how we get there. Many of the ITSM project leaders I meet already have a 'kick me' sign on their back and are sniggered at when they leave the room. Now we are being led again by the software vendors to buy more software.

To effectively offer a service catalog you need a portal and customer experience management strategy (thanks for OI-SM connection John - more on that new book next month). Lets take a simple example - the local pizza delivery here has a website and a portal that includes a menu (catalog) and an approach to understanding how their customers want to interact with them and their services. Version 1 was a very clever piece of web development work that allowed folks to build a pizza - like a video game.

It was not what customers wanted and the pizza place phones still rang with orders. Version 2 was simplified and allowed subscription based ordering (through an online account) that remembered your past and most common orders and sped up ordering by allowing one-click repeat ordering. SMS text msgs were optionally sent to your phone advising on progress... "at your front door in 2 mins".

The basis for Version 2 was customer interviews - "what do you really want", as opposed to - "here is what we think you want". This simple example illustrates why I believe current ITSM approaches that lead with process, best practice, capability development or technology are INSIDE-OUT. They will fail the customer.

As Ken said, understanding the customer's preferences and the required 'experience' is a marketing skill of old. As others have said - walk in the customer shoes for a day, for a service request... and while you are at it Google Service Request 311 and ask a local Council or two how they approached building those systems WITHOUT buying a service catalog tool... Which begs the question, perhaps the yare now all prospects for one???

Service entries are built ground up - from request level. As I blogged on a linked in thread somewhere - where was that James?

Reverting to type

We do it Ian, because the IT industry reverts to type.

Here we have some concepts that finally make it into ITIL that should make it absolutely clear we need to think about services and service design from a customer perspective.

What do we do in response?

First of all we ignore all the interesting work that has been going on in the wider, non IT, world of service design.

Then we start using the right language but start to debase what it means. Look at how often when people claim to be talking about a service catalogue they actually mean a user facing order and request interface. Look at the type of things they put in as services as well and at how thin the veneer of customer speak is when describing services.

Finally of course we have to implement the idea by buying a new tool.

If IT was in the pizza business they wouldn't sell you a cheap takeaway meal. They would sell you some dough, some tomatoes and some cheese. They wouldn't deliver it in abox unless you'd specifically asked for one,

fascinating

I'm fascinated by the response this post has stirred up. Why do who do what to themselves? Is what a "kick me" strategy? Where did I say "buy a tool before you create a catalogue"? Where did I say "everyone needs this regardless of requirements"?

At no point anywhere in the post did I say "hey folks go out and buy yourself a service catalogue with no prior thought or planning or design". Perhaps I should prefix any comment I make about technology with "don't try this at once" warnings, but it is only a humble blog post not a technical white paper, and that applies to any tool equally - nothing special about catalogue there.

I've slagged the idea of a service catalogue tool in the past, putting it in the same bucket as CMDB. It occurred to me that there are valid points why it a catalogue tool isn't a totally dumb idea. I made those points. We can have an extended discussion about how to approach service design or when and how to spec requirements for software but please don't slag the post for not including one.

We are discussing stuff inside out

Skep

I posed the why question to everyone not just you - although you seem to have picked up and propagated the business/technical service catalog concept, which is as yet to a myopic view of things and another straw on our collective backs. I read everyone trying to define a service catalog and few, if any, trying to understand what the customer need to get their business done more effectively, efficiently.

Here we are trying to imagineer ourselves towards a service catalog. I see too many that are over-engineered and miss the target. It took ITIL 11 years to respect the humble service request. Now we have vendors collaborating to clarify the contents of a catalog so they can 'exchange data', a la CMDB. Interesting and valuable, but would a customer pay for it? No - so its inside out thinking again and exactly what gets ITSM a bad name for the wrong reason. My frustration was all about why we as the collective professional IT community allow ourselves to let vendors put a software ring through our nose.... Well? Why?

The good aspect of Skeps blog and being able to blog with David, kengon, James etc is that we get the chance to exchange exactly the thoughts I thought itSMF would enable us to do at conferences, and by doing so build requirements for vendors.... we are truly an ass about face industry. We chant process before technology but forget its also customer before process... or at least desired results before process...

A Gem of a Thread - Anyone up for a web based version?

Gentlemen - and I use that term loosely.... :-)

This, along with all too few threads on linkedin - is exactly the type of conversation we need but miss out on at industry conferences. A few years ago I chaired such open q&a with celebrity panels when helping build out the itSMF USA organization and conference. Sadly they have vanished to be replaced by what I call 'wall papering' - presentations with limited chance of proper feedback and discussion.

To my point - assuming I have facilities - what do you think of us hosting an online event where this type of question is tabled and panel members get a chance to chime in....?

Roundtables

There have been some interesting articles over recent years about the optimum numbers to make committees, communities and workshops work.

Google Dunbar's Number.

I'm sure growth in numbers is one of the main reasons why it is so hard to do this. It was amazing last year to run an itSMF regional workshop session alongside Ivor MacFarlane and to realise how much people valued feeling that their voices were being heard by someone from with "Castle ITIL". I have to agree that most ITSM conferences I go to offer little chance of such a meaningful debate. My personal view is that v3 should have been preceded by a massive community debate of some sort.

So yes, I would back the idea

reach the million

Chris Dancy at ServiceSphere is on that path already, doing great things, and I'll bet there are others whose network we don't touch. the issue is that such awareness needs to reach the million or more people now practicing ITSM, not a few hundred.

Syndicate content