HelpAboutBlogBOKKEDPodcastsTopicsWizardLinksBooks

Skep's Pick: The IT Skeptic Awards for 2008 This link is here because...(hover)

What is a service?

in

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.

Comments

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

This is what the Hitchhicker's Guide says

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

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.

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.

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.

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
www.MinervaE.com

Cost and value

Cary,

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.

James

Value is a tough conversation

James,

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.

Cary

Commercial world

Cary,

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.

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!

Regards

Dave Schofield

Mercedes

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

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

Cary,

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?

Yup.

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

ABC

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*

J

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

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

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

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

Buying

Chris,

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.

J

Some cCmments

Hi,

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

Comment:
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)."

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

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

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.

More simply...

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

Precisely. Supply chain.

Charles Betz has done some nice work on this.
http://erp4it.typepad.com/erp4it/2006/04/here_is_a_simpl.html

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

Cary King

relativity

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

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.

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

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
http://www.erp4it.com

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.

Hi,

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?

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.

Amazon

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?

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.

IT IS 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

Glen,
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.........

boiler-room

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.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Syndicate content

Buy your books here to support this blog: