ITIL 2011 persists with the dangerous concept of supporting services
Not only has ITIL V3.1 2011 not fixed the problems with business-vs-technical services, they have gone the wrong way and reinforced the problem. I will fight to the death to say there is no such thing as internal supporting "services", because I care about ITSM.
This blog post from Vinod Agrasala describes it this way
The new revision of the ITIL gives details of Services to be categorized into:
External customer-facing services
Internal Customer facing Services
Support Services – for the interdependencies within IT
Especially the third category – Support Services, clarifies a long-pending confusion for IT outsourcing companies:
IT Outsourcing companies such as those into infrastructure Outsourcing provide services such as network administration/management, Service administration/management, Monitoring etc for which the customers are usually IT personnel in the customer organization. These services were often deemed confusing in the whole discussion of Business-IT Alignment and Integration context.
Now, with this categorization, the services provided by the outsourcing service providers can predominantly fit into the Category 3: Support Services.
...but I don't welcome it like Vinod does and I disagree about his treatment of outsourcers. I also can't find this three-level categorisation in ITIL 2011, but let's examine it anyway:
Say we are talking about network administration/management.
If the provider is really and truly providing network as a service, and the network truly is managed externally by an ISP under an Underpinning Contract, then it is Vinod's category 1: External customer-facing services, and we are on the receiving end instead of the providing end of the service. SS table 3.4 makes it clear that an external service provider is NOT providing a category 3: Supporting Service.
If the provider is really and truly providing network as a service, and the network team is operating as an ISP within their parent organisation, then it is category 2: Internal customer-facing services. I personally have never seen or heard of this.
Or it is not provided as a service. The network team are providing a function, a practice, a system, a CI, call it what you want but it isn't a ****ing service.
It is easy to tell if something is being provided as a service: is there an agreement? an SLA? a catalogue? a customer-management function? SLM? service desk? availability mgmt?... These things can be informal or formal, implicit or explicit, but they must exist, i.e. the provider must behave as if providing a service, not doing a job. I've blogged before about how a catalogue defines a boundary for the services provided by that specific provider. If the network team are providing a network service, they should have a catalogue, an SLA...
SD 4.2.4 says a Supporting Service is provided by a "service provider" but it also says it is not covered by an SLA.
SD 4.2.4.5 and figure 4.4 are very explicit. The technical service catalogue describes different (i.e. supporting) services to those in the business service catalogue. SD calls it "views" but they are not views: there are different services in the TSC to the BSC so they are not views, they are different catalogues. "Views" don't have different entities in them; they have different data about the same entities. That is NOT what is happening here. [For the geek pedants, that's not strictly true: a SQL View can include a SELECT, but I think the generally accepted colloquial use of "view" suggests selecting columns not rows the views at least come from the same table. Customer services and supporting services are entirely different entity types. A view is a different angle on the same thing.]
SD Appendix G example catalogue is ridiculously facile piffle. SS table 3.4 is very very explicit:
Some IT teams view recipients of supporting services as 'customers'. Although this promotes good service quality, it is also misleading. Supporting services only exist to be combined with other supporting services to produce customer facing services [no distinction between internal and external cstomers]... There can be no service level agreements for supporting services as they are all internal to the same department. Instead the performance of supporting services should be managed using operational level agreements
Read my lips: this is bullshit.
Here's my concerns:
- This talk of internal supporting "services" destroys the whole value of service management by making everything a service. The word "service" ceases to be meaningful. It is a "service" but it is not subject to all the disciplines of ITSM? That's crap. "Service" means any time someone does a job? it's a service when you treat it as a service.
- It also allows techs to crawl back into their burrow and deny any connection with the real customer (internal or external). "Supporting service" is an abdication of their responsibilities.
- The discussion of what services are in ITIL is hopelessly muddy and allows all sorts of interpretations such as Vinod's. As Vinod rightly says, the guidance in ITIL was (and still is) useless in a practical context for constructing service catalogues. It is theoretical waffle.
On all three counts this "supporting services" rubbish is very very dangerous.
P.S if you read the original V3 SS 5.5.4, "supporting services" means something completely different; they are still customer-facing services, seen in the business service catalogue. this was obviously not understood when the term was bastardised by SD (and SS 2011) to mean internal components.
This blogging service was brought to you by Two Hills Ltd.
See also:
ITIL services are customer-facing, whatever catalogue they appear in
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
Clarifying my issue with supporting services
Thank-you everyone for your thoughtful contributions to a stimulating debate. After a long walk with the dog on a glorious sunny day, i think i can be more precise about what my issue is with "supporting services". I'm fine with tracking the relationship between a service and its supporting services where those services are clearly defined as coming from a service provider and being a "real grown-up" service.
My hang-up is with "internal supporting services".
If it is a real service, then it comes from a service provider.
If a unit sets itself up as a service provider, then by definition it defines a boundary, across which value flows as a service.
So if an internal unit in a company does this, it is no longer "internal".
From at least an operational perspective it has become a separate unit (and possibly from organisational, financial and other perspectives too).
And therefore the service it provides is by definition external to those it provides the service to, at least from an operational perspective.
All the use-cases being cited above for supposed "internal" service providers are only internal from some limited sense, and have clearly set up an operational boundary around their own service management.
If the unit have set themselves up as a service provider, then I can accept that it is a "supporting service" but I am sure it does NOT get catalogued as a service in the service catalogue for the greater organisation - we've had this debate before. The catalogue catalogues what flows over the unit boundary: supporting services don't. The supporting service is a component of the services defined in an organisation's catalogue (and may get mentioned in that context), but it is not a service to be catalogued in its own right in the catalogue of the greater organisation because it is not supplied to the customer audience of that catalogue.
And if they haven't done that - if the team is not operating as a service provider - then it isn't a service, it is just a component of a service. This is the area I'm really trying to get at here.
You can throw up all the advanced and esoteric use cases you want and I'll accept that they are external supporting services (though i see little need to treat them as anything more than a CI of the service).
I'm getting at the main, primary definition of a supporting service as quoted from Table 3.4 in my original post, where it is clear and explicit that "There can be no service level agreements for supporting services as they are all internal to the same department". That's crap, dangerous crap.
Service Component vs Service
First off - your quote from Table 3.4 is incomplete, it should read:
"There can be no service level agreements for supporting services as they are all internal to the same department. Instead, the performance of supporting services should be managed using operational level agreements."
Although you can still argue about it, it does provide relevant context and makes it a lot less crap.
As pointed out above, there are many big companies with many internal departments that have their work set up as 'services', which are then integrated at a different level/department.
e.g.
- External provider provides "Service: Linux server" (= datacenter, housing, OS support)
- Internal dept. APPS provides "Service: Webhosting LAMP"
- Internal dept. CST-X provides "Service: webhosting for basic websites incl CMS and support"
These third depends on the second, which depends on the first.
So, how does that work out in the Service Catalog?
The Business Service Catalog lists "webhosting for basic websites incl CMS and support", the flipside (Technical Service Catalogs) says that this service is delivered using Webhosting LAMP from APPS, and a CMS installed & managed by CST-X, and a phone number to CST-X people for support. This flipside is not revealed to the customer.
The details of Webhosting LAMP are not relevant for the customer, but are relevant for CST-X. CST-X looks at the 'Business part' of the APPS catalog.
Where do you agree on a specific service?
The SLA with the customer states that www.corp.com, www.intranet.net, www.public.com are hosted used webhosting for basic wesites incl CMS and support.
The OLA between CST-X and apps states that there are 3 instances of Webhosting LAMP.
The UC between APPS and the external provides states that they require one Linux Server.
Notes:
- Catalogs are 'logical documents', could be an integrated database, or a physical document, or maybe even somewhere hidden in your tooling.
- As with all ITIL, the appropriate structure and way of dealing with SCs depends on size of company. Each (major) internal department can have their own SC as long as they provide a delineated service. ITIL calls them Supporting Services, you call it Components of a service. I don't care what we call 'm.
- Definitions do not change, however, the name of a document can change if you change perspectives (e.g. a UC for you, can be considered an SLA for that supplier. it's the same doc and is typically called an SLA or contract, not UC)
OLA and UC
Rob,
While I agree as usual, that ITIL documentation could be more clear and contextual, a note to the reference you made to Table 3.4 above:
While the table says for "Supporting Services" that: "there can be no SLAs for supporting services as they are internal", the same paragraph goes on to say "they are usually managed through OLAs and UCs".
Which I think is fair - they are internal, then OLAs, if they are outsourced, then UCs.
Vinod
Enterprises and holding companies
Real world example:
- Mixed holding company/enterprise model.
- 85 lines of business.
- Extensive shared services, and many lines of business wanting no part of them.
- 40% of app dev centralized, 60% decentralized into LOBs.
- All data centers under at least minimal central control.
- All networking under central control.
- Some LOBs have centralized app dev teams that mirror the "enterprise" app dev capabilities. These LOB "centralized" teams in turn find "rogue" IT that *they* seek to control.
In such an environment, the following services are absolutely legitimate:
- Centralized application services (e.g. customer management)
- Centralized back office application services such as payroll & HR systems
- Centralized "hosting" services offered to both the centralized app dev team and LOB app teams (themselves radically diverse in degree of centralization)
- Centralized data management services (no I don't want your developers but I'd love to have someone run an Oracle database for me)
- Centralized storage management services (just give me a few terabytes of SAN, I'll handle the rest)
- Centralized network management services (we administer everything from the server on up, but - sigh- you have the monopoly on establishing WAN links into any corporate facility, so we gotta deal with you)
- Centralized security services (the enterprise risk team & the Office of the General Counsel make this non-negotiable)
I'm sympathetic to scrutinizing any "services" much smaller grained than the ones I've listed above. But sorry, yes, I have seen a an internal network capability having to act essentially as an ISP, more than once. This is especially likely in companies that are schizophrenic about whether they are enterprises or holding companies. The units that want a holding company model become very reluctant customers of the enterprise shared services, and a strong service-based interface becomes something they insist on, because they tend to be very well aware of the external sourcing options they wish they could pursue.
And so, as noted above, we run into the tricky boundary of intra-IT services. If the hosting organization offers services to a remote LOB, that would seem to be reasonable to most of the above commenters. Is such a service then illegitimate if also offered and consumed entirely within the central IT organization?
Charles T. Betz
http://www.erp4it.com
Definitions and concepts!
Hello friend!
A very interesting post with a ton of interesting and smart discussion around. My opinion is that ITIL has perverted the concept of service. It started being an it system that supported a business process, and ended being anything. Why? I think that just because with a broader definition the market is bigger.
I use to talk with two different kind of itsm professionals: service providers ( in the sense that they work for consulting and/or outsourcing companies delivering services [not only it services] to customers) and internal it people that manages the services that an IT unit delivers to the organization.
Two completely different worlds with completely different objectives,interests and behavior. So... The word service means different things for those two sectors. In the beginning ITIL was well suited for internal it, but it has evolved... Now it is completely focused or adapted to fit to the needs of outsourcers and third party service providers while forgets the internal it.
In my opinion, an internal it mainly provides the organization with managed it information systems (and that's what they call service and this is why their service catalogs are mainly application catalogs)
Just my 2 cents before going to sleep...
Antonio Valle
G2, Gobierno y Gestión de TI
http://www.gedos.es
I like the concept of supporting services
I generally agree with you Rob, but on this point and at this time I must demur.
I use the concept of supporting services quite a bit. It works well because it helps the organization focus on building their services with a customer in mind and with the idea of providing predictable, repeatable execution and outcomes.
It seems that IT is, increasingly, becoming commoditized. What helps with that is the modular, loosely-coupled design of "services". Even those services that are designated as "supporting", that heretofore might have been considered back office functions, can be, to a great extent, commoditized.
IT is under increased pressure to prove its value. As big vendors sell their outsourced services to the company - bypassing IT - IT will have to develop greater trust and transparency of costs. Organizing around IT services - even supporting services - helps with that. When customers, "the rest of the business", can see what other services besides the app, they pay for, it helps them understand what the real extent of the services that IT is providing and what they are truly paying for.
Defining these functions as services helps the function focus on who their customer is, just what services they provide, what the breakdown of those services are, who is accountable, and how they provide them. Even, perhaps, managing them with Six Sigma (DMAIC) and Time-Driven Activity-Based Costing to show evidence of continual improvement. Specific accountability for tasks, WBS, etc. SLAs if they choose.
Nothing improves the "rest of the business's" trust with IT more than transparency of costs and knowing what they're paying for. Nothing.
Developing services - even back office functions - as services helps the customers know what they're "buying."
Defining those services so that they can be easily compared to externally available services helps too.
If this is a matter of terminology, that's fine. I've regularly complained about the awkward terminology within ITIL (we've had the discussion of the terrible use of Asset many times).
Relative Terminology
Rob,
Cary’s post captures my thoughts pretty well, but since I had started writing this earlier today I’ll submit it anyway…
I think I’m clear on what you’re saying, and the purist in me wants to support you 100%... we’ve had lots of debate in my organization where folks want to call every activity in their day a “service” and put it in the catalog as such. It can be exhausting…
Where I'm a little more flexible on the matter is that all of this service terminology really is completely relative to where you draw the boundary between provider and customer. It’s very clear when the two are separate legal entities or when there’s a real exchange of money, and I think you would also agree that it’s clear between an IT department and other business units within the same enterprise (who typically have separate budgets at least). The gray creeps in when we start getting into intra-IT boundaries. I want to keep a pretty tight lid on this stuff, but there are some legitimate candidates for exceptions in some of the enduring technical silos as certain things become more of a utility.
I think scale also has something to do with it… I work in a place with a very large IT department (~3000 heads in IT). In this kind of environment, there is at least one traditional boundary, between App/Dev and Infrastructure areas, where it feels appropriate to recognize the concept of a “Supporting Service.” The folks who build and run our applications for their business-side counterparts need infrastructure (computing, network connectivity, etc.) to run their applications. From the business customer perspective, you’re right… all those servers and fancy data center toys do not represent a service in any respect, just the necessary evils that support the “Internet Sales” service they need to bring in revenue. But, from the perspective of the App/Dev groups that need a platform on which to run their code, all of that data center stuff can increasingly be treated as a service they are consuming.
It didn’t use to be this way... As an example, a decade ago application groups basically paid for dedicated physical servers, and had aligned resources from the server administration group to help support them. I’d agree with you that at that point in time, the server space was not so much a service, but more of an ongoing cycle of hardware purchases and job duties.
Now, we’re moving toward more “cloud-like” hosting models where everything is virtualized, the physical infrastructure is neither designed nor paid for directly by our app teams, and the server admins are no longer aligned to any particular application…. The computing capacity is on the floor already, and app teams consume server instances while the server group manages the overall physical capacity, technology refresh, and day-to-day administration of the environment as a whole based on expected demand. We are attempting to standardize the infrastructure components and management activities into explicit offerings with stated service levels and costs… so, the effect is that we’re getting very close to something that really is a “supporting" or "shared" service.
I imagine it is a lot like the mainframe days, just more complex and with fancier vocabulary.
That's a service
That's a service - packaged provisioning of platforms/environments for development teams. When we package the result into a defined deliverable, take on commitments as to service levels and costs, define and negotiate with the customer, and fulfill requests from a user, it is a service. Going back to the original post, it is a service for an internal customer. So what? Email is a service for internal customers, some of whom happen to also work for the provider of the service. Development platform provisioning is a service for internal customers, many more of whom happen to work for the service provider (but not necessarily all). I'm not seeing a third category here.
no warning
As in comments I just posted above, we agree so long as they ARE really services, but too often they aren't. Too often it is a glib title, a debasement. And ITIL lets them do that: there is no warning I can find, no stricture that if you call it an internal supporting service it must be a service.
Support Services Makes Sense
Rob,
I believe support services makes plenty of sense, and this type of an organization/setup does exist.
I work for an organization which is divided into front office (FO) and back office (BO). The back office work is outsourced to a different country within the same organization. Both FO and BO are IT personnel. FO and BO work towards the same service, and they are covered under a OLA.
So, in a sense, the BO is providing supporting services to the FO, and the deliverables from both units are towards the service on a whole.
By stating supporting services explicitly in ITIL 2011, the whole ambiguity of setups such as my organization is put to rest.
Abhinav Kaiser
http://abhinavpmp.com
call it anything but a service
The back office has a customer management function? Availability management of their delivered service? Maybe they do function as a service provider but more likely they function as an internal department. I think you should call it a function or a team or a system or anything but a service. What ambiguity? We all know services are made up of supporting CIs, which can be anything.
if you call it a service, then the BO only need care about what they deliver to the FO, and BO can lose all line of sight to the true customer and the real service delivered.
if we are going to recurse down into a service and call every composite CI supporting it a "service" where does it end?
As I said to ITILzealot on twitter, this is a "service" in a new meaning of the word which redefines "service" to mean any job someone does. We are agreeing on everything except what to call it. "Service" is just wrong. It's like little kids wearing their parents' shoes.
Service or not
"...if you call it a service, then the BO only need care about what they deliver to the FO, and BO can lose all line of sight to the true customer and the real service delivered."
I certainly agree that not all work should be considered a service, but in this example would an OLA drive any different behavior? Sounds much the same, to me. The service conontaion at least implies there is a customer at the end of the chain. My 2 cents.
my customer is your customer
If my customer is your customer is the organisation's customer, then we share responsibility for delivery of service. We are a team.
If my customer is you then so long as I do my bit I'm alright Jack. It is you guys who are screwing up delivery to the organisation's customer not me. Talk to the hand.
My 1.5 cents
Definition
The BO is basically performing certain activities that constitute a service (in some cases all activities). It could be preparing a RCA document or performing trending of incidents. FO is in place to face the customer, and to pass on the feedback and expectations of the customer to the BO.
If you look at the definition of an IT service - "An IT Service is based on the use of Information Technology and supports the Customer's Business Processes. An IT Service is made up from a combination of people, Processes and technology and should be defined in a Service Level Agreement." The BO is certainly doing what the definition claims as an IT service.
Abhinav Kaiser
http://abhinavpmp.com
Using ITIL's own definition of service
The official ITIL definition of a service is "a means of delivering value to customers by facilitating outcomes customers want to achieve without the ownership of specific costs and risks". Wading through that consultant-speak, it would be an amazingly progressively-managed organisation where the network team accepted costs and risks on behalf of IT Operations, and/or measured their deliverables in terms of their customer value. THAT is a service.
If the network team worked that way, and managed their service as a service, then I'd be happy to call it a "supporting service". But that isn't what happens, and ITIL fails to make it clear that is what must happen to call it a service. So we get all these little "services" which are in fact just teams with no ownership of cost or risk, no concept of delivered value, no perception of their role in the true service, and a limp concept of what a service actually is.
Service
Rob,
I think you have difficulty in agreeing these deliverables as "Service" since it is done within the same organization.
Just imagine for a moment, that some these activities (say Server administration, Network monitoring etc) are Outsourced from an external service provider organization - then won't these qualify to be "Services"?
In this case, the service provider (second organization) has Customer management function, they have availability management for their delivered service, capacity, continuity - the whole spetrum of IT service management - for the "Services" they are delivering to the first organization.
If in this case they make sense as 'Services', which category it will belong? I would vote for "Supporting Services" category of ITIL.
This is why I mentioned in my blog that this category adds a lot of sense to IMS providers.
Vinod Agrasala
they don't have any ITSM
"have difficulty in agreeing these deliverables as "Service" since it is done within the same organization"? No. I have difficulty in agreeing these deliverables are a "Service" because they - generally - aren't. They don't have the full spectrum of ITSM, they don't have any ITSM, culture or practice. They just slap a label on what they do and call it the Net work Service. Now nobody knows clearly what a service really is any more. I have seen this and was horrified.
Things we do
Yes, you are right. Again ITIL makes things too complicated.
There are things IT people do, like running a service desk or a server or a network etc. This is work, not a technical service.
Then there are services that the customers want. What is a service depends on whether it is something somebody wants to buy. For example a Service Desk is usually a component of some service but in some cases it can be a service itself. All services need to have people and systems working for them.
I have found that it is a useful practice to create a work/service matrix, which connects the service to the work done by the IT.
Aale
Service vs Provider
Rob,
I am not committing to fight till death on anything ;-) However, let me clarify a few things about the blog that you quoted and my reference topic (So that my blog should not look like a pile of Bull Shit!!!)
On little more serious note :
- ITIL 2011 has given the three-level categorization. Since you have difficulty in locating it: please refer to Table 3.4 in Service Strategy book
- These are three level categories of Services and NOT Service providers. So if you read my example of the Internal IT Department of the Bank and the examples I quoted, probably my stand will be a little more clear.
- The 'external customer facing services' - I am not refering to IT services provided to external Services. I am referring to IT Services that are inbuilt into, or part of a business service provided to external customers (of the business). Hence my examples of those refer to Internet banking, business portals etc.
- I believe these three cateogry of services exist in a typical Business organization and each of these services (irrespective of which category they belong to) can have specific Sourcing Strategy : Insourcing, Outsoucing, cosourcing etc..
- I have experienced the benefit of defining supporting services - in the establishment of OLAs and UCs.
- The Table 3.4 text against the Supporting Services in ITIL Service Strategy states that (I quote - not fully) :
" - There can be no Service Level Agreements for Supporting Services.
- Performance of Supporting Services are managed using OLAs
- In some cases, the supporting services ARE SOURCED FROM OUTSIDE THE ORGANIZATION. In these cases they are managed in the same way as other supporting services, but using underpinning contracts."
My reference to outsourced service providers (like IMS providers) was aligned to the third point from the quoted points above.
Even the 'Network Service' that you referred to will fall under Category 3 - supporting Services (provided by a Type III service Provider if it is outsourced, or by Type I or II provider if it is not).
Hope this clarifies my views...
Vinod Agrasala
www.itserviceview.com
pretty clear
I think it is pretty clear from Table 3.4 and elsewhere that ITIL is viewing supporting services as internal or external, equally. The danger lies in the internal situation, where we either
(a) slap the "service" label on an internal function which isn't managed as a service, destroying the meaning of the word, or
(b) manage an internal function as a service which allows them to say "well MY service is running fine so don't look at me" which takes us right back to the bad old days of siloed IT techs.
You're right Table 3.4 does describe the three levels and I overlooked that :) but everywhere else there are only two: customer-facing and supporting.
And no i didn't mean to imply your post was bullshit! I liked the discussion overall - I took exception only to welcoming "supporting services" as a concept and used your post as an example of how you and i can come to such differing conclusions from the same books because the guidance they offer is vague and theoretical.