There is only one service catalogue
Technical vs Business service catalogue: we had a go at this argument previously but I am discussing it again over on LinkedIn and I have - I hope - a clearer way of stating the position. 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. It gives IT staff entirely the wrong attitudes and mindset. So here is my shot at a definitive statement of position on Technical vs Business Service Catalogue. For any organisational unit, for the services that are the outputs across the boundary of that unit, there is only one service catalogue ...and only one set of services.
Technical Service Catalogue and Business Service Catalogue and Fred Service Catalogue are names for different VIEWS of that catalogue. But there is only one set of catalogued services that cross the boundary of an organisational unit. The "technical" in Technical Service Catalogue does not refer to what kind of services are in it - it refers to who uses it: technical staff within the provider. Likewise with a Business Service Catalogue: it presents information of interest at the business level when talking to customers.
I find it astonishing that the IT community can be so divided with two totally different understandings of Technical vs Business catalogue. The poll we had showed me to be in the minority. That hasn't changed my mind.
My axioms:
1. There is only one set of services that emanate from any organisational unit - they are the outputs of that unit.
2. A service catalogue should only be associated with one unit
3. A service catalogue should only catalogue the services produced by that unit, i.e. those that are the output of that unit, which cross the boundary of that unit.
[updated, 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.]
4. There can be different views of the catalogue. All views describe the same services, only in different ways.
5. Different actors can see certain views and certain subsets of the services within those views, depending on their role and profile
A business service catalogue for an IT department describes the services produced by that department, from a business (i.e. customer) point of view.
A technical service catalogue for an IT department describes the services produced by that department, from an internal (i.e. IT staff) point of view.
Same services.
If an activity is not consumed as an output of IT by a customer of IT then it is not an IT service. Period.
If internal units within IT e.g. network group, want to have their own little catalogue and provide their own little "services" to the rest of IT, that's nice but it is not a service to be catalogued in the IT Department Technical Service Catalogue. Network Group can have their own catalogue which defines the outputs at the boundary of their own unit, i.e. their services. So the network service can appear in the Network Group Technical Service Catalogue and in the Network Group Business Service Catalogue and in the Network Group Fred Service Catalogue, but it does NOT get catalogued in the IT Department Fred Services Catalogue or any other catalogue that is describing the IT Department.
A network service might be mentioned in descriptive documentation within the IT Department Service Catalogue as an underlying or supporting service but it is not CATALOGUED as an output of IT because it isn't (not in my example. I know occasionally networks are a service - in the case where IT is a low level infrastructure provider to the business).
"IT Department Technical Service Catalogue Appendix A: internal supporting services used by IT Services.
1) Network Service..."
To me anything else completely debases the purpose and meaning of services, and defeats the whole point of ITSM which is to make us customer centric. "Technical Service Catalogues" full of internal IT "services" are a gross example of the kind of inside-out thinking that got IT such a bad name in the past.
More on this:
ITIL services are customer facing
Do we overcook services?
[Updated: moving material up from comments:]
"For any organisational unit...". When you subcontract or outsource you introduce an organisational unit - a supplier. If an organisational unit delivers services they should have a catalogue. That's why I adopted the cumbersome term "organisational unit" so as to be as generic as possible. (I can envisage that a technology team within IT in a sufficiently large company might adopt ITSM and deliver service). it is fractal.
hexagon=organisational unit
Whoever is delivering the IT, it behooves them to define what it is they deliver. That's a catalogue. We need one of those. it isn't a pointless bureaucratic exercise and it doesn't slow us down by having one.
To me a service catalogue is any directory of the services provided. There are a wide range of interpretations of that depending on the context:
- the services provided and available to one single customer, described in a nice glossy brochure format
- a list of all services provided to everyone used as a reference within IT
- an interactive webpage that presents subsets of services depending on the user's profile: role and organisation
- a piece of software that lists services and available requests, and provides automated fulfillment or at least initiation of requests
- a type of CI in a CMDB, presented or reported by the CMDB software
- a technical document with internal technical definition of what the service REALLY is, along with info about policy, service levels, pointers to procedural documents, specifications, SDPs...
- a list for Customer Relations staff with service options, pricing options, and CRM data
- a collection of contracts in a ring binder
They're all catalogues.
The VIEW of the catalogue is dependent on two things:
1) the overall TYPE of catalogue. ITIL has a crude two-types model: Technical or Business. personally i have a six-way model, I've seen eight. Different views see different attributes of the service, and possibly different subsets.
2) the profile of the consumer:
- role: employee, supplier, customer, user...
- organisation: customers from company X see different subset of services from customers at company Y
- etc e.g. authorisation level
Maybe it's the old data modeler in me: there's only one service entity-type and they are recorded in the catalogue "table". there are many views. You could use the word "catalogue" for each view but that is confusing and misleading. the term catalogue has already been used by ITIL to label the subset of the portfolio that is available. We add qualifiers to "catalogue" for the different types: Technical SC etc etc.
So how you present it depends on who you are talking to.
How you slice the content up depends on how the customers see it (or if they have no idea what IT does, as is often the case, then slice it how you want them to see IT), not on how IT sees it.
The reason I am so anti tech catalogues that contain something different, and so passionate about not allowing IT to cut up IT as IT wants to slice it up, is that one of the most important uses of a service catalogue is to get IT thinking in terms of what we deliver, and seeing ourselves as our customers see us. If a service catalogue gets in the way of that it is a failure.
if a service catalogue allows techs to crawl back into their dark hole to work on "their" service regardless of what the customer is experiencing then it is a failure.
I'm troubled by the remark [in comments below] "is not a contender to be included in either a customer or business service catalog". Are you implying it IS a contender to be catalogued in a technical service catalogue? So what is a technical service catalogue? "It is a catalogue of the services that..."? what? or put another way: what is a service? What does service management manage? Surely a service is something we apply SLM to, something we plan availability and capacity for, track in a service portfolio, assign service owners to, discuss with the service customers, do request fulfillment for, build Service Design Packages for... etc etc
You do all that for a network "service"? Surely not. It's not a service. You said it yourself, it is a core critical IT system. A "system" is a high-level CI that sits in the CI taxonomy just below "service". A service is made up of systems [...some of which are applications, Charles]. The Network Team don't have customers. Go ask them who their customers are, how they manage their customer relationship, how they fulfill service requests.
What I object to is teams who do not enact the service ethos, adopt none of the SM techniques, fail to participate in the departmental processes, but demand that 'their" service be in a catalogue.
And even when a team does adopt SM principles, there is no need for a catalogue in all but the largest most complex organisations. An overall OLA will suffice.
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 wone 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. [Book review to follow one of these days]
[And more from this post:
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 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.
See also:
ITIL 2011 persists with the dangerous concept of supporting services
ITIL services are customer-facing, whatever catalogue they appear in
A menu is not a service catalogue
and other posts on the topic of catalogues
Made in New Zealand 
Comments
clarification: technical vs. business catalogue
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]
Drawing to a close
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!
counter-productive
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.
Easy concept
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.
Not so easy
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
Sorry I missed the conversation!
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.
ERP4IT
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.
Out of the box...
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.
clarification: one catalogue
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.
Several catalogues or one?
From which point of view do you want to look at it?
If you look at it from the point of view of the Business, that uses IT services, then one IT provider has one business service catalogue (I hope :) ). Usually the business deals with more than one provider (I realize that you look at this differently, I describe the reality I see around me).
If you look at it from the point of view of the IT provider (external or internal): most IT providers have more than one customer. Even internal IT departments nowadays (they act as external providers for other companies).
I think they should have a customized SC for each customer, therefore most IT prociders will have more than one BSC. They have only one service portfolio.
Technical Service Calalogues may be considered as 'lower level' BSC's. The customers of the network providers are often other IT providers.
Maybe we should call them all : Customer Service Catalogues? For some the customers are business companies for others the customers are other IT provides.
Lean Thinking calls for fractal service catalogs
Found this interesting quote in Womack's Lean Thinking :
"... the value stream manager develops the vision for the product, determines the Current State of the value stream, and then envisions the Future State. She or he then treats the functions as the suppliers of the essential inputs (for example, engineering, operations, purchasing, sales, lean knowledge) needed to reach this state...
"Finally, we've discovered that these value stream and product line managers, like so much in the lean world, are fractal [emphasis added]. That is, a product line manager overseeing an entire product may work with a number of value stream managers at lower levels taking responsibility for different courses of
the value stream. For example, a chief engineer (to use Toyota's term for a product line manager overseeing an entire automotive platform) works with a
development leader in design, a value stream manager in the assembly plant, and value stream managers in each of the component plants working on major items assembled into the finished product. Each manager is essentially doing the same job but with varying scope—wide at the top and narrow at the bottom."
I think what you are saying supports the fractal nature of these services. And that is the aspect I am more interested in. If that essentially fractal nature is there, I don't really care about an outside-in versus an inside-out view ("Business" vs. "Technical" views). But I don't think it's helpful to dismiss (as you did on the other thread) smaller catalogs as "toys."
Charles T. Betz
http://www.erp4it.com
imposters.
Yes I support the fractal concept, the diagram shows that
What I object to is teams who do not enact the service ethos, adopt none of the SM techniques, fail to participate in the departmental processes, but demand that 'their" service be in a catalogue.
And even when a team does adopt SM principles, there is no need for a catalogue in all but the largest most complex organisations. An overall OLA will suffice.
Just cannot agree with a single catalog
I just don't think the concept of a single catalog is a useful idea going forward because it does not represent the likely case.
I assume that the IT function will, increasingly, be broken down into services provided by disparate functions. That IT will act as a Contractor with any number of subcontractors with subcontractors. Fractal, if you wish. This is the lesson of manufacturing - which is now mostly design and final assembly - the parts are almost all subcontracted.
Manufacturing left behind the end-to-end factory generations ago. Construction and other industries live the subcontractor model.
IT will, within five years, leave the single, end-to-end production model far behind.
Each of the services, each of the pieces, will be subject to subcontracting. The customer-facing service will have a product manager. The product manager will fashion the product out of any number of subcontracted services.
Each of the individual skill groups, like Database Administration, will act like a small Professional Services Firm (Tom Peters concept) and will be subject to buy decisions (internal / external). Each of the services will be subject to make/buy, insource/outsource decisions.
Because each is, potentially, independent, each may have their own Service Catalog.
There is much to do to reorganize IT so exploit the possibilities of narrowly pointed outsourcing. Time to get started.
Insistence on a single service catalog, even with different views, is a relic of the end-to-end model of production.
Cary King
Minerva Enterprises
Managing Partner
www.MinervaE.com
End to end model of value
Cary,
Let's just be sure to not lose the end to end model of value (aka value stream). That is not outmoded.
Charles T. Betz
http://www.erp4it.com
Deckchairs on Titanic
The end-to-end value chain is the Product Manager's and the Customer's view. The outside-in view, as Ian Clayton might put it - remains vital.
Everyone agrees, I would think, with the idea of a single service catalog from IT to the rest of the organization - the customer facing view of the catalog with different views for different slices of customers with different entitlements.
I'm just not sure a bureaucratically-burdened anything, and a single service catalog will quickly become so, will be conducive to the agility, innovation, competitiveness and entrepreneurship that is so sorely needed.
What I'm concerned about is competitiveness. I'm worried about the costs of the ever-growing, soviet-style, highly-centralized view of IT from people, including ITIL zealots that take ITIL as a codified structure instead of as "good practices" to be adapted for recogizable benefit. Simply, processes don't do work, people do. Realized benefits are primarily an outcome of good management and not necessarily the best technology.
Process is just a way to organize so that average workers can produce excellent results consistently. Not a means of burdening them with often non-value-producing work because some author of ITIL said so.
It seems to me at this time that increasing bureaucracy and overburdening price-competitive entrepreneurship might well kill what advantages organizational IT has left to it.
In terms of organization and financial management of IT, there seems to be a retrospective, heavily status quo bias, "We've always done it this way." It seems to me that we would be better served if we looked prospectively, to the reality of what is.
IBM, HP, Microsoft, Wipro, Infosys, TCS, Dell/Perot, Xerox/ACS, Google/CSC, Amazon/Capgemini - they're all marketing directly to the business, our customers, to make internal IT disappear.
The technical issues of cloud and outsourcing will be solved. And, the legal issues will be fixed with big donations by big companies.
It's time to improvise, adapt and overcome. It would seem that each individual mini-PSF within IT either gets price competitive and entrepreneurial, and proves it to the business regularly, or updates their resumes for the list of companies above - while you can. The days of the business having to come to IT, or massive outsourcing, are bygone days.
As Gen. Bill Creech wrote, "Many people believe that decentralization means loss of control. That's simply not true. You can improve control if you look at control as the control of events and not people. Then, the more people you have controlling events -- the more people you have that care about controlling the events, the more people you have proactively working to create favorable events -- the more control you have within the organization, by definition."
Cary King
Minerva Enterprises
Managing Partner
www.MinervaE.com
folding deckchairs
While I don't disagree with your thesis, I think your burdening service catalogue with a lot here :) Whoever is delivering the IT, it behooves them to define what it is they deliver. That's a catalogue. We need one of those. it isn't a pointless bureaucratic exercise and it doesn't slow us down by having one.
Nor do I think we are shuffling deckchairs on the Titanic. For most of us that particular iceberg is years away yet and right now everyone is falling all over these goddam deckchairs that need to be lined up and folded properly before someone gets hurt. That's what ITIL is about. I have a great interest in governance but it doesn't get discussed on this blog much because the folk who come here are in charge of running the ship not determining where it sails to. ITIL isn't about that, ITIL isn't even about setting course and steering the ship. ITIL is about operating a ship, and whoever owns it and wherever it goes they'll still need to do that. Even if they contract out to someone's much bigger ship, that shipping line will still need to run their ship properly.
You can have stuffy bureaucratic ITIL and you can have nimble clever ITIL. It's a function of the culture not the framework.
Even if totally outsourcing IT is going to happen - and I think forecasting shifts THAT big is a brave move - then it is going to happen and there's little internal-IT can do to compete if it really turns out to make business sense.
Fractal pyramids
Looking at these discussions it seems that service catalogs are just not easy to define. I have not read Mark O'Loughlin's book about the service catalog, just a (glowing) review and some articles written by Mark, but it does not seem simple. Mark's eight service catalogs, a service portfolio pyramid and the fractal service catalogs discussed here indicate that this can be complex matter. Actually it looks to me that Mark and Rob have quite different interpretations on the concept?
Rob argues that any document about agreed services to a customer is a service catalog. Maybe this is splitting hairs but I disagree, separate service contracts do not create a service catalog.
Aale
a service catalogue is any directory
To me a service catalogue is any directory of the services provided. There are a wide range of interpretations of that depending on the context:
They're all catalogues
The big issue of the service catalogues
Hi Rob,
I believe that one of the issues making the catalog such a difficult thing (so difficult that some people want to split it into two or more) is the inconsistency and variance of the vertical integration in manufacturing IT services.
Right now I am working on integrating a new outsourcing contract for a mid to large sized IT service provider. The service agreement contains several types of services ranging from high-level business services, down to data center housing. Setting up a service catalog that integrates this wide range of services which is still useful (and can be understood) is hard or impossible.
So I can understand the call for a technical and a business catalog, the former having all the basic technical services starting from housing, networking, server/systems management, desktop IT probably up to the database level. The latter contains specific business focused service, e.g. printing, archiving, dedicated business transactions etc.
I am not sure what the ITIL proposal on business an technical catalog really is (even though I am an ITIL certified expert ;-). I do agree that we need a single catalog having different levels of services in there with different descriptions (technical how to view and business marketing view). If we have a potential service that is currently only used internally (but may be offered to the market in the future), omit the marketing part. If we are reselling an outside service without adding (much) value, omit large parts of the technical part.
In my opinion we need to strive towards a more consistend and reduced vertical integration in manufacturing IT services (which is were the cloud comes in).
Regards
Marc
http://buzina.wordpress.com
Scoping the IT Service Catalogue
The question of one or two catalogues comes down to something basic.
Take a look at your company's (organization's) year end report. Track through the balance sheet / profit loss statements.
Look for the IS/IT department... take your time, it is usually not listed since we enable the business.
My best anecdote about services from a business perspective. Regarding Email availabilty, A Senior VP said to me as a consultant.
"All I want to know is when can I get it, should I be made about not getting it, and who do I yell at about it!"
We used that as the scoping statement for the Service Catalogue.
Second story from some government work. "If we can describe our entire ministry to the public in a 2 page brochure, why cant you describe IT?"
Service Catalogue is a list of what services are offered. How you slice it depends on who you are talking to.
one of the most important uses of a service catalogue
How you present it depends on who you are talking to.
How you slice it depends on how the customers see it (or if they have no idea what IT does, as is often the case, then slice it how you want them to see IT).
The reason I am so anti tech catalogues that contain something different, and so passionate about not allowing IT to cut up IT as IT wants to slice it up, is that one of the most important uses of a service catalogue is to get IT thinking in terms of what we deliver, and seeing ourselves as our customers see us. If a service catalogue gets in the way of that it is a failure.
if a service catalogue allows techs to crawl back into their dark hole to work on "their" service regardless of what the customer is experiencing then it is a failure.
That is the goal!
Yes, Rob I perfectly agree on that goal. Still you have to take different lines of service into account where sometimes IT "just" delivers plain tech (still service, but tech service) and sometimes it delivers business enabling services.
Just as McDonalds has multiple catalogues, IT should be allowed to have them. McDonalds has the Morning Catalog, the standard Daytime Catalog and it also has the McCafé Catalog. And damn well, these are outside-in designed catalogs. They just found out that they can sell more and better if they provide customized catalogs to their customers.
Or look at amazon. Their main quality is that they know what you like and present you with a customized catalog (yes, they come from a central database, but who aksing pure implementation tekkie questions now?). So when I go out to sell my services to the business I can either bring my standard catalog of all services and hope I hit the right target with the first 3 services (no-one listens to the next offerings at all) or I can select one of my pre-defined catalogs for this customer and catch them halfway, or I can create an individual tailor made catalog for this customer, based on what I know about them. So Rob, which one is the future? Or to be more exact: which one is current state of the art?
Glen:
The email service sample, to me is usually not a service. It is part of the broader "Working Environment" service (sometimes called Front End, or Workplace Service or whatever). If you want to use 2 pages to describe the IT, you gotta cluster, right? So in your example you did not cluster good enough and you obviously did not spark your customers interest. Talk about Email Anywhere, even on your iPad or whatever is sexy at the moment. That is marketing. The catalog is marketing.
Marc
http://buzina.wordpress.com
We did do the brochure
It took a while but the brochure was done in about 4 months. 2 weeks of design, 16 weeks of research and underpinning elements.
Broke the services into three levels, Operational Services, Planning Services and Business Alignment Services.
Departmental OLAs then mapped to these levels. Service Desk used them to develop escalation and support models.
And regarding email, I agree that it is more of an output than a service, however the customer wanted to know about the email service. It was the keystone in developing the "service catalogue". The client in quesiton was a multi national insurance company.
In the end the business partners questions were around, what does IT do for us? and IT needed to show this is how the support you need is delivered.
Sounds great
Hi Glen,
Sounds like a proper setup. Are the services you defined now the primary basis for talking IT (even inside IT)? Or do the people in IT have a seperate set of things (I dare not call them services) that they talk about?
Sometimes it is like that. I would guess that in an insurance company the mail (snail mail) handling would be more business related (e.g. saving a day on processing mail is a save) than email, but I do know that most business people relate easiest to the email service. So if this is what the business demands, it is what they get.
Marc
The VIEW of the catalogue
Yes I agree. The VIEW of the catalogue is dependent on two things:
1) the overall TYPE of catalogue. ITIL has a crude two-types model: Technical or Business. personally i have a six-way model, I've seen eight. Different views see different attributes of the service, and possibly different subsets.
2) the profile of the consumer:
- role: employee, supplier, customer, user...
- organisation: customers from company X see different subset of services from customers at company Y
- etc e.g. authorisation level
Maybe it's the old data modeler in me: there's only one service entity-type and they are recorded in the catalogue "table". there are many views. You could use the word "catalogue" for each view but that is confusing and misleading. the term catalogue has already been used by ITIL to label the subset of the portfolio that is available. We add qualifiers to "catalogue" for the different types: Technical SC etc etc.
The data modeler and the marketing buffs...
... do not understand each other well. With my database modeling and software development background I could not agree more with you. But as you state all over your blog, don't let the software guys take over. So don't drive a marketing project such as the development of an IT service catalog with technical software development skills.
So in a perfect world we would have a single large catalog (probably in a database table as you described) and there would be different views to it as your diagram shows. But even then you would have the 2 page brochures (with probably 4 pages ;-) which would never be a view of the catalog table. You would have a brochure with your highly technical solutions and a brochure with transactional business services (e.g. online payment processing, logistics management or ERP). Probably people will call those "catalogs".
I still don't see the issue about the number of catalogs as being so important. Even if you have multiple catalogs, you still have (somewhere) a list of all services you provide. It is more important to work the outside-in idea and to keep people on that agenda. If focusing on a single catalog helps you with that, do it. If that has impacts on the way you gather your catalog information, then don't do it, but still make sure that people know what counts.
all on the same page
You need to listen to my podcast on this. of course the customer view is a glossy brochure - nothing I have said precludes that.
I don't too much mind multiple catalogues if that floats your boat, depending on what is meant by multiple. Different customer market segments might have different catalogues for instance, stored and managed differently by different people. The key thing for me is that the catalogue used for internal purposes to define what we do, why we exist, is the same list of services that we show a customer, so that we are all on the same page, all customer-focused, all oriented around the real services we deliver.
One, two, eight? What's important is ...
"The key thing for me is that the catalogue used for internal purposes to define what we do, why we exist, is the same list of services that we show a customer, so that we are all on the same page, all customer-focused, all oriented around the real services we deliver."
I am happy with this - customer catalog.
However you still need to have the business and technical view internal to the organisation to understand how the customer services are supported, delivered and costed by IT and business processes. I call that view 2 separate catalogs i.e. business and IT catalog.
If you are still not convinced, that's fine. I think there has been some good debate here. I can demonstrate eight basic catalogs. But the important thing to remember is what needs do these serve the organisation and which ones do they need at any particular point in time. One, two, eight? Will a customer catalog really help IT make sense of their world and what they offer the business? Will they even understand it?
Anyway, it's another rainy day here.
Realitycheck
I agree with your theory of single catalog with different views. The idea is good. It just seems hard to do in practice.
I wanted to what's the situation in real life and did a quick survey using my Three Question Survey method. I will publish the results later but here are some observations from the answers:
The most common solution is that there is only a technical service catalog and that is updated by IT people. In the first 100 answers there is only one (1%) which is theoretically "correct". The best practice does not seem to be very common practice.
All results are from Finland but Finland is pretty advanced country (according to Newsweek the best country to live in:-). See http://www.newsweek.com/content/newsweek/2010/08/15/interactive-infographic-of-the-worlds-best-countries.html
Aale
Two types of catalog
Also there are two different service catalog types that serve two different purposes.
A records based catalog that contains information (documentation, attributes, links to services etc.)
An actionable based catalog that utilises workflow and automation to handle requests and changes to services.
Aale, I saw that about Finland. It's the cold that gets me!
Not so cold
The July average temperature in Helsinki (21.7 C) was 3C warmer than Amsterdam and 8C warmer than Dublin. Winter is coming but it's not the cold but the wet cold that's nasty, dry winter cold is much better.
Sorry, slightly off topic.
Back to topic. Wouldn't it be a good idea to give a separate name for the actionable service catalog? It is completely different concept and can contain just a tiny fraction of total services.
I prefer to leave invention of new terms to you natives, if I happen to invent a new word or phrase in English, it is purely accidental ;-). (In Finnish I am 50% responsible for word yhteyskeskus which has becom an commonly used general term for call centers + service desks.)
Oh, I'm again off topic, sorry. The reason must be the 12 yr old Caol Ila I'm sipping, whisky just don't get better but it seems to loosen the fingers.
Aale
an attitudinal thing
Apparently Finland is also the most promiscuous country in the world with New Zealand a close second. I don't think we are promiscuous, we just don't get all tied up in hypocritical moral knots like certain countries I could name. Also off topic.
I too agree that an actionable request interface bears as much resemblance to a catalogue as a CMDB does (but is more useful than a CMDB). However the industry has decided it is included so i treat it as the User Service Catalogue, the user view.
I'm still not sure Mark gets my point. Whether you consider them one catalogue or eight catalogues, there's only one catalogue. that is, they are talking about the SAME services. Don't let the techs burrow into their cosy technology and run their own tech services. keep them engaged with the REAL services delivered to the customer, by treating techs' "services" not as independent services but as component systems. It's an attitudinal thing. Like promiscuity.
What is important is ...
You are right - Aale. It's the damp the kills us here.
Rob, the customer catalog (or view... or whatever we call it) is the most important one. It should be the first one created and any other catalogs , view etc. based off of this to show different "parts" of how the service is delivered (if you will).
You can have one catalog, you can have many catalogs. The important thing is you must have at least one. That is not to say that the ONE catalog is a single entity - you of all people must see this or we are doomed to go down the single database CMDB road with regards to the service catalog.
Where do organisations typically start with creating the service catalog? Well ITIL talks it up so a lot of S.C. initiatives start within IT and end up cataloguing, guess what... IT services. Some more mature IT org's will be mature enough to know that to get value (and align to the business ... etc, etc) they look to translate what they do into something the business understand ala the business view, catalog etc... This is a typical scenario though I am not suggesting that it is the right approach.
Whether you and I agree is not important. What is important is that organisation's derive proper value from their service catalog initiatives or the spend is just not worth it. So if having the extra layers, views, types etc. of service catalogs is required by an organisation then use them. If not, don't. At least have the option.
Focus on the important one
I guess we are approaching an accedemical discussion here. Maybe a short summary:
* We agree that a service catalog should first and foremost conecern itself with business services.
* We agree that a service catalog should be outside-in defined.
* We agree that a service catalogs objective is to get the techies to talk about the business services.
* We agree that their can be multiple business consumers of the catalog. This is similar to different business lines.
* We agree that each business line (in IT) can market their services differently and that they may have different services
* We agree that all in IT and business should be talking about the same set of services
So the difference in how to achieve this "uniqueness" of each service description is not important anymore. Even with a single "catalog table" I can create disseperate understanding if I fill the table with business services for the business (fill out the business fields) and IT services for the teckies (fill out the technical fields for new rows) and show only business info in the business view and show only technical info in the teckie view (filter horizontally and vertically) resulting in:
and show services 1 & 2 in the business viewwith only the business info (the yellow stuff) and 3 & 4 in the technical view with only the technical info (the blue stuff).
So let us all get away from the discussion on "one catalog to rule them all" down to "one single and agreed list of services and one person to oversee them". Catalog Management anyone?
Marc
http://buzina.wordpress.com
Same entity, different views
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
But that model is not helpful
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).
total failure
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
Yes exactly, but who started talking about tables & datamodels?
You said:
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 - ;-)
none taken
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.
pink elephant
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.
Techie info for techies
Configuration Management not Catalogue Management <--
Theology
Actually rather than an academcial(!) discussion it seems more theological to me. Seems to me we have something approaching the Holy Trinity of God the Father, God the Son and God the Holy Spirit .
When Castle ITIL turns into Cult ITIL perhaps we'll have a new triumvirate of God the Service Catalogue, God the Business Catalogue and God the Technical Catalogue. Now that would be a deity for #FakeITIL to follow.
In the name of the OGC, APMG and the itSMF
Amen
The Devil Incarnate?
OGC, APMG and the itSMF is hardly an all knowing, all seeing, all perfect triumvirate! More like the opposite.
Agnostic
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.
Mysterious Ways
Well they certainly move in mysterious ways!
Another incident or problem
The problem with a wide definition is that it does not define much. Another incident with ITIL definitions, or is it a problem?
useful guidance
It may not define much but so long as it defines the key essentials it is useful guidance:
You need one
What constitutes a service is...
The limit on the scope of what services you include is...
Potential uses include...
etc
Wish to contact Ed
Wish to contact Ed VanSchaik. Call me in Dayton@ 937-274-5853
organisational unit.
You misunderstand me. Look at my diagram. read what i wrote. "For any organisational unit...". When you subcontract or outsource you introduce an organisational unit - a supplier. If an organisational unit delivers services they should have a catalogue. That's why I adopted the cumbersome term "organisational unit" so as to be as generic as possible. (I can envisage that a technology team within IT in a sufficiently large company might adopt ITSM and deliver service). I've already agreed with Charles that it is fractal.
hexagon=organisational unit
yes, you are right, one
yes, you are right, one catalog is enough. thanks for the interesting article.
being drubbed
where the hell were all you guys who agree with me when i was being drubbed in the online poll and argument last time? LOL
Whaaaaat?
I can't facepalm AND type at the same time you know. You want the moon on a stick you do.
Still forgetting about the customer view!
I have refrained from commenting on some of your posts here and on linked on for one simple reason. You seem to have your mind made up on what you see as right, so such posts have been less debate and more a lesson (maybe even sourcing opinion for a new book perhaps!!). But that’s ok - you are as entitled to do so as I am.
For me the missing catalog, the one that adds true value to the organisation and the one that aligns to the outside-in thinking is the customer catalog. A catalog that describes the services offered by the organisation to its real customers i.e. the ones that pay real money to the organisation to use the service (none of this internal services and cross charging stuff). That does happen at the business layer and at the business service catalog level.
But where is this customer catalog mentioned, ITIL? MOF? Here? - You can have all the technical and business services you want but unless there are customer services generating money, driving product sales etc. they may all be for nought.
"What I object to is teams who do not enact the service ethos, adopt none of the SM techniques, fail to participate in the departmental processes, but demand that 'their" service be in a catalogue." - Yes this is a barrier which I see over and over again.
In your example using a "network service" I agree it is not a service with a direct output to a customer or business user and therefore is not a contender to be included in either a customer or business service catalog. It is important to understand that it is a Technical System used to provide a technical service. In fact "network service" is a core critical IT system required for basic communications of most organisations. Without it they stand still (or get out the paper and the yellow sticky post-its). In order to charge for the use of a "network service" it should have a relationship to the IT services that are require the “network service” in order to help with working out the cost of the service both to business users and customers.
For me the service catalog has many views (layers) and services a number of purposes. The ITIL view is limited as it omits a customer service catalog and the example provided in the ITIL books only shows an example of a very basic service record leaving the actionable service catalog out in the cold (though it gets a mention in the Request Fulfilment process).
what is a technical service catalogue?
I have been known to change my mind, publicly :)
I'm troubled by your remark "is not a contender to be included in either a customer or business service catalog". Are you implying it IS a contender to be catalogued in a technical service catalogue? So what is a technical service catalogue? "It is a catalogue of the services that..."? what? or put another way: what is a service? What does service management manage? Surely a service is something we apply SLM to, something we plan availability and capacity for, track in a service portfolio, assign service owners to, discuss with the service customers, do request fulfillment for, build Service Design Packages for... etc etc
You do all that for a network "service"? Surely not. It's not a service. You said it yourself, it is a core critical IT system. A "system" is a high-level CI that sits in the CI taxonomy just below "service". A service is made up of systems [...some of which are applications, Charles]. The Network Team don't have customers. Go ask them who their customers are, how they manage their customer relationship, how they fulfill service requests.
Don't be troubled.
Don't be troubled. "Network Services" is an IT System and not a direct service. The link to the CMDB is fine as there is where such information is generally recorded.
I agree that the network team does not have customers but the IT Director (or boss of IT) does in the form of internal users who may use certain services that require, in this example, the network systems in order to work.
How useful the Service Lifecycle is, actually?
This is an interesting discussion. The lifecycle model with a portfolio of future services has always troubled me a bit. It brings in mind our old former eastern neighbor, the Soviet Union with their 5-year planning model. In a way a beautiful idea, everything works according to a grand plan and growth is stable, much better than this up-and-down world. Somehow it just did not work.
The service catalogue is a nice concept but quite often it seems hard to define. Thic technical-business discussion is probably just a symptom of it. It is a bit like trying to fit McDonalds and a Mom in the same model. McDonald has a clear service catalogue and you get exactly what you order, in a specified manner. Mom makes food for the family (not meant to be sexist, I like cooking and do my share of it at home). There is no service catalogue, she does what she wants but you can make wishes. Sometimes she follows recipes but not always. On a bad day she tells you to just heat the left-overs from the fridge. End results may vary but overall they are much healthier than the McDonalds options.
I suppose Charles's fractal model fits better with the Mom-concept than this fixed services -concept. My tentative conclusion is that it may not be possible to describe all the activities provided by the IT unit as services. Either it becomes too vague to be of any use or too complex to manage. Having said that I must add that I know that the Service Lifecycle model can also work and I know that there are succesful companies working like that, I'm just arguing that it doesn't seem to fit all.
Let's call the alternative model a Partnership. In this model the services are not standardized but flexible. The service provider is not just aiming to fulfill the needs of the internal customer, instead both have the same goal to satisfy the external customer. The exact roles vary and boundaries can be adjusted.
I see more examples of working partnerships that of fixed service offerings. The variable nature of the service causes problems and usually the IT partner would like to have more fixed relationship but the Business partner resents this. The "best practice" solution has been: define the services and make SLA's but maybe it is not a best or even good practice as it seems so hard to do?
Aale
PS Thx Rob for the nice comment earlier!
Service or product?
Hi Aale,
some nice observations. One or two points of note:
If you are referring to McDonald’s menu as their service catalog, it is a product catalog. It lists the products you can buy (and eat - I was there last night). It does operate in a service industry, providing you with the ambience of a family fast food restaurant making specific products available to the customer. They don't offer you the service at a price; moreover the cost of their ‘world famous’ service is rolled up into the cost of the products and is invisible to the customer.
"In this model the services are not standardized but flexible." That would be nice but would it work in the commercial world? I guess it could providing you had the appropriate options attached to the service to allow it be flexible.
It's not really a product
Mark
McDonald's items are not really pure products or services. They cannot store the ready made products, like fries which are made on demand. The service part comes from providing you with a hot and cold meal when you want it. Most service has some physical elements and most product sales has some service included.
Flexible service works best in the internal IT structure but I know a case where an sales manager was fired and he destroyed the key customer contracts. Business went on but the service provider people did not know what was in the contract and did not want to reveal the situation to the customer. So they needed to be flexible.
Aale
I know...
Hi Aael,
I know, there is a fine line.
And you wonder the business gets fed up with us
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!