ITIL services are customer-facing, whatever catalogue they appear in
Oh dear it's an outbreak. I'm once again debating on a forum whether the services in the Technical Service Catalogue are different services from those in the Business Service Catalogue. And it shows up recently on a major website. I consider this concept of internal IT services as nothing short of tragic. Anyone who thinks the two catalogues could list different services clearly fails to grasp the whole fundamental point of service management, which is to get everyone to think in terms of the service delivered to the customer. And there are plenty of folk think that way, judging by early results in our latest poll.
[Note: this post is refering to the ITIL V3 books, not ITIL V3.1 2011]
Never mind which forums - it is a recurring battle - but here is an instance of the same misconception from ITSMWatch, a site that should know better:
A service catalog is a database or structured document with information about all live services or services planned for delivery. It is used to support the marketing and delivery of IT services. The service catalog includes information about deliverables of IT services, contact points, prices, ordering and request processes.
So far so good.
The portion of the service catalog that is visible to business customers are only the business services. Both business and infrastructure services are visible to the IT organization.
Wrong, or at least misleading. "Infrastructure services" (actually SD talks about "supporting services", of which infrastructure services are but one instance, see p 62) appear in the TSC only as documentation of the true customer-facing things that we call services. This is the misconceptiuon I'm trying to stamp out. Non-customer "services" should not be on the list of services catalogued, even in the TSC. They appear only in the description of the services, as components.
According to ITIL V3's Service Design 4.1.4
The Technical Service Catalogue contain[s] details of all the IT services delivered to the customer
Those are therefore the SAME services as listed in the BSC
Service Design goes on to say
...together with relationships to the supporting services, shared services, components and CIs necessary to support the provision of the service to the business.
"relationships to" not "details of". Supporting services and shared services appear in the TSC only as components of the services being documented, which are the services provided to the customer, same as the BSC. Supporting services and shared services are not themselves documented in detail in the TSC. (They would be documented in detail in the service catalogue(s) of the service providers providing those services to us).
Figure 4.3 in Service Design shows services A thru E as being in both catalogues. "Supporting services" are listed in the same line as "hardware" etc - they are just components. We no more detail the supporting services in a TSC than we detail the hardware - we just show the relationship. Every time we call something a "service" when it is an Underpinning Contract, a process, an activity, an organisational unit or a function, we take our collective eye off the one service that matters - the one delivered to the customer.
Interestingly, Service Design and Service Strategy totally contradict each other as to what is a Supporting Service. If you read Service Strategy 5.5.4.1, especially the examples, then supporting services are clearly also services delivered to the customer, which are ancillary to the core services of the business. Note especially "Credit-processing...is not a supporting service to borrowers because they are not its users". Whereas Service Design is clearly referring to the geeky idea of inward-facing IT services invisible to the customer. The glossary attributes the term to Service Strategy and uses its definition "A Service that enables or enhances a Core Service" but then goes on to offer an example that obviously demonstrates the same misconception "For example a Directory Service or a Backup Service.". Did these people ever talk?
Finally, ITIL defines a service in many places as:
"A means of delivering value to Customers by facilitating Outcomes [which] Customers want to achieve without the ownership of specific Costs and Risks."
Nothing there about "or a service we receive from our own suppliers, or a chunk of infrastructure the geeks want to label as an internal service so they don't have to think about customers any more"
Once and for all can we please all put to death this concept of catalogued services not seen by the customer.
[updated: moving some material up from comments. please do read the comments on this thread, there is lots of useful discussion]
- A catalogue defines the services that are external to the business unit that owns the catalogue.
- the catalogue defines the services that flow out of the black box which is that business unit.
- the only services that should be listed(catalogued) in the catalogue are those that flow out of the unit owning the catalogue.
- In ITIL terms, there are two views of that catalogue: Technical and Business (actually i count at least five views of a catalogue. ITIL is still behind the game in service catalogue, but that's another discussion)
- services that appear at other levels, provided by internal sub-units of the one owning this catalogue or provided by third parties, should NOT be catalogued in THIS catalogue. they might be mentioned in a description or a breakdown of a service they are part of, but that is NOT the same thing as being catalogued.
- If a parent or child of this business unit, or any other party, is providing their own services they have their own catalogue at that level defining THEIR outputs. ("Aw, innat cute? The server group have their own little catalogue now. That'll make it easier to outsource them") (I'm not in favour of this in general because it allows teams to live in their own little world delivering their own little services. I think it's not, in general, a service unless the unit is truly independent. What is being called a service is more often is one component of the service at the higher level delivered to the "real' customer).
- to reiterate: a catalogue is a boundary document. It defines the outputs of a unit. it does NOT define the internals. The confusion arises because the Technical view of the catalogue documents the internals and as a consequence mentions other services from other business units.
To me there is only one catalogue at any boundary of a business unit. That unit only delivers one set of services to one or many customers. That is simple.
There are many layers of business units in a supply chain/network, each with their own one single catalogue. The complexity comes in the many catalogues. However a customer of a business unit only sees that one catalogue.
Each of those catalogues has many views depending on the audience. yes TSC/BSC is too simplistic. As I said, I can think of five views. Mark says eight. But they are all views of the one same catalogue per organisational unit with only one same set of services defined.
in the course of documenting a service, a technical view for internal use within the business unit will mention other services in the descriptions of the services it catalogues. That is not the same thing as cataloguing those other services, they don't get added to the list of services in the catalogue. All views of a catalogue are cataloguing the same set of services.
.
If you found this post useful, and you are a Facebook user, please Like this blog :
See also:
ITIL 2011 persists with the dangerous concept of supporting services
There is only one service catalogue
A menu is not a service catalogue
and other posts on the topic of catalogues
Made in New Zealand 
Comments
a semantic approach
...or for a semantic approach:
The Technical Service Catalogue does not mean a catalogue of the services that technical staff within the organisation can order,
nor does it mean a catalogue of all the services that go to make up the services we provide to the customer,
it simply means a technical view of the same catalogue the customer sees, providing all the technical data that does not form part of a customer view (included in that data will be some mentions of underlying services from other organisational entities).
Listening or Teaching?
Hi,
I can recommned a good book that will help clarify things but I am not sure if you are looking for clarification or are providing advice! Anyway if this is how you see things - this is how you see things.
always open to learn
I think I'm open minded. It is just that in this case nobody has provided me with a compelling argument to change it. "No you're wrong. I'm more expert and it is this way" is not an argument. I'm always open to learn, and to change my mind. What is the the recommended book please? If it is Steinberg's Servicing ITIL I have it on order
It depends...
Does there have to be one-and-only-one format for services structure? Just about everything in ITIL leaves enough wiggle room to adapt to and overcome organizational idiosyncrasies, why not a service catalog?
Maybe I oversimplify, but I see business services provided to business consumers via the service catalog agreed upon through SLAs. Technical services and capabilities support those services and are governed by OLAs. The business consumers don't see the technical services, but so what if they did? Just deny them the ability to order them. What does it hurt for them so see the effort and composition underneath the business services?
Regards,
David
a single entity in Visio
First, many "technical services" are not services. They are just systems. They have no business model, nor means of engaging with them outside of the business unit. Often they are only treated as a single entity in Visio: they are not measured as a service, not OLAed service by service, there is not one accountable owner, no charging model, no warranty and so on...
Second, the whole point of ITSM is to engage the customer in their terms: to stop blinding them with science and baffling them with bullshit. The customer wants to see what comes out of the pipe, not what is inside the factory. if they do want a tour, then yes by all means show them the TSC parts-explosion of each service.
Third what customer enjoys being presented with menu options they can't have?
I think there is a simpler explanation...
I think there is a simpler explanation...
Geeks insist in including "Technical Services" into the catalogue, because they feel very comfortable defining them. It's very easy for them to describe TS in a Service Catalog format because they can pose as customers for them.
But it's much more challenging for a geek to pose as a real customer and try to describe a business service from a customer perspective. And this is the real challenge.
So, challenged as they are, if you leave these "Technical Services" out of the catalog, the SC would be pretty empty. Of course, the "Email" service and the "File & Print" service would also proudly be part of the service catalog. Very original.
And it's much more difficult when these service catalogs are produced without any kind of input from the business. In this case, the most likely output is to have an unhappily amused customer that will only corroborate how little IT understands business.
Of course I'm taking the case a little to the extreme, but I honestly think that these Technical Services in the Service Catalog are like a security blanket for IT people unable to understand business.
which customers and services
I agree with Horacio - we need input from the business regarding services they feel we provide or should provide to shape our service catalog in support of their needs. And thank you Skeptic for making it clear that UCs or OLAs should not be considered services in my service catalog. Going back to Mark O's comment/question... in IT, we have our business customers and they in turn have their customers i.e. end consumers. The services in our catalog are relevant our business customers (NOT to end consumers), correct? This goes back to the definition of service, business service, IT service... the service catalog should contain IT services which we provide in support of business services they provide, but NOT contain the business services which the business provides to their customer. Right? That would be in their catalog? Can you provide a couple of examples of IT services which support business services which would be in the service catalog? Thanks!
example services
IT provides the service of stewarding information and providing transaction infrastructure for any of the business's own services to its external end customers.
IT also provides professional consulting services for business analysis, project management, change management and deployment every time the business wants to change its services.
In addition IT provides technology services to the business which link indirectly to the business's services e.g. provision of desktops and phones.
In order to avoid confusion with the services IT provide to the business, which are described in IT's BSC and TSC, I'm tempted to call th business's services to external customers, which don't get catalogued in any IT service catalogue, "revenue services" (but public sector and notforprofits won't like that name)
Orphans
On a couple of occasions situations have arisen where it has occurred to me that there might be some services that do not have a traditional customer as such, but rather a mixture of users and stakeholders. I suppose I'm thinking in terms of commodity/utility services. There might also be some services that IT provide direct to their customer's customers rather than via their customer.
James Finister
www.tcs.com
http://coreitsm.blogspot.com/
payin'
You know me James I'm a bear of very little brain. I like to keep things simple. In my lexicon the customer is the one paying. Therefore there is always a customer somewhere. And there is usually only one customer per service transaction.
So yes we do provide transactions to users of our customer's services but only one of them is payin' so only one is the customer at the time.
Rule of Thumb
Rob,
That's my normal rule of thumb as well, but it depends on all parties recognising who that customer is. Take email for instance, trying to find a customer for it to sign an SLA can be quite a challenge - which isn't to say it shouldn't have a customer, but that sometimes the customer might be a proxy, for instance the CFO owning it on behalf of others. Obviously any IT service treated as an overhead can provide a challenge in this area. Then if the rules over use of email (mailbox size, filtering rules) are set by the business, as they often are, doesn't that make email an internal business/facilities service that is provisioned by IT, rather than an IT service?
James Finister
www.tcs.com
http://coreitsm.blogspot.com/
Not following you
I don't understand the example. Someone is paying IT to run email. Now either it comes out of a fixed operating budget, in which case the CFO or CEO are the customer (however the org wants to treat it - whoever is signing off the budget), or each department pays allocated costs in which case they are the customers.
there is no rule says the customer has to be closely connected to the users. In internal IT they often aren't. It's a problem but it's a fact. Chargeback tries to change that.
The fact that the organisation sets policy for something doesn't mean it is the customer, any more than government legislation makes the government the customer. these are environmental factors.
I don't understand what "internal business/facilities service" means. Internal to what? All our services are business services that are provisioned by IT, surely?
Reality v the possible
Rob,
Remember we are talking about a real life scenario I've seen repeated several times. not the approach we would get the business - and it is a business decision - to adopt if there a chance of them listening to anything a humble ITSM consultant might say.
In theory, if not in practice, there is no problem if a CxO level manager is genuinely acting as a customer. I'll come back to that thought. In the case where costs are allocated to budget holders then the budget holders are probablycustomers in name only. They have no control over either the cost or quality of the service they recieve
I'm not sure of the relevance of your point about the distance between the user and the customer, it doesn't form any part of my thinking.
"The fact that the organisation sets policy for something doesn't mean it is the customer, any more than government legislation makes the government the customer. these are environmental factors." is an interesting point and obviously reflects a lot of thinking about public sector reform over the last 25 years - but does it stack up in this case? After all that nebulous entity "the business" is both setting the policy and paying for it. Budgets after all, are an artificial construct.
As to my last point I simply mean that it is a service delivered purely to our internal users, not to the business' customers. Email is actually a very bad example of that on reflection, because although we often think of email as an internal service it is usually business critical because of the impact it has on inward and outward communication with the outside world.
James Finister
www.tcs.com
http://coreitsm.blogspot.com/
External to the owner of the catalogue
Maybe this will help clarify my position on this:
This is complicated enough
Rob
Why is #4 another discussion? I think that people have been trying to tell you that BSC/TSC model is too simple and here you agree. I mean this is what I have been trying to discuss.
I suppose the heart of the problem is in #6 and true independence. Of course the server group should be outsourced unless they can prove that they can compete, which is difficult for small groups. The best strategy for them might be to integrate their services in the common catalogue and hopefully hide their excess costs in there but is that ok for the whole company?
Aale
Last attempt to crystalise
To me there is only one catalogue at any boundary of a business unit. That unit only delivers one set of services to one or many customers. That is simple.
There are many layers of business units in a supply chain/network, each with their own one single catalogue. The complexity comes in the many catalogues. However a customer of a business unit only sees that one catalogue.
Each of those catalogues has many views depending on the audience. yes TSC/BSC is too simplistic. As I said, I can think of five views. Mark says eight. But they are all views of the one same catalogue per organisational unit with only one same set of services defined.
in the course of documenting a service, a technical view for internal use within the business unit will mention other services in the descriptions of the services it catalogues. That is not the same thing as cataloguing those other services, they don't get added to the list of services in the catalogue. All views of a catalogue are cataloguing the same set of services.
.
Real World Catalogues examples I have used...
When working in the SLM arena I have used both of the following to kick start the thinking process.
Take a look at the front 20-30 pages of a phone book. It is a great example of a service oriented catalogue.
Key numbers to call, cost of long distance, different services you can order / use.
Note, no where does it state how your phone works or the logistics necessary to make the lines work. link up etc. The customer assumes they will get a dial tone and be able to communicate.
Now the second example is more in line with this discussion. I especially use it when discussing V3 catalogues.
Think Restaurant Menu and Kitchen Cookbook. You cannot offer a meal without the underpinning ability to prepare it.
The menu summarises what is available to the end customer, the cook book and kitchen processes tell the operational teams how to prepare the meal. As a customer, you order from the menu, as a provider you use the cook book to make sure that the order is delivered on time, on budget and as described.
ITIL BSC = Menu.... ITIL TSC = Cookbook. (and kitchen instructions i.e timing, roles, workflow, dependencies)
a fine example
the kitchen cookbook is a fine, and common, example.
And the cookbook, the TSC, does NOT say:
Menu:
Soup
Steak and chips
Gumbo
Cheesecake
Oil delivery
Waste removal
Food wholesaler
Vegetable market
Potato chopping
Dishwasher
Cashier
Maitre d'hote
The only services catalogued in the TSC are the services delivered to the customer. Underpinning services (I prefer that term instead of supporting services because ITIL uses that term in two totally different ways) do NOT get catalogued, though they will get mentioned as part of the recipes and instructions.
Depends on what the customer wants from the restaurant
Maitre d' : "And how was your meal today, Mrs. Uppercrust?"
Customer: "Quite passable. I love the decor in this dining room. I'm wondering, do you host special events? It's my Fluffy's tenth birthday."
Maitre d' : " We have a banquet room upstairs that is decorated in the same style. We can certainly accommodate you there."
Customer: "Well, the one thing is that we have a family chef and we'd actually like to have him provide the menu."
Maitre d' : "Of course. Fortunately, the banquet room has a catering kitchen. We accommodate these types of events all the time. Here is our standard offering & price list for special events:
1. Hourly fee for kitchen facilities
2. 2% markup for case quantities bought through our wholesaler (or you can bring in your own food).
3. Hourly kitchen prep staff (e.g for potato chopping), or your caterer can supply
4. Dishwashing staff (or your caterer can supply)
5. Excess waste removal
6. Cash bar services (bartender/cashier)
And so on...
The catalog is defined by the customer and what they need in the moment, and the truly agile service provider should also be alert to the need to unbundle and re-bundle...
Charles T. Betz
http://www.erp4it.com
business view
Don't have a problem with any of that. Any service provided external to the unit in question should be in the catalogue. My issue is with the geeks who want to have infrastructure "services" in the catalogue because they currently have such a system internally. But if the business view of that service AT THE LEVEL OF THE EXTERNAL CUSTOMER does not currently exist then it should not be in the catalogue, TSC or BSC.
Customer: "Well, the one thing is that we have a family chef and we'd actually like to have him provide the menu."
Maitre d' : "Of course. Fortunately, we have a chef. Your guy can swap with him and he'll show your guy around the kitchen"
Customer: "What do you charge for renting your kitchen?"
Maitre d' : "ummm..."
Customer: "Do you have a license to provide rental food preparation facilities?"
Maitre d' : "ummm..."
Customer: "Would we be covered by your insurance if our chef accidentally set fire to the place?"
Maitre d' : "ummm..."
Customer: "You've never thought this through before have you?"
Maitre d' : "well..."
Defined flexibility
I agree with Rob here.
It might not be practical (at least not in most type of service providers) to be completely flexible in your catalogue and keep it entirely (or predominantly) external focused. You HAVE to take your current capabilities and constraints when you prepare your Service Catalog.
My view is, what ever flexibility/customization you can give in your service catalog has to be 'defined flexibility' (which is defined taking into consideration, your strategy, capabilties, constraints, current design etc).
In the example of the restaurant - whether to allow customers to use your kitchen with external chef/cook has to be a strategic decision most of the time - isn't it? (unless you want to satisfy a key customer of yours by providing an exception approval for him).
Having said that, your approach is entirely true for Service pipeline! - That need to be and can be completely external focused, flexible and agile.
If the strategic management feels it is a good idea to provide those services - like allowing the kitchen to be used by external customers and chefs- then that should come to Service catalog through pipeline, through proper analysis and decisions.
Vinod
www.itserviceview.com
www.wings2i.com
Customer?
Hi,
"The only services catalogued in the TSC are the services delivered to the customer. "
A common problem people have is defining "the customer". Who is the the customer in this case? An internal customer or external customer? If internal customer where are you cataolging the services provided to external services. This comment is too IT focused - no?
no such thing
There is no such thing as an internal customer. The organisational unit defining its services and hence its catalogue only has customers external to itself, by definition of what a customer is.
You can define services internal to IT if you want to, but the subset of IT providing the service has its own catalogue, and the customers are external to it.
It is true that staff of IT can be both providers and customers, that IT is its own customer, but that is no different to the guy who works for a power company and uses electricity: different roles. They still aren't "internal" services
CUstomer is King
Skeptic,
Just picking up on one quote for no reason in particular:
"Anyone who thinks the two catalogues could list different services clearly fails to grasp the whole fundamental point of service management, which is to get everyone to think in terms of the service delivered to the customer."
They can list different views of the same service. One a technical view with technical details and information, one with a business view for a non-technical audience. The missing thing here which is important is the customer service. I think that is what you are kind of referring to – no?
A customer service is built from a combination of business services and technical services. Customer services are where the organization makes real money. This is the one that counts though missed in ITIL. Remember, there is more to services that what ITIL details. I reference 8 service catalogs when I speak about the subject. Each can be placed within a pyramid - customer services at the top - Actionable service catalogs to the side.
Just thought of this and thought it apt for the conversation:
Technology - Enables (Technology Services)
Business - Delivers (Business Services)
Customers - Buy (Customer Services)
Missing the point... customer focused
Hello friends,
very intersting discussion, you know I'm really interested on getting a good definition.
But this time I think we are missing the point: the interesting fact is that we don't have "the customer" to serve (to provide services)... we, in fact, have an unlimited number of customers, each of us are customers of each other, and suddenly we find that "oh! there are what we (IT) call -the customer- and us", so for the "us" type of customer we have the TSC and for the "them" type of customers we have the SC
May be it's a little confusing? :-)
Antonio Valle
G2, Gobierno y Gestión de TI
http://www.gedos.es
Sheep and wolves
Antonio is spot on. This BSC/TCS discussion misses the point. It is like an sheep eat wolves ecosystem. Compare this to a marine ecosystem where everybody eat everybody, depenging of relative size. The plankton eating insect might not be aware that its endcustomer is a pelican via the stomaches of five fish where fish #1 can be the same species as fish #5.
Real life services are more complex and ITIL does not have a best or good practice to offer. The model is simple but it just does not fit. As I wrote earlier, this seems to be the major challenge for IT service professionals at least here in Finland.
Aale
this discussion reminds me
this discussion reminds me of a post on Fear & Loathing in Oct of '07 ... which catalog(s) you put services into is not the biggest issue to me; service definition is.
Proper design of a service catalog (or any catalog as Ian states) starts with the customer. ITIL V3 does address this, although in a rather casual way: An outcome-based definition of service moves IT organizations beyond business-IT alignment towards business-IT integration...Requirements are generated for internal control only after customer outcomes are well understood.
Even with Outside-In thinking we may decide to establish a Technical Catalog of Services, and if we do then the customers are likely to be IT staff who need to use these services as 'building blocks' to establish other services (presumably based on external customers).
Unfortunately the Business often defines services from a business-silo perspective, which doesn't align them with their customers; making IT/Business alignment kind of mute.
Achieving a Top Down (Outside-In) definition of services is a more important discussion than which catalog you want to put them in. If you perform Outside-In (Top Down) service definition then catalog design will take care of itself.
John M. Worthington
MyServiceMonitor, LLC
Black, white, grey
Page 62 in the Service Design book states:
The Service Catalogue has two aspects:
- The Business Service Catalogue: containing dtailsof all the IT services delivered to the customer, together with relationships to the business units and the business process that rely on IT services. THIS IS THE CUSTOMER VIEW OF THE SERVICE CATALOGUE.
- The Technical Service Catalogue: containing details of all the IT services delieved to the cusomer, together with the relationships to the supporting services, shared services, components and CIs necessary to support the provision of the service to the business. THIS SHOULD UNDERPIN THE BUSINESS SERVICE CATALOGUE AND ****NOT**** FORM PART OF THE CUSTOMER VIEW.
The Technical Services are part of the value chain of the Business Service to the customer. No one taking their eye of the ball. Just understanding that the ball requires rubber that is unpuntured and that it must be inflated to the right level with air in order to optimize its perfomance to the player of the game.
Having said that, I think the books, which are in the process of being corrected, are a bit inconsistent in their treatment of service. But I am "all-in" with the fact that a customer or end-user does not give a hoot about a directory service that needs to be up and running and supported at a certain level to allow that Payroll service to cut a check, and therefore, it satisfies no real need, for those non-inquiring minds to publish this to the customer community - unless of course, IT is publishing a CV rather than a catalog of subscribable services.
I don't see your point
I don't see your point in highlighting those bits of the extract. The TSC is indeed the view that the customer doesn't see. Agreed. So?
The salient point of that bit you quoted is as I have already discussed above. "...details of all the IT services delivered to the customer, together with the relationships to..." The only services in the TSC are the same as those in the BSC, the services delivered to the customer. Other "services" (if we must insist on calling internal or third party stuff that) get a mention in the TSC only because we document their relationship to the catalogued services. It's crystal clear... at least to me.
Lines of service
I suggest just looking at the bits in capitals. Makes perfect sense to me.
collecting my scattered thoughts
I feel I'm going to write something about this, so collecting my scattered thoughts into this thread.
From a discussion I kicked off on the itSMFI forum seeking guidance on this:
"From the bottom up, each technology support team or external service provider is providing a service upon which the higher levels may build their solutions." No they DON'T. It is this mindset that ITSM is trying to eliminate. they each provide their bit in order to deliver a service to the customer. There is only one level of service and we all pull as a team to deliver it. This "I just stoke the boiler, don't ask me where we're sailing to" attitude is what got us into this mess. Everyone should have line-of-sight to the user.
I still remember vividly talking to an HP Unix administrator in a bank who had no idea that the machines he tended ran the foreign exchange system.
And from the poll related to this thread:
[A holiday on planes and in hotels involves] many services. Some are core services and supporting services precisely as described in Service Strategy 5.5.4.1. They are all customer-facing services - ones that you see, choose and consume. Others are infrastructure services, internal services that a third party provided to the service provider not to you, such as room cleaning or food supply to airplanes. These are called supporting services by Service Design which contradicts SS usage of "supporting", so I avoid that term as ambiguous.
So the question is about distinguishing between the services provided to the customer and the services provided to the provider. In my view, the TSC and BSC both catalogue the services provided to the customer, and that's all. the TSC will mention the third-party services as components of a catalogued service (this is what SD Figure 4.3 shows) but not as catalogued services in themselves.
If we look at the basics of what a catalogue is for, then this is clear to me. it mystifies me that it isn't clear to others. there is a disconnect here somewhere and I can't find it.
How would this be defined?
Please tolerate the ignorance of a newbie thrown into the deep end of an ITIL project with no formal ITIL training, and basically trying to pick up what I can as I go along (there are others on this project with some level of ITIL training, so it's not a complete cluster-mess, but it still is somewhat overwhelming to me). I'm currently working on both components of the service catalog, the BSC and the TSC. Based on the current work flows at our company, there are many requests that end up being handled something like this:
-- Request comes in from the sales team or the client service team to IT team X for a standard service.
-- Request generates work tickets 1, 2, 3, 4, and 5. Ticket 1 must be completed by IT team A, Tickets 2 and 3 must be completed by IT team B, Ticket 4 must be completed by IT team C, and Ticket 5 must be completed by IT Team D.
-- Team A must complete Ticket 1 before Team C can do their work. There is a defined agreement between the teams as to when this needs to be completed by. My superiors call it an OLA (operational level agreement).
-- Team B must complete Ticket 2 before Team C or Team D can do their work. Again, a defined agreement exists between the teams as to when this needs to be completed by.
-- All 5 tickets must be completed for the service to be tested.
-- Team X performs all QA work, gives the go-ahead for it to be installed into production, and owns the process once it is in production.
From what I've read, none of the work tickets would be defined as services in ITIL -- our sales and client service teams certainly would not know to order any of them as part of the service they request. However, if those tickets are not services, and if nothing that is not in the BSC is in the TSC, then where should those OLAs between the IT components -- which do inform on the overall SLA for the service being rolled into production -- be housed? Is there another catalog for that? Or is this just one of those situations where you take as much ITIL as you need, then figure out whatever else you need on your own?
Thanks for your patience...
The service is the one requested by the user
The service is the one requested by the user. period.
In order to fulfill a service request, there is a process to be followed. that process involves a number of sub-processes, activities and functions (groups of people). As far as the customer is concerned it doesn't involve any additional services. We have to retain an outside-in perspective and see that therefore they do not appear in the catalogue, any catalogue. A catalogue lists what we provide to a customer.
In the BSC we say what. in the TSC we break it down into how, we add technical detail. Part of that detail is to describe the underpinning contracts, systems, processes, activities, functions, technologies that make up the service provided to the customer. (We're wandering into CMDB territory now *shudder*). Now certain groups within IT or third party providers will consider they provide us with a service, and therefore we have an OLA or UC with them. This is part of the documentation of the service in the TSC but it doesn't constitute a new service in the catalogue
The service is the one requested by the user
"The service is the one requested by the user. period." Can we perhaps soften the period to become a comma: ", which a an authorized provider has agreed to fulfill. period."?
It will be a fruitless request if it cannot be fulfilled.
Say the user requests "A virtual Linux server instance with temporary admin rights so the user can load their own app on it. This is a TSC entry in many shops. It is available only to App Management teams. Is it not a BSC entry because it CANNOT be provided to the user because of regulatory restrictions, lets say.
Where does that idea come from?
I didn't quite mean it that way. of course all services have predefined authorisations as to who can request them. i didn't mean any user can request any service. i meant that if no user can see it then it isn't a service.
Now the example you cite of VM provisioning is an interesting one. I'm impressed by the sophistication of an organisation that treats IT staff as service users. I've advocated it always and seen it never. For me, getting a Service Desk tool treated as a production platform is challenge enough.
But yes indeed IT provides services to IT. IT is its own customer. But that's not what TSC means. There is nothing i have ever seen anywhere in ITIL that suggests the TSC documents the services we provide to ourselves and the BSC documents the services we provide to the business. And yet it is the third option in my poll and proving popular. Where does that idea come from?
VM provisioning is a service. We provide it to a customer called IT. it appears in the BSC and the TSC.
if you have a problem with that, consider the service of provisioning a new admin user to the payroll system. how many customers can request that? And how many users within that customer? VM provisioning is no different. it is a service available to only a subset of the business. In this case that subset happens to be IT.
You are all inside out and need to get a marketing mindset on!
Hi everyone - well someone alarmed me to a fire over here in the form of a discussion on service catalogs. What an inside-out lot you are. The more you refer to ITIL V3 the more likely you will fail in your service catalog strategy. Catalogs are examples of marketing collateral. They both offer products and services and enable a request or order. One of the best examples, for many reasons is the Victoria Secret catalog. Behind the scenes smart marketing determines what to send to which customer audience, when, and generally based upon buying or customer interaction patterns detected at the website portal.
Whether its a business or technical catalog is irrelevant and confusing. You can have one central 'catalog' and present differing views based upon how you wish to position (look that up in Kotlers Marketing Mgt books) and 'sell' the service to each customer community. Or, you can have multiple catalogs, again each designed to fit the language and needs of a target market.
To get that anywhere right you need to walk in the customer's shoes a while. I spoke to one method of doing this at my blog in the Undercover Boss article. The descriptions within a catalog should read like things a customer can do when subscribing to the service.
A service catalog lives on a portal and is co-designed with customer involvement so it looks and feels like your local online banking website, or pizza order site, or Dell, Amazon, or auto repair site. The best route to take in understanding what ergonomic look and feel you will need to a service catalog should go through a service request catalog (please Google service request 311 to see how simple this can be as a start).
So, start thinking OUTSIDE-IN, customer first. You need to become the customer and view matters from their perspective - please. This is your path to success. Please stop trying to make ITIL's inside-out view fit. Designing service catalogs, or 'brochures', is a product marketing special skill - go find a marketer, or get yourself a good marketing book and for once appreciate that IT does not have to keep re-inventing the wheel here.
Oh and while you are at it Google customer experience management....thats where the non-IT service management universe is at today... we need to get aligned! Inside-out fails the customer. Outside-in rocks!
Oh and as for how the service is to be or is being provided... the technical view or 'TSC' thats in the service (product) development plan, or in ITIL terms perhaps the service design package... electronic version of course, or the CMDB, or the TSC... see how ITIL confuses us all by not explaining if these artifacts are just different lenses of the same information.... and how they connect to OLAs, UCS and the like...
Perhaps ITIL should walk a while in the provider's shoes and take a moment to explain how it thinks it all flows...
We have to organise
Not putting underpinning services into a TSC increases the risk of putting them into the BSC. At which point we start talking to the customer about stuff they aren't interested in. You also risk losing any connection between the techie stuff and the services being provided to the customer. In any case the TSC information might just be groupings of CIs from the CMS anyway plus OLA type information.
So which do you want? Business Service A supported by Cisco router A, B & C plus Cat 5 cabling plus port management plus monitoring using product X plus Datacentre A plus ETC ETC ETC for about 10 minutes. Or Business Service A supported by Network Management Service? Which do you want to see as customer?
I hope you've got a great definition of customer. How outside are you getting? Because my truly end customers won't want an Amazon style front end to their bus, tube train or even street outside their house.
PS Why is no one mentioning 'lines of service' yet?
I can't imagine any service
I can't imagine any service catalogue where every service would be offered to every customer. there is ALWAYS segmentation.
See my latest comment re how a catalogue is a boundary document defining the outputs of a unit. if the IT department truly provides application levels services to some customers and infrastructure level services to others then it is correct to have them all in the business catalogue. of course.
In your example the BSC would say Business Service A. period. the TSC would say Business Service A supported by Cisco router A, B & C plus Cat 5 cabling plus port management plus monitoring using product X plus Datacentre A plus ETC ETC ETC
I think you need to clarify "putting in". the catalogue defines a list of services which are the outputs of the business unit writing the catalogue. In your example Network Management Service is not in and of itself an output service provided to customers. it is just terminology for a bundling of components of the business services. so Network Management Service does NOT appear in that list of services, e.g. the table of contents of the catalogue.
The TSC provides a technical explosion/breakdown of the services, or references to the CMS in the unlikely event that you have one :) Somewhere in that description of the catalogued services, all that network stuff would get a mention. preferably don't call it a service unless it genuinely is, eg. from a third party, but in any case it certainly does not appear on the list of OUR services being provided to OUR customer in OUR catalogue.
I think figure 4.3 in Service Design is perfectly correct.
Exactly the conversation that should be had at conferences!
Well! This thread is another prime example of what I called for (I was not alone) years ago when helping create the itSMF USA Annual Conference. Given today's economic woes IMHO if there is an ITIL session it should answer a question like this thread tries to pose and encourage responses to. If authors are to present - they should either form a panel or present to the question.
After all, ITIL is lauded as a source of 'best practice'. Unfortunately in my view its welcome common sense in the easier areas - nearer operational activities, and nothing but a trouble maker in other more strategic and life-critical areas, such as service portfolio, customer outcome sniffing, relationship management, change, continual improvement, problem management, and the service portal, access point, request management and catalog areas... phew..
You only need to look at the example catalog the Design book offers...hhmm.. A catalog is a brochure. It is a primary marketing tool. Marketers should design and maintain. Its a critical element. If developed inside-out (as ITIL is generally positioned) the IT organization will find itself being on the Cloud before they ever get it right. The smaller the IT organization the quicker that may happen.
Do not argue about what ITIL says - that will end up like a 'handbags at ten paces' event in the pub car park. ITIL is unclear on this topic as I said and offers incomplete guidance. Get the authors to sit on a panel at an ITIL conference - there's a WHOLE TRACK at the itSMF USA one - and explain themselves - or find a better source. Please do not waste time trying to make whats documented fit.
Service design is different
Ian is right here. ITIL Service Design book is useless.
Service design is a new disicpline that many universities teach today. See Wikipedia for start: http://en.wikipedia.org/wiki/Service_design. It is obvious that the authors of ITIL SD book did not study Service Design but neither do Service Designers read ITIL, there are no cross references.
This slideshow explains some interesting concepts of service design. http://www.slideshare.net/sylvain/ux-design-service-design-design-thinking. I think one could use these concepts also in IT service design. Slides 35 to 42 are the core if you do not want to go through the full presentation.
Aale
Service Design
From time to time I find myself defending the ITIL books - this is one of them. I don't think they are talking about the same Service Design.
The slideset you refer to is discussing the design of delivery of a service transaction to a user, what ITIL would call a service reguest fulfillment transaction. It is discussing the design of the touchpoints.
ITIL is discussing the design of the IT processes and infrastructure to support and deliver a service. not at all the same thing.
While the honeycomb model is an interesting consideration for ITIL service design, I don't see the rest of it as terribly relevant. it is relevant to the application designers designing the user interface to services. It is also relevant to those designing the request fulfillment interface. but that isn't what ITIL calls Service Design.
I'm all in favour of outside-in thinking, but not if the inside falls out. ITIL SD designs the inside.
Internal services?
Yes, that set was about user experience but I think the concepts could be applied to IT service design too. Do you really think that you can design the inside separately. I agree that ITIL SD tries to do it but I do not think it works. Actually that sounds just like the internal services you oppose.
In my opinion the slide set is relevant to this BSC/TSC discussion in the sense that it does not use that split. It shows service as a layer model and points out that a service is a journey and different customers take different paths.
Aale
PS Quite fittingly I'm sitting in a Pendolino train that should be doing 220 km/h but keeps stopping due to some system error. I wonder which version of Windows they use.
I did not say Service Design was useless
Aale
Tut tut ... I did not say it was useless and you know me for someone who has been a harsh critic of ITIL. My mantra (which often goes unrepeated or referenced - rather conveniently by some) has always been to "protect a planned or existing investment in ITIL". My loyalty is with my clients, not ITIL. But I did not say, nor do I think teh ITIL Service Design, or any other core book, is useless.
What I will say is that ITIL Service Design failed to respect a whole profession, industry and body of knowledge - enterprise architecture. It failed to also recognize that some countries have regulations around the topic of managing and investing in infrastructure with a major law here in the US that dates back to 1996. It has horrible examples for a service catalog and diagrams that have more arrows in them than shot at Custer's last stand - but its not useless. Why - because its purpose is different from what many suppose it to be, and use it for.
My comment was pointed at those that claim too much or read too much into ITIL. My comment was also aimed at those who present time and time again on ITIL V3 without moving any of us forward past what we knew at the time of its launch, or since through reading the books.
ITIL is a contribution not a religion to be evangelized, as so many did during its launch - strange how those folks now evangelize (IT)SM - yet they now drop the IT - why? ITSm is IT + SM - the proven principles of service management (with origins in the business realm of product management) applied to the challenges of It - a perfect name.
As for those who keep renaming ITSM to BSM or something else - it would be polite if they actually finished something first - ITSM. And that alone should be a clue to buyers of their 'expertise'. When you next consider employing or contracting someone to help you with an (IT)SM initiative ask them ho wmany of the 25 items they can help you with I listed in my blog article "My Service Management Professional ‘Bucket List'"!
ITIL and the Service Design book is valuable, as a starting point for understanding what IT Service Management is, and for discussion. It is NOT designed IMHO to solve things. Therefore it is not useless, just misrepresented or misunderstood by too many who are the go-to folks for so many IT organizations trying to address management imperatives.
Remember - as an ITIL Expert I admit to you all that the designation alone means little - except that I know how to study and pass an exam. Like others, I have to regularly dig deep and and call upon my 30 years of experience WORKING WITHIN IT, MANAGING DATA CENTERS, AND MAKING IT PAYROLL.
Different standards
Ian
Sorry for misjudging your comment. IMHO you listed enough errors to make it useless but that is then just my interpretation. All ITIL books have some useful stuff in them but in my mind that is not enough.
Aale
PS
I'm also an old ITS manager who turned into ITSM consultant in 1989. V2 Service Manager and V3 Expert. Studying for the Expert made me much more critical of V3 than I had been before.
Thick skinned but sensitive - thats me!
Aale - no problem - its just that unfortunately there still seem to be a few folks out there that salivate at the chance to take any comment I, and a few of my fellow scrutineers, make about ITIL. I'm pretty thick skinned - skinned I said! But I do want others to understand that what is of paramount importance is that something as important and valuable in so many ways as ITIL, as a commercial product, is subject to the same inspection and comment as any other similar offering. It should be a healthy thing, but it seems some think that its akin to drilling holes in their lifeboat to let the water out.