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.
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.
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.
[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.
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.
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.
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