What is a service?

The word “service” certainly gets some exercise. ITIL v3 says “A service is a means of delivering value to customers by facilitating outcomes customers want to achieve, but without the ownership of specific costs and risks.”

This impenetrable bit of consultant-babble does not help those who are trying to grasp the fundamental concept.

The itSMF repeats the same waffle in their introduction to ITIL V3, but they then take pity on us by providing a practical example, where the outcome of sales people getting more customer face-time is delivered by a service which provides remote access to systems. (In reality, we all know that sales people spending less time in the office does not translate to more time with customers).

This is an advance from the ITIL v2 pocket book from itSMF which avoids the whole question of defining a service, though it does in passing say that a service is about “ICT infrastructure and management processes that deliver the information and solutions required by the business." ITIL v2 was centred on the process not the service, and in fact that other excellent itSMF pocket book for ITIL v2, IT Service Management, talks about “service” as a verb rather than noun in all parts of the book except the Serve Level Management section.

The ITIL V3 Glossary naturally repeats the party line quoted above, so we are no further ahead. Even the ever dependable Wikipedia omits a definition. This might be because defining a service is hard. It is one of those words where people know one when they see one but struggle to create a crisp, clear definition that covers all instances.

I prefer to follow the “Hitchhiker’s Guide to the Galaxy” approach: it is okay if something is “relaxed” and “contains much that is apocryphal, or at least wildly inaccurate” so long as it is ultimately practical and useful.

Users regard IT as a utility delivering “stuff” in the same way as other utilities deliver water or power. IT is a pipe and what comes out the end are IT services. Users don’t give a toss about the ponds, pumps, purifications and pipes needed to deliver out of the pipe—they just care about the consumables delivered to the screen in front of them.

Customers and users care about all that infrastructure only so much as they care about the cost and standard of the delivered consumables. [Note: ITIL makes a good distinction between users and customers: the user uses; the customer pays.] So, services are what come out of the pipe not what happens to get them there.

What do users consume from IT (or if you prefer, ICT)? They consume transactions running on technology. They add, update, find, view and report data. They execute a process. They communicate with someone. The value and quality of those services is measured by whether they are the transactions that the users need, whether they do what is required, and how well they do it. All those things are defined from the user/customer point of view, i.e. looking at what came out the end of the pipe.

Okay, so this, then, gives us a nice, crisp definition, right?: IT Services are transactions on technology.

Well yes, and no (of course). Now we will mess it up by exploring a grey area.

Not all customers want to trust IT as a total service provider (for good historical reasons). They are not willing to “black box” the services, to use the application service provider (ASP) model (now software as a service (SaaS) but still the same model). They are not willing to look only at what comes out of the pipe.

They either (a) want to know about the ponds, pumps, purifications and pipes and define the consumable in those terms or (b) they want to provide some of those themselves. In that case, they are treating IT as an infrastructure service provider (ISP) (and you thought it meant “Internet”).
The customer wants to take some responsibility for their applications, and looks to IT for platform (servers, operating systems, desktops, databases, network, etc.), storage, bandwidth, and/or management (security, availability, backup and recovery, etc.). This is common in geeky departments like engineering but it can crop up anywhere.

Neither ASP nor ISP is “correct”. Whether one or the other model is preferred (or prohibited) should be defined in the IT part of the business' strategic plan, and each service definition should make clear where it fits. What is important is for all parties to be clear on what the model is. Confusion and disagreement vanish the moment people realised they are talking on different levels.

If we can ignore that real-world intrusion into the idealised total service provider model we can come up with a slightly more precise definition that still does not become too waffly: An IT service is the offering and/or consumption of a type of transaction running on technology.

“offering and/or consumption”? Every service provider sells the services they provide, even internal corporate service providers. There can be services that someone is already consuming, and there can be services that are there but nobody is taking them yet.

There, we can’t make it any easier than that.


Arachnid sense

Lately my sixth sense (what Parker called arachnid sense) is buzzing around this subject. I don't know exactly how to explain this, but something is telling me that we are wrong... really wrong: all the ITSM "science" is talking about Services, but then, when we try to explore a little bit more those concepts we find that in fact we are talking about two very different kind of "services": IT Services -something that, in fact, is a more or less complex IT Information System- and "Profesional Services" -something that matches the definitions of services (intangible, non stockable, etc etc) that we have seen in this thread-

Can you tell me that the Database, the router and the server are "intangible"?
Can you tell me that for a cloud provider, the virtual servers are non-stockable?

The IT Information System is stockable and tangible, what is non-stockable and intangible is the *use* that the business makes of those IS... (the information, may be the transactions, the conversations....)

We use those "profesional services" (what Pink calls profesional capabilities in the "defining service catalogs..." book) in order to ensure that the IT services are delivered to the users in the best possible conditions.

So I think (and please, dont forget that this is not a mature thinking, just an intuition or arachnid sense) that the root cause of the discussions and probably of a big portion of ITIL incoherences is the usage of the word service (and not linking to the word IT) in IT Service Management.

Using ITIL and the other tools, we don't do Service Management... we do IT Information Systems management... using profesional capabilities, structured as processes and functions, and so on...

What's your opinion about this?


Antonio Valle
G2, Gobierno y Gestión de TI



I think some of the reason for you spider senses tingling is that the ITSM goalposts are on the move just as they were in reach.

Most of us have been aiming towards a view of operational IT services that add value - using ITIL as a service differentiator.

The possibility exists though that our consumers aren't interested in that value add. Or actually there was never value to be added where we were looking for it, only barriers to be removed.

What they want is a commodity service that enables the other aspects of IT to deliver value.

Who cares about negotiating n SLA if the service is "just there"? What service is there to manage in any sense that is visible to the customer?
The only negotiation around an SLA becomes "How is it OK for us to disappoint you by not meeting your expectation?"

All those good and essential things we need to do to deliver the commodity service sink beneath the waterline.

Which leads to the question of whether your professional services route is a way of rising above the surface again. The idea is initially attractive, but what exactly would it involve that other people in the business or the value network are not already delivering? Remember in a lot of organizations IT is playing catch up when it comes to the service catalogue compared to what their customers are already offering to the outside world.

I should clarify that I think most IT departments are not yet in a position to deliver commodity services and ITSM remains very relevant.

System vs. service

I went to Walter Library (a gorgeous building btw) at the University of Minnesota 2 nights ago and downloaded the Oxford English Dictionary definitions of "system" and "service."

What struck me about the two concepts was:

- A system is complete and sufficient unto itself. It exists independent of value or utility.
- A service is incomplete without a recipient; it is a potential or real relationship. Value and utility pervade most of the variant definitions (of which there were some 36 pages worth).

I don't know what you mean by "commodity" services but (as is frequently remarked) the commoditization dynamic in computing is ferocious; today's cutting edge program becomes tomorrow's library buried in the operating system.

Re: professional services. In an IT context, what value do they deliver? In most cases I can think of, the end value is a correctly functioning IT service that is optimized along some dimension (utility/warranty). The "value" of that system is the delivery of authoritative transactional control. So the IT consulting avenue is merely preparatory.

Now, if the IT consultant says "did you realize that this new capability could net you $MM over the next 2 years?" then I guess the definitional part kicks in - is this "IT" consulting or "business" consulting? But in general we don't see "IT" consultants able to contribute much along those lines without deep, deep domain expertise in a particular business context - domain expertise that (except in the cases of polymaths) usually comes at the expense of currency in "pure" IT skills.

Charles T. Betz



You did what I thought I should do, went and searched for research results. I think we should understand that this is a real scientific subject. The serice-product dichotomy has been replaced by a service-product continuum as most products are worthless without service.

"The dichotomy between physical goods and intangible services should not be given too much credence. These are not discrete categories. Most business theorists see a continuum with pure service on one terminal point and pure commodity good on the other terminal point.[citation needed] Most products fall between these two extremes. For example, a restaurant provides a physical good (the food), but also provides services in the form of ambience, the setting and clearing of the table, etc."

The citation is missing but I have learned this way back from Christian Grönroos. Here are some short clips from him. Listen, they are good. We are all in the hamburger business. http://www.hanken.fi/staff/gronroos/



As Ian Clayton always does, i commend readers to the extensive body of work out there on Service Management. We in IT think we're inventing it but we're just refining a mass of IP. the goods/services spectrum, intangibility, perishability etc are service management concepts three decades old or more. I've spent an enlightening half-year exploring what's out there!! As you guys say, there may not have been much research on ITSM to date, but there is some on SM.

As Ian also points out, due to the fact that there is no real distinction between service and product, the long-established discipline of Product Management is equally applicable. In fact as you will note from some of the comments above, I'm trying to train myself to use "product" to mean a mix of goods and services, not just the goods bit.

Hold on a sec

"We in IT think we're inventing it but we're just refining a mass of IP."

Well, actually, we are. I'll explain in a moment.

"...the goods/services spectrum, intangibility, perishability etc are service management concepts three decades old..."

Boom. There's the problem.

This is a very old, and, believe it or not, very rich discussion. And without the context of the larger narrative, the modern day treatments are under-appreciated. I've long since toyed with the idea of writing a book on the discussion, colorful characters and all.

Take for example, Adam Smith. His book, The Wealth of Nations, has arguably done more to instruct, enlighten us about business and economics than any other. Yet he took a provocative stance when he distinguished between goods and services with the criteria of capital formation rather than production boundary. The output of services could not be stored in inventories or augment the stock of assets, so he deemed it "unproductive" labor (not to be confused with worthless).

He never describes services as "intangible", that happened later with Jean-Baptiste Say in Traite D'Econonie Politique. Say argues Smith as wrong, compellingly, but then makes an unfortunate turn with his choice of terminology. And he likely realized it, as he writes in a footnote:

"It was my first intention to call these perishable products, but this term would be equally applicable to products of a material kind. Intransferable would be equally incorrect, for this class of products does pass from the producer to the consumer. The word transient does not exclude all idea of duration, neither does the word momentary."

The renowned John Stewart Mill later steps in to defend Smith writing, "Productive labor means productive wealth." He argues that because wealth normally refers to only material products, broadening the definition to include human capital would create confusion.

The argument continues to this day, with many interesting turns. IHIP, for some strange reason, became a hardened criteria during the '80s and early '90s. (IHIP = Intangibility, Heterogeneity, Inseparability, and Perishability.) This might have lasted until the current day if it wasn't for...

The Internet and the emergence of IT.

Yes, despite Ian Clayton's admonitions, IT is reinventing new product management rules because it is breaking the old ones. IT Outsourcing, for example, violates the Inseparability clause. Airport and Hotel Kiosks break the ideas of Heterogeneity and Perishability. Because of IT, IHIP is no longer taught as dogma in the leading university graduate programs.

Because of IT, Intangibility emerges as an ambiguous and surprisingly limited concept, causing many other fields to think differently. In fact, many IT services key goals are to obtain tangible changes in themselves or their possessions. The tangible outcomes of such changes range from ephemeral to the irreversible. A high labor content does not necessarily render a service physically intangible. In fact, the role of service desk personnel in many service environments is to help bring about a physical change in customers themselves or in their possessions. Think GM's roadside assistance, Healthcare support services, as well as Dell's platinum support services. Remarkably, you can find a CMDB/CMS and SKMS in each of these environments.

A common exception to the generalization that all services are perishable (non-storable) is found among IT services where there is the option of recording video/music for later resale and reuse. The service provider’s output is durable and replicable, and the customer can enjoy the performance again and again. I can point to a form of this on my Playstation gaming console and home theater equipment, where I can similarly enjoy improvements to firmware and codecs with online updates; stored services I use at my need and convenience.

The debate is by no means settled. But it doesn't surprise me that the freshest thinking is coming from IT domain. If we simply settled on "long established" non-IT practice, then everyone on this board should simply be classified as "unproductive."

Insert punch line ...

struggling with all your examples

I did say IT was refining existing bodies of knowledge. i never advocated going back to following them slavishly. I merely suggested learning more from them - or at least that is what i meant to mean. certainly, treating ITIL as the font of all SM wisdom is unhealthy.

I'm struggling with all your examples to see how they challenge the concept of product as a mix of goods and services. It seems to me IT is only unsettling to those who deny the continuum, who see services in a pure form. And I thought we got past that about ten comments ago. IT products include a tangible goods component. Your downloaded song is a good example. the recording is in its own way tangible. the service is the use of the song.

Likewise you'll need to enlighten me on how outsourcing violates inseperability OF THE SERVICE COMPONENT of the product.

Service desks bring about physical change in exactly the same ways as those classic SM examples: masseurs and car washes. Nothing new here.

IT does indeed live at the edge of some service concepts but I don't see it breaking them.

I've forgotten where we started

Can someone remind me why all this matters? Was it simply that we didn't think ITIL had a good definition of service, or does the panel think that by getting a better understanding of where IT fits on the goods - services continuum changes our approach, and if so in what ways?

IT is often treated as a pure service, which it isn't


IT is often treated as a pure service, which it isn't. there are objects involved, which may be tangible only in a broad sense (e.g. the downloaded movies discussed above), but are nevertheless goods not services. So are all the asserts we manage and deliver, so are the software packages we deploy, so is a RFC...

In not too many years i suspect we'll revert to talking about product management, of which service will be one component

Distinction still remains

I'm still thinking all this through, so bear with me.

By commodity service here I'm thinking of a third party provided service that is generally reliable and predictable, and where the client has little or no control of the service levels but only of their level of consumption. Having said that I think it , and some of what follows, contradicts what I said in this thread back in May or sometime when I said a commodity service is easy to specify. It is in terms of "I'll have some of that please" but not in terms of what that means either in terms of the constituent parts or the value it delivers. Think a home broadband service, perhaps.

The service system distinction still remains I think. My client still has and needs an accounts payable service that can be described in business level terminology without reference to the underlying technology. In the bad old days in IT we wouldn't have been very aware of that. We would have known that it ran on this server, using that app and that's how we would have presented it to the customer - as a set of disparate systems. Our SLA might have talked about availability of the server in % terms, not aboput availability at the desktop. In recent years we've tried to stop thinking like that and instead tried to align with the business. So our SLAs has shifted to the users ability to carry out a specific business transaction. we can do that because even if we have external suppliers in the mix we have sight of the value network and can can exercise a degree of control, even if it is contractual rather than operational. And so we took responsibility for the overall service.

Here and now I have a client who delivers all their services to their internal users via the web. Currently all their applications are running at an external data centre under a traditional application support model, but it is already difficult to specify the overall service an individual will get. especially if they are one of the individuals dependent on a 3G service. From a user perspective the view is that this is a web service, and therefore it will just be there, 24x7. The customer view is slightly different, but related, they no longer want to allow individual business units to specify the service levels they get. Suddenly we are also back to a model where downtime between the data centre and the desktop is no longer seen as the IT departments concern*, only this time the business is driving that view. The difference is that the business now have a reasonable perception that their users will normally be able to access the internet.

Now move those applications to SaaS model and what value can the internal IT department add operationally? What do our SLAs now look like? Two years from now
can I make a meaningful commitment to my customers about the availability of their documents stored on Googledocs, or the availability of the virtual call centre we are operating?

The user is still getting a service, but are we still managing a service?

*Not strictly true currently because they can specify exemption from bandwidth throttling for certain kinds of traffic, but that is stilla bout dealing with a constraint rather than adding value.

IT product management

I'm sure you're right Spider. And it is because IT does not provide pure service. As discussed above, nearly every provider in nearly every industry provides a mix of goods and services. we should be talking about IT product management, where a product is a mix of goods and services. This is exactly the same existing product management discipline that Ian Clayton often refers us to.

What is a service?

CMMI-SVC defines a service (not an IT service: any service) as "a product that is intangible and non-storable" which goes back to the first comment here from Aale about "can't drop it on your toes"

It's not original, it harks back to stuff I've read from the 1980s. But man is it easier to grok than the ITIL definition!

Some Elvish

"a product that is intangible and non-storable"

This definition (from Parker in 1960) was recognized as flawed even in the 1980s. This is either amateur hour or the CMMI-SVC took the lazy way out.

"Intangible": First, such a definition would exclude the transformation of tangible items from services. Second, there is a spectrum, not a hard dichotomy, when separating goods from services. In fact, there are goods that are less tangible than many services. Consider the wide variety of business products involving DVDs, MP3s, pizza delivery, and checking accounts. Moreover, most services do involve goods. Without the car, there is no car rental. So yes, you can drop a service on your toes.

"Non-storable": Perishable, to be more precise. Writing in French, Say was the first to describe a service attribute as immatériel. He missed the mark. Again, physical goods can also be perishable. In fact, perishability and inventory present a more challenging issue for manufacturers than for service providers. Perishability of service capacity is not the same as a perishable experience for a customer, and perishable capacity is not the same as perishable output, for without customers who require service at a specific time, there can be no output at most service organizations. Think airport kiosks, who do a fine job of storing my service capacity. Certain types of services such as education, entertainment, music, and news, can be recorded for subsequent service storage and consumption.

"An IT service is the offering and/or consumption of a type of transaction running on technology. "

What about consulting? What about security? What about training? Does it qualify if the service is running on powerpoint or my iphone app?


The drop on your toes is of course just a joke. The article which I commented earlier in this stream argues that even products are bought for the services they provide. Your stored music is actually a product bought for the listening experience. A car, rental or own can provide value in many ways, transportation is just one of them.

The non-storable is not the same thing as perishable. The value recieved from own skis and rented skis are the same and both can be painful on my toes. Renting the skies relieves me from the trouble of transporting the skies and from the investment as long as the service works when I need it. If it does not I will not be skiing when I stand in line to wait for the service. The ski shop may have had excess capacity all week but it cannot save that for the Saturday rush hour.


Good Points...

Visitor makes several good points here that are worth noting:

"Intangible": First, such a definition would exclude the transformation of tangible items from services.

I agree. While the tangible item is required (the raw material) to deliver the service and fulfill the customers requirements, the services to transform it are where the value gets added. I think this is a key element to keep in mind. No value add, no service.

Second, there is a spectrum, not a hard dichotomy, when separating goods from services.

And that's exactly why in the USMBOK, we use the term "Goods-Service Continuum" and give examples along the continuum.

Without the car, there is no car rental.

Very true. I'll point back to my first statement. I'm really not renting a car (per se) as much as I am taking advantage of a capability. Exactly what car or its attributes are of less concern to me than the capability. Of course, to someone else, it may be everything!

In fact, perishability and inventory present a more challenging issue for manufacturers than for service providers

I think this depends upon the service provider. The relevant case here, following your lead, is an airline flight. An airline operates many routes and wants to get as many people on a given flight as they have seats available. Once the plane takes off, you can't readily get on the plane and use that seat... unless your Wesley Snipes! :-) So, perishability is just as much a challenge here as with a manufacturer, grocer, etc.

Training providers have a similar problem. Once the class starts, you're hard pressed to insert new students in without disrupting the rest of the class. If they do, they risk undermining the value and expectations of the existing students. Not a good deal.

Does it qualify if the service is running on powerpoint or my iphone app?

Sure it does! Again, in the USMBOK, we talk about Service Access Points. It's the desire of a service provider to give customers access to services in whatever way/means/lcoation that will have them be satisfied customers. The customer experience may be radically different from one access point type to another, but that doesn't (or at least shouldn't) diminish the value the customer derives from utilizing the service. If it does, then there's some work to do to get it right.


mere mortals

Valid points. I agree neither definition is perfect.

I still await the day we get a definition of service that works for mortals not elves

A service is intangible and non-storable

You know, on further consideration you may make valid points but I'm not sure you are right. or more precisely i think it - as always - comes down to semantics.

A product involves an intangible non-storable service component, even if it also involves tangible goods too. Goods and services are indeed a continuum, so if we are to usefully use the word "service" what does it mean? it means the intangible non-storable part of a product which varies across that spectrum (using the word "product" to refer to the mix of goods and service that makes up the offering, not to refer only to the tangible component).

So CMMI-SVC's definition does not "exclude the transformation of tangible items". By taking such a position you are being absolutist and denying the very spectrum you refer to. "transformation" is both intangible and non-storable - it is an act. So no you can't drop the service component of a product on your toes.

I don't think recorded music is a service. As we agree, most products are a mix of goods and services. the service component is the supply of that recorded music to me, not the tangible recording. A music recording is a good not a service.

yes some goods are perishable. that's why "non-storable" is a better word - even perishable goods can be stored. "Non-storable" refers to the interaction with a human and the immediacy of consumption of the service component.

So I think "intangible and non-storable" works well as a definition of service - it's not perfect but it is pretty bloody good. if you read CMMI-SVC instead of insulting it you'll find they expand on that definition to address some of these issues. It also worked for Sasser, Olsen and Wyckoff in 1978; Rust, Zahorik and Keiningham in 1996; and Haksever, Render, Russell, and Murdick in their classic text published in 2000, so if something you read in the 80s poo-poo'ed it may I suggest we have here a disagreement not a universal rejection.

IT services as transactions

I think that the idea that information services are by definition transactional has merit. I just re-acquainted myself with David McGoveran's excellent series on the topic (available by request from http://www.alternativetech.com/). One needs to start from the premise that business itself is transactional by definition. In a business context, what else does IS do other than executing and controlling state changes in data sets and authoritatively guaranteeing their integrity across creating, reading, updating, and deleting? The history of information technology, even pre-Turing/von Neumann, can be read in this light.

These fundamental ACID responsibilities aggregate up into the longer lived transactions by which we assert and accept value, up to and including legally enforceable contractual and property rights.

All else is subordinate, preparatory, or ancillary. Storing a PowerPoint file, uncorrupted... that is a transaction.

This also paves the way towards the correct application of industrial analogies, as I have commented on here.

This definition does tend to exclude pure telecomm services, e.g. basic voice...

Charles T. Betz

User journeys

I like the transactional view, though of course we need to be aware IT people tend to interpret transaction in a very concrete way.

A service is less and less about discreet, consecutive or overt transactions.

I wish I hadn't written that sentence before thinking of examples!

Retailers long moved on from looking at single purchases at the cash register to the overall relationship with specific customers. via loyalty card schemes and on line shopping. They are also increasingly aware of how their customers use other services. Not just services from competitors but also services that add value to their core offering. This can be a driver for acquisitions. With the rise in social media we would probably be wise to take into account how customers interact and respond with other consumers.

Actually I'm tempted to use Rob's own move from Microsoft to acceptance of the cloud as an example.

That darned paper clip did not turn Word into a service based solution, but it is IT type thinking; we layer a service element on top of the product rather than designing a product as an integral part of a service.

what do we mean by "IT"?

But is it possible that this is the essence of the IT/business divide? That longer term value chains such as the complete lifecycle of a customer, and the schemes to lengthen and broaden the activity in that lifecycle, are in fact and by definition "business" concerns?

I keep returning to the etymology here: Information Technology Service Management. The word "technology" has to anchor the conversation. Lots of discussions seem to have a subtext of "let's ignore that inconvenient word because it's geeky and business people don't like it, and it keeps us lower on the food chain."

The "technology" of "information" to me is not at all about computing architectures, Intel vs AMD or whatever. Instead, for me "information technology" very much centers on computing fundamentals like:

- first order predicate logic
- ACID theory
- Turing & von Neumann's work on computability & stored program architecture
- the role of information processing in the enterprise, pre-Turing, e.g. Babbage & all that preceded him back to the Mesopotamians.

And any discussion of "IT service" needs to be bounded by those fundamentals.

Recently I was asked on one of those silly "tell us about yourself" questions, "what 3 people would you like to spend time with, over all of history." I answered Turing, Deming, and Goldratt. Why were people so excited about seeing "Turing in hardware"? Willing to spend billions? And what does that fundamental excitement have to tell us today about the "value" of "services" platformed on "information technology"?

We all "know" the answers ... but do we? I think it's good to go back once in a while and look at the path that got us here, & reconsider whether we really do understand the journey we've been on...

PS "discreet" transactions imply things like banned substances or adult services... ;-)

Charles T. Betz

Not About IT...


While I appreciate and like your comments overall, I don't think that adjusting the focus to IT service buys us anything useful. I always will want to start with service management as a whole, as it provides the best context to understand what the customer intends and is trying to accomplish. In no way am I advocating abandoning or avoiding the discussion of technology. I just want to see us have a proper context for how to hold and discuss it.

I think you do an outstanding job of considering the fit of technology with service. From what I read, for most people, the connection between service management and IT service management is a tenuous one at best. When given the choice, those who don't have your background will go back to their preoccupation with the gizmos in ITs magic box and completely lose the plot.


Don't disagree

I don't disagree. Perhaps I'm just undergoing the same evolution in thinking that others such as yourself have already passed through.

So, "IT service management" is a dead end?

Charles T. Betz

basic voice

Surely every phone call is a transaction? How is basic voice excluded?

State changes

I guess I'm getting hung up on McGoveran's definition of transaction: controlled state change on a domain with business rules defining what "integrity" means. I can think of a couple ways to stretch that definition into telecomm (the "states" are either "connected" or "not connected") but it just doesn't feel quite the same. Yes, of course the *record* of the call is a transaction... but one doesn't need to have a record of the call in order for the call to have happened. One *needs* an authoritative record of a business transaction (if only cash in a drawer) for the transaction to even exist.

Charles T. Betz

What about inseparability?

The inseparability of production and consumption is another criteria frequently cited in the definition of "service," but has not been remarked on here. It's not quite the same thing as intangibility, which I agree is neither necessary nor sufficient... drop a cup of hot latte in your lap, it's pretty tangible, yet Starbucks figures more in books about services than in books about manufacturing.

Charles T. Betz

beyond "intangible and non-storable"

the inseparability is implicit in "non-storable" and can be explained in that context, keeping the definition simple.

If you want to go beyond "intangible and non-storable" then one of my favourite references, Haksever at al (2000), lists four properties :
Intangibility (acts, deeds or performances)
Inseparability (provision and consumption are inseparable "of most services")
perishability (I like "non-storable" better for reasons discussed above)
Variability (the outcome of the service is dependent on an interaction with a user and therefore every occurrence is potentially different as is every satisfaction)

Another of my favourites, USMBOK, lists these same four and attributes them to a 1993 study by Hartman and Lindgren. it also lists these attributes:
Lack of transportability
Labour intensive
Demand fluctuations
Buyer involvement
Client-based relationships

Both books also discuss other detailed aspects that distinguish services from goods.

USMBOK also discusses transaction-based services. It really is one of the most comprehensive descriptions of SM anywhere.

Riddle me this

So this evening I'm planning on streaming a movie from an active client (Amazon). I've two options.

(1) I can purchase a new movie, and have it available (service capacity and service output stored on Amazon servers) for a window of 7 days.

(2) I can purchase an older movie, and have it similarly available but for an indefinite period of time. I now own an intangible thing called a digital movie.

Are these both services? (Amazon would say no, for good reasons.)

Does the criteria of "storable" and "intangible" really help inform the decision?

simple and straightforward

Well I think so. To reiterate a product consists of a mix of service and goods, across a spectrum from no goods to no service. In this case the service is the transaction where you buy the movie. The goods you bought are the stored (right to the) movie. There is another service(s) where you consume the movie. I find that simple and straightforward but then that's me (I'm simple and straightforward).

Language is a model. Language is always an imperfect model of reality. There is always a fuzzy edge. But I don't see it here.

Definition of Service...


As you might imagine, I prefer the definition found in the USMBOK, as it addresses all of the items that have been discussed here (at least, in the past few days).

While recorded music (regardless of the media on which it is distributed) is more product-like than service-like, there are good examples of services that use the product to deliver a service.

It's also one of the reasons that one of the foundations of the USMBOK is (traditional) Product Management. The concepts found there are just as applicable to the management of services.

As far as music examples go, Pandora is my favorite... listening to it while I type this. I get the benefit of streaming content that I enjoy listening to (of use) without having to own the thousands of albums that it takes to get that mix of music -- and I get it all for one small annual feel. Customer value is high.

That's one of the reasons I think that steering off of customer value is absolutely essential when characterizing or defining services.



You mean the 100 word definition on page 20 of USMBOK? Hardly pithy.

"intangible and non-storable": People can understand it (with some explanation), remember it and most of all relate to it.

Uh, sure...

Pithy? Really? I didn't realize that this was a key consideration.

Now, there is a shorter definition that should requires no explanation:

Work performed by one group that benefits another.

[source: USMBOK Lexicon p.108]

It gets the gist without the gory detail, but the gory detail is important. After all, if there were a clean, consistent definition of what a service is, this entire thread would have been redundant, eh?


I like that. The

I like that.

The semanticists (the spell checker says that is a word) will say "work" is a bit narrow. But it is simple,sensible and practical.


The V3 service definition is a nice example of the Elvish I mentioned in the LinkedIn Call, event and incident -discussion.


Interesting paper

I don't know if any of you have seen this paper on the "total service experience" that was tweeted about recently.

Value in use through service experience http://www.huizenga.nova.edu/5017/ReadingList/sandstrom-2008-valueinuse.pdf

Quite interesting paper

The paper show how the thinking on services is evolving. As the writers warn, the model is untested theory but it feels ok. You do not buy a car, you buy the services and emotions the car will bring you. Maybe there should be an Emotions Management Process in ITIL 4 ;-)


perhaps an IT service is something performed by IT?

There are a great many services (deliverables) performed by IT that are not "transactions on technology." Most, however, do have a technology focus because technology is IT's raison d'être.

One of the things that causes me concern is the idea that IT services are only those services delivered to/for customers. It seems to me that all the deliverables performed by IT are IT services. Generally, what we focus on is the "prime contractor" view - those "services" that are delivered to customers. I believe that is a mistake.

I think we should identify all services within IT - prime contractor services or subcontractor services. We should define them, standardize them to the extent possible, measure their effectiveness, cost them, market them. Each business unit group will be required to behave like a small specialized professional services firm or a job shop manufacturer.

These "service products" can then be assembled for use by customer-facing demand management "prime contractor" teams. Or, they can be disaggregated in favor of externally sourced services if the individual internal business unit (say, network administration) cannot provide competitively priced services. What we'll see is that the individual functions within IT will have to demonstrate the wisdom of "buying" their services (making) instead of buying those services externally. The individual business unit manager will have to exercise entrepreneural skills.

We will, I think, with the Cloud and SaaS, see rapid change in the way we manage IT - we'll see a change from production to a design/final assembly shop where IT serves as the aggregator of services.

Cary King
Minerva Enterprises
Managing Partner

Not all services

Not all services directly add value to your customer. Many - epsceially (spelt wrong for emphasis) those that are pure technical services - exist only to help another service deliver.

Look at this way: A network is a service, right? Without one pretty much all of your applications and core services aren't going to work or do too much. What value does a network DIRECTLY provide to your customer? I posit that unless your customer speaks binary through an OSI swanney whistle then a customer can't use a network. It's the services that use that network that they care about. As the service provider I am interested in the network service because it affects the quality of the service that I can provide so of course I'm not saying a network isn't important at all. But we shouldn't expect the business to care about fun techie stuff just because we do.

It's that dumb quarter inch drill quote from the Service Strategy ITIL v3 book basically.

The other point I wanted to try and make is that while a service provider cannot tell a customer what value they must get from a service they must still understand how that service can provide value. It's the difference between painting a McGuffin green and telling customers that it provides value and painting a McGuffin green because you know that your military customer needs to have camaflarged equipment. Or something like that.

There's a capability model that I can't remember the name of because I lent a 'World Class Service Delivery' book to someone that describes levels of maturity going from Commodity to Partner. EQFN or something. It's late. I'll remember tomorrow morning. I fear that many of us still provide LAN connections and black (formally beige) boxes and monitors to people.

Time for bed... I'm going to look at this in the morning and laugh at myself

If it doesn't it isn't

"Not all services directly add value to your customer". Disagree. If it doesn't it isn't, by definition.

A network is not a service, it is a CI. Unless of course the customer is BUYING network as a service (NaaS - the IT Skeptic tries to stay buzzword-literate).

Well a network does add

Well a network does add value - just not directly. It doesn't mean it isn't a service. However it should be recognised that its an internal service that enables other services to provide value. Actually that's the key value that the network provides to yourself as the Service Provider.
Think public sector - not all customers BUY services.

EDIT: Oh and the thing you replied to was from me last night - I forgot to log in



It depends how far back you want to go into the supply chain, and the importance of the end product. For instance when you settle down with a glass of Dalwhinnie I'm sure you would argue that it is important to the experience that the water used to make it didn't come out of a tap in London. On the other hand do you care about the water used to make a fizzy drink?

Even in the public sector with internal IT departments customers "buy" services by making decisions on resource allocation.


Some cCmments


some comments to open the debate a little more.

IT Skeptic: "Not all services directly add value to your customer". Disagree. If it doesn't it isn't, by definition."

Internal services may add value - a lot of the time the customer does not know it, does not want to know, or is not aware of the value provided by the internal service and why should they. IT enables an organisation to work better, smarter, faster etc (granted if done correctly, but can offer the opposite if done badly)

IT Skeptic: "A network is not a service, it is a CI. Unless of course the customer is BUYING network as a service (NaaS - the IT Skeptic tries to stay buzzword-literate)."

A network is an IT system built from a collection of CI’s. It can be viewed as an IT service if service levels and targets apply e.g. guaranteed uptime, etc.

terminological debasement

Oh come on guys. Apparently everything that counts or controls is governance, or so it seems reading the web these days. Let's not go the same way with "service". A service is provided to a consumer. It is the end point, the objective. A service has SLA or can potentially have one (we haven't got around to it or don't need one).

An SLT is not an SLA. Just because a CI has an SLT against it - a single measurable contributing to an SLA - this does not make it a service. it makes it a service component, i.e. a CI. A CI can be composed of other CIs. An app is a CI. A network is a CI. A system is a CI.

Let's not start calling every reasonably complex aggregate of stuff a service, nor every CI we want to monitor or measure.

Depends upon your point of view

From the broad IT point of view, a service is provided to a consumer - what you viewing here as an outside of IT consumer. ITIL v3 is extremely vague in this regard.

Every internal group within IT is a small professional services firm or service provider firm that provides services to a consumer - albeit not, necessarily, an outside of IT consumer.

Better, I think, that we start to think of the "grand" services as service products delivered by the IT organization to outside consumers - where IT acts as the prime contractor or aggregator for the many and several services that they assemble as part of their agent role to deliver the service product.

wander into absurdity

As I mentioned above, the danger is that just about everything becomes a service and we'll wander into absurdity.

I think we need to restrict the term service to those relationships that are at least semi-formal: where a service is provided across an organisational boundary under the terms of an agreement. Otherwise we'll end up with the DBA providing a service to Application Support and service desk analysts providing a service to the SD manager

I was with you until the DBA

I was with you until the DBA example. The DBAs do provide a support to App Support - especially if there is an OLA. Even if not and the DBA sit about reading Wikipedia all day instead of testing a script or checking something that they are supposed to then the App Support guy is going to complain to the head of DBA support. Then you might end up with technical teams not trusting each other. I couldn't imagine an IT department like that... Oh wait... Too late.

A DBA counter-example

Environment: mixed control of IT funding between central IT service org & distributed IT capabilities owned & managed by business units.

An internal "database grid" with capacity on demand is deployed by the central IT service organization. App teams owned by the central IT services org use it. So do qualified business unit owned app teams.

Is it a service?

Charles T. Betz

perfectly cleanly

Any taxonomy or terminology is an abstraction. None reflects the real world perfectly cleanly.

i.e. there will always be grey areas

it's a service if the people paying for it say its a service.

its a service if there is a formal or semi-formal agreement with the customer

i.e. it might be, it might not :D

Hi, this is a good thread.


this is a good thread.

"it's a service if the people paying for it say its a service. "

I don't directly pay to use Amazon (or Lulu etc.) when ordering books from their site which is in fact a service provided to the customer. As a customer I will never refer to using the "Amazon book ordering service" but will refer to it as "Amazon or Lulu etc."

Now the cost of providing the service may be included in the price I pay for the book but this is all transparent to me, the customer.

Ok I am layers above IT here but isn't that where we should be when looking at services?

you don't buy books off Amazon

Hi Mark

two pedantic points:

the customer pays for the service. the user uses it. they are not always (often?) the same thing

you don't buy books off Amazon: you buy delivery of books. the service as a whole is to get a book to you. the actual transaction for the commodity "book" is between Amazon and the printer. so i see it the other way round: the service is not behind the book-product transaction, it is in front of it.

Cat amongst the pigeons

In this case they are the same thing, no?

The customer pays for services or goods or whatever they are buying from an organisation. They also may actually use the product or service that they buy or use the mechanism in which they deal with the selling organisation (as a user). - No?

I disagree in that as a customer I do buy the book from Amazon in the same way that I buy the book from a book store. It does not matter who they buy it from, that’s behind the scenes even if they buy it on my behalf and it never comes direct from Amazon. I have made an agreement with Amazon and I pay Amazon - I am Amazons customer.

Unless it is a super saver day (or whatever they call it) I get charged a separate delivery fee as well so I pay to use that delivery service. It just happens that their business model does not allow for me to pick up the book from them directly.

Amazon offers me as a user (or potential customer) an interface that I can use to browse and buy books
I become a customer of Amazon when I buy a book.

Anyway, back to the initial definition of a service. We should not just limit the subject of services to IT services but the challenge is for the IT organisation to think above the IT layer and for the organisation as a whole to understand how all this fits together

Clear guidance is required in this area (guidance that is lacking from ITIL v3).

ITIL constantly refers to IT services (I get pedantic regarding this point) as it IT services cannot exist in isolation - They serve, or should service a business or custoemr need.

Am I alone here in this line of thought?

Thinking above - NO! OUTSIDE OF the IT layer

ITIL V2 constantly reiterated that IT should be "aligned" with the business.


Where does one ever hear of a seperate department in an organization that needs to 'align' with the business.
"We need to get Accounting ALIGNED with the business" - HOW RIDICULOUS DOES THAT SOUND?

This is one of my biggest criticisms with ITIL. Nowadays IT is the business - it's time folks who worked in the other departments WAKE UP and understand that IT is a key component which helps to enable business processes in the organization.

In fact, I would support that IT becomes, along with other departments a key component of a Chain of Value - which are specific activities through which a firm can create a competitive advantage.

IT IS NOT the business

Can't let this stand...IT IS THE BUSINESS...NOT
.V2 said IT is the business to get IT folks to begin to think about how they fit in the business. Somewhere down the line, it became a way for IT professionals to say without us, you cannot run. IT is part of the business. But IT is the mule that pulls the wagon... V3 talks about integrating with the business...i.e it behooves us to show how our enabling processes and technology enable the business services to function.

Try saying IT is the Business to a senior business manager....You are going to get told to get back to the basement where you belong. Read Nicholas Carr, IT is becoming a commodity, as an IT professional, you need to prove your value. Otherwise you will be commoditized.

Take a look at corporatiion annual reports. All, (and I mean every project) balanced scorecard work I have done has had IT reporting into the financial quadrant of the corporate balanced scorecard. That has been for utility, government work, finance and industry. From a business point of view, IT is generally perceived as a cost overhead that needs to be managed. We are not the business, but without us the business would be slower. Much like without a car, its a long walk.

Back to what is a service... From an IT perspective it is what we do to enable the goals and objectives of the organization. V3, says ask the following questions to determine your value.

What is our business?
• Who is our customer?
• What does the customer value?
• Who depends on our services?
• How do they use our services?
• Why are these services valuable to the customer

Cobit says that business objectives should lead to a clear definition of IT’s own objectives (the IT goals), which in turn define the IT resources and capabilities (our services) required to successfully execute IT’s part of the enterprise’s strategy. For the customer to understand the IT goals and IT scorecard, all of these objectives and associated metrics (controls) should be expressed in business terms meaningful to the customer.

Point Taken

Excellent comments. Thanks.

I was wondering who would stand up and shout at my comment.

(Maybe I should have just said 'IT IS PART OF THE BUSINESS' - but I don't think this would have initiated any feedback)

I agree that IT must have effective process integration with the overall processes of the organization. IT just seems a little too obvious to me.........


Once again I'm going with both sides of this one (egad I must be getting old! Age and guile beat youth and a bad haircut).

IT is as essential to many businesses as manufacturing is. In fact IT is the core "manufacturing" for some: no bank can go back to manual ledgers today. In that case it is not too far off mark to say "IT is the business". Any bank, finance or insurance company that treats IT as a cost centre reporting into finance gets what they deserve (and I saw a few banks get what they deserved a decade ago).

On the other hand IT is still so far away from having any real credibility at the top table in the majority of organisations that claiming to "be the business" would indeed be met with scorn and derision.

ideally yes we should only consider services at a business level and treat them holistically in an integrated manner, with IT seamlessly forming a value-adding part of it. In reality we are a decade or more away from that happening except in a few visionary firms. IT remains a distinct boiler-room doing what they know in a separate building.


Interesting as well that the Amazon service isn't better or worse than a book shop, it is a different service. If you were a customer used to a book shop would you chose to specify the Amazon service, or do we only chose to use it because it has been offered to us?

This is the challenge

The typical siloed IT organization is faced with this challenge :the IT department's view of the service is from the inside where all the bits and pieces are configured, connected and managed to come up with what's needed.

The customer has a unique position - experiencing the service without the cloud and confusion of all the bits and pieces.

Knowing what ITIL V3 refers to as 'Utility' and 'Warranty' is the challenge faced by many IT departments. Partly because of the complexity - there are many bits and pieces which going into making up the service.

A good place to start is with what the customer's perception of the service is - and further defining the Utility and Warranty that makes up the service.

I agree with that. There is

I agree with that. There is a challenge within IT in regards to their view of a service and the view from the customers perspective.

"Partly because of the complexity - there are many bits and pieces which going into making up the service."

It is because of this that services need to be further understood and defined in relation to the organisation as a whole rather than just within IT. Going back to a pervious comment - this may be aspirational, especially within the IT view of the world, but it is something that is worth striving towards.

What about the role of Business Processes ...?

I tend to use a structure like :-

Business Service(s) - Something the business/organisation offers its customers/clients for which a contract [implied] exists.
Business Process(es) - How each specific Business Service is delivered which can be nested, shared and reused.
IT Service(s) - Something IT/3rd-party offers its business customer to enable a specific Business Process for which a SLA exists.
IT System(s) - Related multiple ICT that IT/3rd-party manages to deliver all or part of an IT Service for which an OLA or UC exists.
IT Component(s) - Single ICT that IT/3rd-party manages in combination to deliver IT Systems for which an OLA [implied] exists.

From that

Service Catalogue - Business Service + Business Process(es) + IT Service(s) + SLA(s)
System Catalogue - IT Service + IT Component(s) + OLA(s) + UC(s)

Dave Schofield

I agree - but I do think we

I agree - but I do think we need to have a few basic but specific classifications of services - not everything is an IT service. Granted the majority of consumer services may be enabled by IT services.

"If we can ignore that real-world intrusion into the idealised total service provider model we can come up with a slightly more precise definition that still does not become too waffly: An IT service is the offering and/or consumption of a type of transaction running on technology."

Sure I can buy that. But here we go again - IT talking about IT services and defining things in relation to IT. ITIL falls foul of the same thing refering all the time about IT services. Do we foget that all IT does is to enable a business to work better etc. (if done corectly) so IT services enable something else - dare I suggest business services or customer services i.e. as seen through the eyes of the comsumer.

Yes - the service world does not need to go the "governance" route (a phrase often misused - which you have blogged about as well).


Hi Mark

If IT is the service provider - if Service Delivery is housed within IT - then it is only natural to talk about IT services. On that fine day when the business operates Service Delivery and IT is just delivering to the OLAs, THEN we can talk about business services

Service from a Customer Perspective

Need to think about the supply chain in this discussion.

If I want to rent a car online, the service I want as a consumer is a car available when I land. Preferably clean, well maintained and fully fueled. I dont care how many cars they have, how the web interfaced with the inventory, which device or appliances connected my pc to their web site... I want a car.

However to build an appropriate cost model, we need to identify all the elements in the supply chain used to provide this access point to a service. And you know that the Car rental agency does not give a fig about how the information is provided... So Service Managers may need to build internal SLA's or SLR's, even an SLT. This quantifies what can be acheived / delivered / expected. Now an IT manager can begin to identify the priorities and allocated resources and expenses accordingly.

IT is an enabler, we enable our business colleagues. We need to map how we deliver to their core services...IE this switch array is part of the online car rental reservation service. But beofre we can do this, we need to have an idea of how the infrastructure fits together to enable all the services used by the customer.

SImple categories for business services... Not a definitive list...buts makes a good menu. (Customer Facing)
Telephony , Email, Billing, Printing, Ar /AP, Marketing, Sales, Web Page, tell your partners how you work to delvier these things, now they begin to understand your value.

Internal services to enable the business. (also not definitive)..lets call it the cook book. (technical Catalogue)
e-print, email, network, app development (If you build things) App support, desktop mgmt, desktop support, MS Office support, Service Desk, security, anti virus, architecture, DRP.

You need to get the recipe right to deliver what they need....and NO ONE CARES about how hard it is for you to deliver what they need.

Precisely. Supply chain.

Charles Betz has done some nice work on this.

Consider organizing the database around UNSPSC - just like the "real" supply-chain world does.

Cary King

More simply...

You presume the supplier will clean and check a car before assigning it to you?

All relative

It depends doesn't it? Today's innovative explicit customer facing value adding service tends over time to be fade into a background overhead enabling service. In an ideal world I would like all my SLAs and contracts to be in terms of capabilities but that isn't alsways possible (especially if either the supplier or customer are not that ITSMmature)

If we are talking an internal network we could query if there neeeds to be a business owner, or can it be left entirely to IT

Cost and value


Agree, we need to understand our internal services, including supplier management, the full cost of providing those services, and the value they deliver both to the customer and , if we are a commercial provider, the value they deliver to ourselves. We also need to understand how value and costs flow between services. In a silo world value can end up trapped in a dead end and not get realised or leveraged.


Value is a tough conversation


It appears to me that Value is a very much tougher conversation. One with which I'm hesitant to engage. In the late 80's I was the Finance Manager of a more than 1,500 person IT business unit of a Defense Contractor - everything was charged back, every investment decision scrutinized by the contract officers. What is now called portfolio management was extremely disciplined then.

My problem of discussing value is that I've always thought that all revenue comes from sources external to the company, and therefore all company activities are costs. Parsing how those revenues relate to value of any particular function is a challenge. The "revenue" of IT comes outside of IT, from the amount of budget the other departments are willing to part with to support IT activities. The "value" of most functions is an internal customer satisficing activity.

It seems to me that the measurement of value is something the customer does, not the producer. I'm shopping for a new car. I note that the BMW and Mercedes sales guys are very clear about the costs. They are also very thorough about what the features of the cars are. They do not, however, attempt to tell me the value. They leave me to decide that for myself. My perception of value must be based upon my own desires for outcomes. If the salesman tried to tell me the value of the BMW 550i, I would be offended.

In the same way, it appears that IT will have a challenge telling customers the "value" of their services. Particularly the value of "subcontract" services - services delivered from one IT function to another, which is rather like BMW telling me the "value" (not the cost) - would be rather like them telling me the value of the brakes. IT provides absolutely necessary services. Services that make other functions throughout the company more efficient, and in some cases are essential to their existence. Few, if any, of those services add strategic revenue-generation capabilities.

Most companies don't charge back for IT. Lacking chargeback they allow IT to be viewed as an all-you-can-eat buffet where there is an overall satisfaction/dissatisfaction. Without chargeback, or an organized budget that the "business" can control and choose to "buy" services - IT bares itself open to arbitrary outside controls - "do more with less." Decidedly passive-aggressive. It's as though Moore's Law applies to software development and maintenance and not just hardware.

At this time, I conceive that we should stick to the cost discussion - but get very specific about the costs as they apply to specific services. let's discuss the "features" of our services - and market them a la BMW and Mercedes. Let's let our "customers" decide the value of our services - and, buy them at a price. Instead of a buffet, let's do automat.


Commercial world


I'm usually hesitant to talk about internal value myself, not least because having spent too long amongst economists I know the arguments it can lead too. Having said that I find a MaxDiff type approach can at least provide a ranking.

Because of my focus on improving IT contracts most of my clients are either retained organistaions in an intelligent customer role, or they are outsourcers. In both cases the quality of their internal processes can have indirect impact on their long term position and survival, so has value to them, even if it isn't directly charged to customer. Even though the customer might not consume the service they still makes judgements about capability based on the suppliers ability to deliver it to other customers, or to provide the service to them at a later date.

BMW and Mercedes don't tell you about their costs, only what it will cost you., which is to say the value they place on it in the market. Both have big F1 programmes (at least they do as I write this) which don't have a direct impact on the value of the car in the show room. I can't go in and expect 10% knocked off the price because I'm not interested in F1. But they only compete in F1 in order to increase my appreciation of the value of their product, and to feed into development work that will eventually improve the product. Whether F1 adds value to their market position is a question of internal value to the company.

In an internal IT provider the issue is perhaps less clear.

F1 - good point

I believe your F1 program issue actually enhances my point.

As a customer you don't care about their F1 program. But, they would argue that they use F1 as both a marketing tool and a development tool. Like the technology throw-off from the American Space Program (Tang and whatever else), they use F1 for development of technologies that may find their way into the cars of the future.

Full disclosure: I worked in Product Management at a couple of the big ITSAM vendors.

An IT Service Product Manager may also have development work to do that will, eventually, get folded into the service product. The idea that everything is linear, as some project management zealots would have you believe, is untrue.

Working to hear the voice of the customer and translate their needs into a workable system takes experimentation. Else one choose satisficing as a decision strategy instead of optimization.

All that effort would get translated into the price of the system to the customer - that's what gets charged back. And, by charging back the customer gets to decide their own priorities based upon their budget and needs - they "spend" their budget their way. I don't know of anything more flexible and more "aligned" with the customer.

That is different, however, from BMW knowing the labor and material costs of each part. BMW would never show a customer this information. Yet, by not providing a "price" for the main service IT offers its customers, don't we invite the business people to come examine our "books" to satisfy themselves that we're doing a good job. Don't we invite them in to scrutinize and micro-manage?

Cary King

Crossed wires


I think we might have got wires crossed, my initial point was that an IT department needs to undertsand how it's internal processes add value to it's activities, not that it has to make that value explicit to the customer (though the customer might be interested). on that basis aren't we in full agreement?


Full Agreement.

If IT is to run "like a business" then, just as any other well-run business, IT must understand which processes are value add and which aren't.
If we treat the "services" we offer to customers as products, we need to understand the value and cost of every component product (or service). The service product manager (prime contractor, or aggregator) will have to know how to put the piece parts together to produce the service.

We will also need to do a make/buy decision on each of these - so each internal IT business group needs to start acting like an entrepreneurial professional services firm or service provider. We'll all need to structure our services as do external competition and, where we add value, be explicit about those product features. One of the challenges will be, of course, costing the services on a service product or deliverables basis.

A challenge for most is that business units use each others' services - washing out the overhead distortion can be tough if you don't know which service is using which other service and the common overhead structure.

Another challenge is removing the "corporate overhead" from the equation. There are always corporate charity meetings, required corporate pep rallies, etc. that the competitors don't have to do - the cost of that "corporate" time waste pit must be removed from the make/buy decision and charged elsewhere.

Best to take a lesson from the manufacturing side of the house - start measuring the right things.

Cary King


I know ABC, like so many good ideas, is out of date, but I found it, and target costing, really useful in these situations.

combining services might not be as easy as an additive menu. because doing x makes y easier to achieve, We buy a portfolio of solutions, and I guess we need a risk based approach to overheads*


* there is at least a PhD and probably a HBR article hidden in that statement!

Isn't Value another name for Benefit ...

which is a pretty common way of presenting your business offering, e.g. Features & Benefits, Costs & Benefits?

Interestingly saw this article (http://www.computing.co.uk/computing/comment/2242085/getting-clever-half-4657476) today which seems to fall into the same trap of positioning IT as just about cost reduction, which it can be of course but that's only a small part of the story.

If my local BMW, Mercedes or Audi dealer didn't talk about 'lifestyle benefits' I'd think they did not understand their own brand even if I don't believe a word of it!


Dave Schofield


Mercedes used to have the strap line "Not so much a motor car, more a way of life"

I like to think of business

I like to think of business services not IT services. The IT service is whatever it helps the business to do.
The other awkward bit with tying this to technology so much is IT training and advice can be a service without requiring technology. Even if it's advice on how to use technology.

Service is what servants provide?

Actually Service Strategy does provide some rather useful discussion about the differences between IT and Business services, with some diagrams.

What you describe sounds very like an IT Service.

I like this example:

Email is an IT Service. It does something for users that's supported by IT/ICT technology

Invoicing is a Business Service. If you send your invoices through e-mail, then your business service is being supported by the above IT Service.

What I like about this one is that the 'Invoicing Service' is not what IT would label as the General Ledger 'Invoicing Service' provided by their ERP system, that's another IT Service, or collection of IT Services.

The actual Business 'Invoicing Service' includes these services (at least):

- Audit Services
- Bank Services - deposits, reports and so forth
- Credit Rating Services
- Debt recovery services
- Fax Service
- IT Services (as above)
- Legal Services
- Postal Service
- Tax Office Services - VAT advice etc.

And so forth. So, when an IT 'Service Manager' comes to the Financial Director, CFO or similar and starts talking about the 'Invoicing Service', you can understand why they're a bit bemused.

This is a good example for teaching too, because some naive IT types have difficulty understanding what is meant by a 'Business Service' or aligning to the Business.

This is what the Hitchhicker's Guide says

Service is something you can sell or buy but not drop on your toes.

Two tiers

We now have a combination I think of the commodity service and the value adding service, with the emphasis shifting towards the commodity model.

Commodity service (I'm avoiding the term utility because as we know ITIL v3 uses that for something specific) is highly repeatable and relatively easy to specify. My broadband connection is a commodity service. There is probably a tendency for charging to shift away from the per transaction model. To the customer these can often be seen as overhead costs.

Value adding services are differentiated from each other, indeed their value can be derived from that differentiation in terms of competitive value.

When I buy the service I don't buy the means to replicate the service for myself, purchase of a service is always a revenue cost not a capital cost.

My ears were burning...

My ears were burning - the length of this thread is testament to why we in IT should be very careful about abandoning ITSM and embracing BSM. Thank you - all of you who are trying to apply the USMBOK. As an ex product manager I just had to revert to type and teaching when confounded by the ludicrous definitions of a service bandied about by IT folks and expert consultants. Once and for all - THINK CUSTOMER FIRST when trying to define a service. Also - as Ken says - place it in context - IT Service. This helps.

Then remember - as many tried to emphasize here - its work performed by one for another - a transaction that has legal standing. Check out your national or State statutes - its well defined. Then - think successful customer outcomes - or desired results of your customers. A service is a type of product. As for type - the classification spans a continuum not a spectrum - sorry - ranging from pure goods (tin of beans) to a service (lawyer, doctor, accountant?). The job of the product manager (service manager) is to understand how much human resource to include to meet the needs of the customer.

So simple. yet we struggle so much - why?

Just for fun - therefore an IT Service Manager (ITIL included) should know how to design a service, with just enough human resource and service support, to satisfy a customer. So why is this not taught!

Everyone - this is exactly what our industry should be discussing at conferences - before we talk about software, processes, maturity levels and the like. Thats all inside out thinking and as I have said all too often of late - a recipe for failing the customer. And this - was exactly why I wrote the USMBOK from a non-IT perspective as it helps us all understand that the reason we buy an expensive Dyson vacuum cleaner is the same as why we pay for certain IT services... there is a result in there somewhere.

Skep - please download latest ebook version - it has outside in service management updates that will help... you can get it here:


Syndicate content