Who is the customer?
It is important to distinguish between customers and users, as ITIL does. Confusing the two leads to problems.
We often use retail as an analogy for IT, "serving the customers". But retail is quite different; the user is the paying customer. IT is more often like government services: the paying customer is distinct from the user, and has different measures of success of the service.
ITIL is careful to distinguish between customer (who pays) and user (who consumes). This is why restaurant and hotel analogies fail/mislead
I've had this discussion with conference organising committees in the past: the real customers are the sponsors and exhibitors. Attendees are part of the product, the transaction.
I've seen it lately in airports: the real customers are the airlines and franchisees. Passengers are the transaction. Oh sure they need to make the experience pleasant, but why are there so few sitting areas, so unattractive, with no power outlets? Because they want you sitting in restarurants or walking around the shops.
There are plenty of examples in IT where the paying customer cares little about the standard of service to the end user, at least compared to how much the end user cares about the standard of service to the end user. Often we want to do our best for the users but the customer simply isn't paying for it. Even if the users NEED it to perform their roles. Take for example a hospital that refuses to pay for 24x7 IT service desk (I know two).
Overservicing the users is a recipe for going broke. It feels good but it blows the budget. We can only do as much as the customer agrees to fund. When Operations talks to the users every day and seldom to the customers it's easy to forget what the constraints are.
If I see another analogy comparing IT services to a restaurant I'm going to throw up. The only valid analogy would be a Soviet state food hall, where the user isn't paying for the meal. And we can imagine what those meals were like. Explains a lot doesn't it?
So always check: who is the customer? Who pays the piper?
Made in New Zealand 
Comments
giddy
The airport model of customer/user may be changing, or at least maybe they are realising that treating the users like shit doesn't make them stay and spend. Ottawa Airport hit me with a check-in guy and a security guy who set new benchmarks in friendliness and helpfulness; US gates separate from other destinations so we don't all have to put up with TSA rules; clean toilets; a cup of tea for $1.73; free Wifi with no password; AND powerpoints in the seats in the public waiting area.
I feel giddy.
Parents and Children
I got tired of the Restaurant analogy long ago.
I see customers as parents and users as children. Parents (customers) have the decision power. They understand the long term plans of the family (organisation) and make decisions based on family needs and budgets. They are of course very influenced by their children and often marketers will target the children directly in order to influence the buying decisions of the parents (customers).
Children (users) have a very immediate need fulfilling focus. They don't usually care much about next year or even next month. They don't really consider the needs of anyone else but themselves..... it is not wrong, it is just where they are at.... Long story short, if you allow the kids to go grocery shopping you'll usually end up with a lot of nice to have now but nothing in terms of what could keep the family alive the whole month.
Using this analogy, you'll see how critical it is to negotiate SLAs with the customers (parents). It may not be exactly what the users (kids) want but it may simply be because the users don't understand where the organisation is moving towards or the budget constraints that need to be taken into consideration.
Users focus on now, and will usually put a performance up if they can't get what they want. Trying to please every user is like trying to please every need of a child.....and yes, you guessed it, you end up creating naughty, screaming brats. Allowing the users to dictate what level of service IT should be delivering will usually end up with a lot of nice to have now but nothing in terms of what could keep the organisation running profitably.
Making sure that the users (kids) understand the decisions that have been made by the customers (parents) is however another important aspect, as they (kids) tend to thrive under rules (routine) more than anything else. Setting the boundaries so to speak.
It is important for us as a service provider to understand both the needs of the users (kids) and the customers (parents), and make sure that we help the parents with understanding what their kids are looking for. We can use the "children" to influence the "parents" but ultimately it is the parents who decide - no matter how much the children sulk.... :-)
Once you start using this analogy you can go on forever! So enjoy!
IT as caterer
Skep,
I see your point as this: there is an inherent disconnect when the consumer/user is a separate entity from the customer/payer. I agree that the restaurant analogy is at least insufficient, and is often misleading. I blogged about this (http://bit.ly/lH48mG), and proposed a slight alteration to the SERVQUAL model that can be used as a measure of service quality. The traditional SERVQUAL model assumes that the consumer and customer are one in the same, but this is simply not the case in many technology contexts. My altered model makes us address the gap between the paying customer's expectations and requesting consumer's expectations. I didn't distinguish the terms customer and consumer the way Skeptic does here. I think I'll update my version of the model to account for the three actors in the transaction: The Customer, The Consumer, and The Service Provider.
Ultimately, I think the better analogy is that of IT as caterer. The customer reviews the menu of possible offerings, along with the associated costs, and chooses what should be offered to the consumer. The consumer, then, reviews the services laid out for them on the buffet table, and decides what items to consume. Some of the items are "ready to serve", so the consumer can just pick them up off the buffet table. Other items are "made to order", but within a limited scope of options, like a laptop computer. Think of the made-to-order omelet station in a buffet line. There are still a limited number of possible ingredients the consumer may choose from. It's clear for the consumer to see that the omelet/laptop is not something they just pick up off the table, because it's being built for them. Of course, this implies the same transparency in both the omelet and laptop contexts.
In the catering analogy, the consumer usually knows there is a difference between the service provider and the person who chose what options to make available. All too often, there is no distinction in the corporate context. Or. even worse, the paying customer works with the consumer to set expectations, but never asks the service provider/caterer to determine the costs of meeting those expectations, much less even sharing the expectations themselves. The service provider is left to meet consumer expectations as best they can, within cost constraints that have no correlation to the expectations. The caterer is serving meatloaf and mashed potatoes with nothing made to order, while the consumer was expecting a choice between ribeye, filet mignon, and Alaskan salmon -- all made to order.
Now corporate IT tends to look at this as something they have no control over. "They didn't tell us what they wanted!" or, "management should communicate better with the line level, to not set us up to fail". Yes, the corporate customer does have responsibility; AND we in IT need to be proactive in identifying the expectations gaps and offering solutions to those gaps. The solution to a given gap may be to simply communicate that the gap cannot be met and change the consumer's expectations.
IT Pizza
One of the themes many of us keep coming back to is
"What would happen if IT people ran a pizza parlour.
http://www.youtube.com/watch?v=OV7SXmHq0Bk
James Finister
www.tcs.com
http://coreitsm.blogspot.com/
interesting
An interesting discussion.
First, it appears to me that Skeptic is right, there is some confusion about what is a customer vs. a user. I tend to think of customers as the economic buyer and the users as the third-party beneficiaries of the economic buyer’s transactions. I would argue, however, that since users are 3PBs they too are customers because the economic buyer is purchasing those services for those users. Just as when you buy services for family members – you are the economic buyer, but your family is, indeed, to be considered a customer.
As to the discussion of what is a service or not, that’s also quite interesting. ITIL has some fuzzy thinking, which is, no doubt, a challenge for those that teach it. I don’t teach it, I help customers implement solutions – so my view may not align with ITIL at all.
The way I see it, everyone is providing a service. Tom Peters calls it branding and says the Professional Services Firm (PSF) is everything. Robert Louis Stevenson wrote that, “Everyone lives by selling something.”
We sell services, our own individual services, often measured in time units, to our employers. In my case, I try to sell services as results. We are all selling something. Each individual has to show value.
We often sell those individual services to a business unit. Perhaps, since that is an example already in play, to Database Administration. That DBA team “business unit” “sells” services – often priced as time - what ITIL refers to as supporting services. That “business unit” has customers – perhaps other supporting services or a core service, or both. DBA services can (I would argue should) be modular, and loosely coupled from other services. DBA services can be purchased externally, perhaps from an external PSF. Those services can be described in a catalog, can be standardized, can be pre-planned (with WBS, BOMs, work orders, DFSS, etc.) and can be formatted to be competitive with externally acquirable services. The time sold can be tracked and an “invoice” can be prepared.
Business Unit managers manage their resources to fit the demand for their services. Advantages include matching resources with demand, managing business units by skillset to make sure that skills are appropriate to services to be “sold.” Alignment - solved.
The question here is whether you want to describe those services as ITIL services and offer those services to IT’s economic buyer customers. Probably not. It seems to me that’s a matter of ITIL definition of a service.
It seems to me that instead of organizing IT around functions that perform ITIL processes, it may be better to organize and budget IT around service “business units” – PSFs, or infrastructure services. Modular, loosely coupled.
What IT “sells” as services in the IT customer-facing, perhaps self-service catalog then would be services that are arranged by Service (Product) Managers acting as Prime Contractors to assemble and deliver services from the needed variety of subcontracted services (supporting services from internal, or external PSFs, cloud, outsourcers, etc.).
Decisions about whether to “buy” the service internally or buy it externally then become the Service Manager’s analysis issue – depending on all the factors of cost, quality, security, stability risk, etc.
Economic buyers (customers) “buy” the prime services based upon annually arranged budgets based upon demand.
Isn’t running IT as a business-within-a-business what service-based management is all about?
The reality differs
Cary,
The idea of DBA as a service is attractive on the surface, but in reality often leads to confusion without delivering benefit.
As well as customers and users we also have the term stakeholders to play with. I would personally only include family members in within the customer group if they were actively involved in the purchasing decisions and also made some material, though possibly indirect,contribution to the purchase . so my family only pass one of the tests ;-)
I'm not sure that everyone is producing a service as such - or that it is always useful to think in those terms. Most people are producing something that is somewhere on the product-service continuum rather than at either extreme. Even if they are, then not all services are equal. What I need to deliver an acceptable service if I am delivering a commodity service is not the same as what I need to deliver a bespoke service.
The thing with the DBA is actually it is extremely rare for them to effectively sell their services, and they are not competing in a market or quasi-market. That affects the whole relationship between supplier and consumer - and yes I have changed the terminology to avoid use of the term customer in that example. Now there is nothing to stop you thinking about DBA as a service, but the question to ask is what value is added in return for the overhead of treating it as a service? Now if you decide to open up sourcing the DBA service from either an external supplier or an internal team in competition with external suppliers then it is a different matter. What I'm not so sure of at the moment is whether an aggregation of such services equates to the service delivered to the end-customer. As a supplier I would argue that my "below the water line" activity is my concern, and not the customers provided I can provide the customer with a degree of assurance and an auditable risk/benefits model
These days I'm suspicious of any attempt to organize around a single concept, be it processes, "Centers of Excellence" or whatever. What I agree is some function/role that pulls together the big picture is needed, which is why at TCS I've spent the last twelve months building our Service Integration model, and loose coupling is quite a good description of how that model works.
I'm not sure that "running IT as a business-within-a-business what service-based management is all about", I suspect that that is either a means to an end, or a necessary/desirable side effect of doing service-based management. Generally speaking an IT department that takes that approach should be expected to do a better job.
James Finister
www.tcs.com
http://coreitsm.blogspot.com/
below the water line
Very little about what IT does is a product. Even when we deliver a product - a PC, for instance - there is usually a lot of service component with it.
DBAs sell their services all the time - there are whole staffing and consulting firms marketing those services. Most IT shops have outside hired workers that are not employees - that's selling their services, by the hour.
What IT "sells" in its catalog is different from the services it "buys" to make up its services. It would be rare indeed for an IT organization to "sell" DBA services directly. Most often they would be bound up as part of the bigger core service. This is similar to buying compute power from the cloud, as part of my service - but offering the whole service.
One can outsource the Service Desk service, or outsource the Service Desk tool, or keep it in house, or keep partially staff it with outsourced staff services - or any combination. When you hire staff, or hire outsourced individuals - you are "buying" their service, are you not?
James, you write, "As a supplier I would argue that my "below the water line" activity is my concern, and not the customers provided I can provide the customer with a degree of assurance and an auditable risk/benefits model."
Just so. If you can demonstrate that the component parts of the service you provide are, in fact, value-priced.
What I'm suggesting is just what manufacturing companies have done for years. There are Product Managers (Service Managers), that "buy" R&D, "buy" ops, "buy" distribution, "buy" marketing, and "buy" sales force. They "buy" IT support, and accounting and facilities, etc. Essentially, they assemble the product or service.
Many industries have minimal ongoing staff - and subcontract out the rest.
IT does that in large part now - how much of IT is already "bought" as outsourced services, temporary employees, print services, telecom services, etc? 30% of the budget?
An example? The County in which I live has a $700m IT budget. Less than 20 people administer it. The rest is outsourced.
Want more? I sat next to a CIO at a meeting a few weeks ago. His CEO had set him the task of outsourcing down to 10 people to administer it.
It seems to me that we would be better served to acknowledge what we're already doing. That we organize around it with modular, loosely-coupled services from the beginning - instead of highly-integrated, tightly-coupled processes (and, so does ITIL in the Service Strategy book). Understand the overhead structure, understand the actual recoverable costs should we outsource a group. Doing so will cause less disruption as we move through evidence-based make/buy decisions. Doing so will help us show value to our customers.
What a business, or IT, offers to its customers is way different from what components it purchases. Having worked as the IT Financial Manager for a 1.,800 person IT division of an aerospace contractor - I can tell you that customers (Navy and Air Force) pretty much want proof that you're providing reasonably priced components.
Our internal customers want to know (that means we have to prove) that we (IT) are acting as responsible stewards of their investment, that we are acting with systematic due diligence as their agents. My experience is that transparent pricing of the underlying services - labor - and comparisons to other services that can be purchased, is the only way to get the trust of the rest of the business. They trust us, but, occasionally would like verification. When we obscure the costs and services - how can they trust us?
Consolidation and Virtualization is just the start, Cloud, Outsourcing - a continuum that requires us to rethink and plan for managing IT resources in a whole new way.
If you're a type III organization that sells those services - great, all that ITIL, SMBOK, ISO 20k, ISO 9k, etc. - is going to be even more important because that's how your customers will measure you.
If you're a normal company that provides IT services to internal customers - don't you have to organize around supplier management, contract management, asset management, financial management and procurement of these services in a much more aggressive way?
Benefit benefit benefit
Cary
The most important think to listen to in what I've said so far, in what I think is a very important debate, is that we should only treat below the waterline activity as a service if benefit is derived from doing so. That benefit could be the IT department, it could be for a supplier or it could be for our customers and users.
Because treating activity/process/function/capability/technology as a service has a cost, that cost has to be justified. And just re-read that sentence again, because it reveals another dimension to my concern. when I say I'm seeing people treat everything as a service I mean I'm seeing people treat all those components - activity/process/function/capability/technology - as services at the same time. So our DBA service is layered with the service delivered by the DBA team, the infrastructure service, the application service, the capacity management of the the dbase...etc etc. Oh, and then all those services are themselves layered on other services, and then you have to define the interfaces, the users, the customer, the service owner.....
Now in a perfect world that actually appeals to me, but to the pragmatist in me it is a recipie for wasting vast amounts of time and effort for no benefit. Like much of ITSM I suspect the people who benefit most form doing it lack the maturity and capability to do, whilst those who have the maturity and capability to do so would gain little form doing so.
Is very little we do in IT a product? With my contract management hat on that can give rise to some interesting legal issues, for instance in some legal systems contract law around services differs substantially form how contract law handles products. If I buy a copy of Sage is that really analogous to me buying the services of an accountant? However attractive the "I want a hole, not a drill" image is, the truth remains that Black & Decker sell drills, not holes.
The different ways of providing DBA capability you mention are just that - different! If you employ TCS to provide the service you can hold us responsible for different kinds of things than you can an aggregation of individual contractors. It would probably make sense for us to have a team of service managers managing the DBA service we deliver to a customer, and if you looked at that time it would roughly resemble your customer facing service management capability - but that's only because it is useful to do it that way. You might be buying in another service which is such a commodity item that you'll never have any contact with a human being in the supplier's company, and the only negotiation of service levels you'll be able to do is deciding whether nor not to rip open the envelope with the licence inside.
As an aside the manufacturing analogy is one I've often used myself, but the more I get involved with integrating IT in manufacturing environments the more I question the validity of it as a deep metaphor. IT doesn't make cars. We don't bolt together parts, we don't have a production line. One of the failures inherent in the early years if ITIL, which I don't think any of us realised at the time, was that it encouraged us to think that everything is a process. It isn't, and thankfully v3 has started to address that.
Large scale outsourcing has been the norm in the UK for many years, so you don't need to sell me on the idea, regardelss of the fact it what I do for a day job. And I've frequently been on the other side of the fence managing outsourcers as a customer .The role of the retained organisation is clearly that of bring together the elements to provide a service to the customer, and clearly everyone in the value network has a contribution to that, but it doesn't mean we should end up with
"(As) nat'ralists observe, a flea
Hath smaller fleas that on him prey,
And these have smaller fleas that bite 'em,
And so proceed ad infinitum."
In fact one of the service that the big outsourcing companies, like ourselves and IBM now supply is the management of all the other suppliers in the value network on behalf of the retained organisation, allowing them to focus on the definition of business focused service levels whilst we manage the technical service levels, freeing the other suppliers up to do what they do best.
I'm absolutely with you on the loose coupling, as I've said before, and on the transparency front. But being pragmatic again the sad truth is that most IT departments aren't mature enough to produce a robust cost model, and certainly not one that can be used to model anything other than the steady state. The visibility of costs, and resultant ability to manage them, has been cited on several occasions as a reason to move to an outsourcing model. To return to my original point about the DBA as service - how easy would it be for an internal IT department to cost model the DBA service with any degree of accuracy?
As for your last three statements - Absolutely yes to all of them.
- We need to rethink how we provide IT so it can cope with de-stabalising changes in the delivery model
- The detail side of ITSM will increasingly be the preserve of IT companies, not internal IT departments
- The retained IT organisation has to focus on the capabilities and processes for managing suppliers and customers
Bring ion the next response ....
James Finister
www.tcs.com
http://coreitsm.blogspot.com/
DBA services & other thoughts
Funny, as I was reading this thread mixed in with other stuff on Google Reader up pops commentary on the new Amazon/Oracle service...
http://www.constellationrg.com/20154/oracle-on-amazon-think-again/
Not quite a "DBA" per se, but still apropos...
I think in general that there is a quest for illusory certainty in this debate. All have good points, at the extremes. "Fractal within limits" is how some colleagues and I are leaning towards describing the problem.
As I look at the debate, I think that there are a finite number of dimensions that characterize the problem:
1. Size/cost of the service
2. Relationship of provider and customer
-a. Different legal entities
-b. Different legal entities in a long term binding framework (e.g. holding company)
-c. Same legal entity, but EVP-level separation (traditional shared services/ops organization providing services to the "line")
-d. Same legal entity, provider/customer under same EVP (typical relationship between app & infrastructure teams)
3. Centrality of computation to the consumer. That is, is the service being provided to enable a higher order computing service? Or is the service being provided to enable a business process? This is a critical distinction and one that can generally be crisply made.
In general, if the service is
1. Relatively large & costly
2. Relatively more organizationally differentiated
3. Enabling a human centric business process, rather than underpinning higher order computation
I think everyone would agree it's a fine candidate for a service. On the other hand, if it is
1. Relatively smaller
2. Relatively less organizationally differentiated
3. Enabling higher order computation (e.g. network to hosting, or hosting to app) rather than a human centric process
that is where the controversy comes in.
(Did I miss any dimensions?)
My question for James and Rob is, where should the bright shining line be placed along each of those dimensions, and why should it be there rather than incrementally further down the spectrum? If it's a team of 200 under an SVP, they can have entries in the service catalog, but the individual VPs and group managers cannot?
The concept of 'the waterline' is begging the question. Where is it? Is it always and only about the legal boundaries? I think that is too restrictive. What if I am in a captive IT organization who is suddenly outsourced to TCS? Do the same activities get to become a "service" just because of the change in legal model? Are services between units of a holding company inappropriate? When one party is minority stockholder in another? Majority stockholder?
Is a hosting, network, or DBA service nonsensical when provided to an app dev team under a common EVP, but suddenly acceptable if it is used directly by line-owned developers (e.g. in Marketing, under no CIO?)
This is why I advocate for a patterns-based approach. What is working in the real world? I am more interested in small, humble examples people can point to that are actually functional. E.g. my alma mater's service catalog. Go Gophers!
My inquiry of Cary is, what is the future of detailed activity-based IT cost accounting in the face of the Lean and Throughput Accounting movements? Ohno chased all the cost accountants out of Toyota. Many Lean/TOC advocates think cost accounting is waste. I have not seen any discussions of Lean IT Finance yet... but I would think that it would start with a very skeptical eye on any form of cost accounting, whether allocation or activity based, especially if that accounting is being used to recover costs for large sunk capital investments. Only truly variable expenses should be considered, according to some Lean accounting stuff I've read. (Example.)
Would that change the service definition debate? It can only be a service if the costs are truly consumption-based from the enterprise perspective? No manipulation of capacity white space, no rebates, no fictitious metering allowed? Would such principles be helpful or harmful? And, there is the whole concept of service culture we haven't even touched yet. Independent of service financing, it seems to me that attempting to inculcate a service culture is beneficial, even down to the DBAs? Mightn't a service catalog play a transformative role along those lines?
As you all can see, I have more questions than answers. Nor could I read the debate with the detail it deserves, so apologies if I've misunderstood or overlooked key points.
Charles T. Betz
http://www.erp4it.com
Rob Stroud's view
he role of the CIO and IT is transitioning from being the IT factory to specification of the components, negotiating with suppliers and then assembly. Even the after sales support and delivery may be the domain of others moving forward
Costing
The first step is to get away from standard costing and develop a service-based BUDGET. A financial structure based upon services, not functions. A services-based budget is key.
With that budget we can identify rates based upon actual forecasts of demand usage and the overhead structure. We can identify the overhad that is applied from corporate activities like United Way and other required time-wasting. We can identify overhead that is from cost drivers vs. overhead that is not reduceable.
It's about getting to a rate for each service. It's about knowing how much each "service" will be selling to other services and how much they'll be "buying." For instance, DBA's sell their service to application teams, DBA's buy compute services from Server and Client management teams. It's about washing out the overcounted overhead.
Time-Driven Activity-Based Costing is easily adaptable to services organizations and can easily be adapted to those organizations that have time-tracking or work order driven activities - such as Design for Six Sigma. TDABC works of data captured from the time capture and can explicitly be incorporated into any request fulfillment process at the transaction level.
Both lean management and TDABC are based on process maps. Both are data-driven and fact-based. Both promote accountability and ownership among operating employees.
Lean projects eliminate waste within departmental processes. TDABC deals with factors that cause complexity within processes. Lean, DFSS and TDABC are synergistic - once we build a budget based upon services.
Lean accounting is a costing method that supports creating value for the customer by costing the entire value stream. An interesting side effect of making everything a service - whether a customer facing service or an internal only supporting service - is that all service provision is priced.
The combination allows teams to know where to apply their priorities (Pareto), measures rework, cost of quality, etc.
There is generally little argument about needing evidence of pricing once a Service Catalog is produced, particularly a self-service request catalog. The first question, like a menu in a restaurant, is, "how much?"
Having priced services, based upon prices that are transparent and trusted, are important to "alignment." Furthermore, when services usage reports are designed so that users and management can relate their activities to actions that can reduce demand - gives user management some increased measure of control over their costs. That's a real crowd pleaser that often makes a big difference in satisfaction and perception.
It all starts with a change to service-based budget. And, then a commitment to drive all work with the request / fulfillment cycle. In Flores, Fine and DuMoulin's fine book - this is a top-down budget approach with a bottom-up approach to defining the individual self-service services. Get your activity-diagrams with swimlane skills revved up!
Synthesis
Rob, Cary, Charlie et al,
Can I reiterate how important and useful I think this debate is? I know it might appear academic to some, but there are already organisations out there who are sinking their entire transformational ITSM resource into going down the line of "everything is a service"
I suspect for some, especially those who have integrated it with a sensible out-sourcing strategy, it will work well. For others it will be an unnecessary distraction. There is a danger that in deciding whether DBA is a service or not we come back to the great cop out phrase of ITSM - "It depends" - which should be emblazoned on the ITIL books in the dame way that "Don't Panic" was on the Hitchhiker's Guide to the Galaxy.
Trying to combine Rob's point with Charlie's I wonder if the litmus test is "It is a service because there is a customer who recognizes what they are receiving to be a service" To make a bridge to Cary's comment you might add "and is prepared to be charged for it as a service"
Somewhere on this site , a long long time ago, I think I posted a slide to show that back in the mid 90s we were trying to follow the costing approach laid out by Cary, influenced by the early writings on ABC and target based costing. Whilst I remain committed to the idea I can't think of an example where I've seen it carried out in practice within the IT world. I suspect the catch is that to build the model successfully you need to have a good idea to begin with of what the answer is - a bit like using a slide rule.
James Finister
www.tcs.com
http://coreitsm.blogspot.com/
Either way
I guess both push and pull models work.
If I want to act as if I am delivering a service then it s a service even if the customer initially doesn't perceive it that way (I bet they soon will). Likewise if a customer wants to consume it as a service then I better comply pretty quick else they'll go somewhere else.
Either way it's a service
A service is ...
Pure theoretical models always fail to perfectly model the real world because we reduce all models to simplifications in order to make them manageable. There are no clean abstract definitions of "what is a service" in the real world.
You know me: i always try to see things in a simple useful pragmatic light. I think a service is a service when we treat it like a service. To go back to my last comment about a DBA playing grown-ups by saying they are a service provider: I won't be patronising about it if they really are treating it as a grown-up service.
A service is something that has the ITSM practices and artifacts wrapped around it to make it a service.
Saying it doesn't make it so. Living it does.
A plumber
A plumber provides a service.
A plumbing contractor provides a service - likely more complex than a single plumber. The plumber sells his service to the plumbing contractor.
A general contractor provides a service - likely more complex than a single craft. The plumbing contractor sells his service to the general contractor.
But, at all times they know the plumber's rate and the jobs that that plumber is delivering.
Every electrician, machinist in a plant, doctor and his charge code, lawyer and his client - track their costs and their services. They don't waste "vast amounts of time" tracking their time. In fact, in many cases they get work orders and charge numbers before they are allowed to work at all.
Why is it that so many crafts and professions can do it - with systems created by IT - but IT cannot?
They're all services. They all know the rate for the service.
What we seem to be disagreeing about is that I believe that supporting services - DBA or plumber - "sell" their services up the value chain. You don't. You seem to think they are an organic overhead. I don't.
Each individual, each service - has a cost. At some point you have to account for that cost within a service. You can estimate it if you like - allocations. When you do that, however, without some sort of Time-Driven Activity-Based Costing effort - you create a lack of transparency. Lack of transparency leads to mistrust.
That may not be an issue for TCS. The customer buys at a price you set - how you manage is up to you.
But, it would seem to be more of an issue for, admittedly immature, IT shops.
Each company's CIO has to decide what they spend their money on. Whether they want to drive their work with work orders and build transparency (and trust) - or not.
Another question for you - if you're not driving your work with work orders, capturing who does the work and work times (actual, elapsed) how do you develop heuristics (evidence-based time and cost estimates) for a service? How do you apply Six Sigma DMAIC? Track service failure costs? Track rework, waste? Do Lean analyses? Know who is accountable? How do you standardize?
Field services organizations use these techniques all the time.
pretending to be a grown-up
A plumber is a retail service provider. they sell services direct to a paying customer/consumer/user. there is no disconnect between the customer and the user. as discussed all these direct retail models are wrong for most IT units reading this.
A DBA does not sell services, not in any org I've ever seen or heard of. Where's the catalogue? the SLA? The SLM? Do they do their own incident/problem/change for their service? Do they identify a market space and set portfolio strategy? C'mon this is yet another terminological debasement: please don't let's erode "service" into meaningless like so many other words. A DBA saying they are a service provider is like a little girl staggering around in Mummy's lipstck and high-heels pretending to be a grown-up.
As I've blogged before it's worse than that: it also gives the DBA an excuse to narrow their horizon to the next cube down who is their "customer" and abdicating all responsibility for the real service.
One Outsourcer to rule them all
James
This is a good point. There is a distinct cost in defining things a service. Sometimes I think that some of my most valuable consulting contributions are when I tell customer not to do something. It is so easy to do and buy unnecessary things.
Another interesting point is the multisourcing model. It is interesting to see where this one outsourcer over others -model will lead, hopefully no to this:
One Outsourcer to rule them all,
One Outsourcer to find them.
One Outsourcer to bring them all and in the darkness bind them (sorry, remember you are not a Tolkien fan)
What I hear in the market is that people feel that they are insignificant as small customers to a large outsourcer and there seems to be more and more small players in the market. Actually some of these small outsourcers buy services from bigger ones. For the customer it means that the service has a human face.
Aale
Anyone's Guess
Aale,
I think it is fair to say the Service Integration market is in very early days. Currently it seems to be being driven by third party advisers, rather than organisations deciding for themselves that it is the way forward. On the other hand it does address very real issues such as the skills gap in many retained organisations.
How would it affect the overall market if it took off is an interesting question.
Interesting comment about small companies and outsourcers.
James Finister
www.tcs.com
http://coreitsm.blogspot.com/
Consumers have types
Its late - so apologies if I read like I'm rambling...
USMBOK - a consumer is any person or community who may or does consume the resources of a (service) provider. Borrowed from commercial marketing speak.
Depending on the service industry, a consumer may be called by another name (keep it clean!), for example:
- Transportation: passenger
- Healthcare: patient
- Disney: Guest
- Nordstrom: Customer
- Online store: Shopper/visitor
- Consultant: Client
You get my drift. Lean tends to use consumer as they consume resources. The terms consumer and customer are inter-changeable and most folks get it - except some in IT it seems - quelle surprise. Here goes IT again complicating matters I suspect.
Consumers like stakeholders have an 'interest', this must be defined when building 'pictures of your customers' (thanks to Barbara Bund). This allows us to differentiate between a buyer and a user.
The key think to ask if you are working in IT is "what business are we in". As I am sure I've blogged elsewhere, if you ask an airline that they might say "we fly planes". IT might say "we manage ICT/IT". Both are wrong. An airline's business is to transport passengers from A to B - in a timely manner!
IT must ask what business they are in. Frequently. As for services - you don't need any and I agree - especially not something like a DBA - unless you can directly associate it with an outcome the consumer/customer gives a monkey's aunt about...
Perhaps my point is lost here
What seems to be part of the discussion is that some define a service as what is delivered to a customer - an external customer.
I define a service as what is delivered, experienced, or whatever to a customer - external or internal.
From a Service (product) manager's point of view the external customer viewpoint is what he's primarily concerned about. But, since many of us in this discussion have been product managers, we all know that we assemble services from many other services - we "buy" services internally.
What is complicating this is that we can, increasingly, "buy" services from outsourcers, cloud, etc. - hybridized delivery.
It's not really the delivery of services I'm discussing, but how we assemble services to deliver.
It seems to me that IT is, increasingly, to rely on cloud, outsourcers, etc. How we manage those suppliers, how we assemble those services, how we manage the contracts and the finances - that will be the test in the future.
My point here is also one that James points out - most IT organizations have a very low maturity when it comes to the skills and processes necessary to manage this issue - IT financial management, IT asset management, IT contract management, IT procurement, IT designed and structured as services and not as process functions.
Organizing and controlling (that budget) in modular, loosely coupled way instead of the tightly-coupled, highly-integrated way that is traditional, is likely to be a paradim shift for IT organizations. But, if we're to intelligently exploit the purported economic advantages - don't we have to make this change? And, if we don't, won't those companies that have more mature IT organizations be able to exploit the cost-savings and agility that we're not able to?
Bring on the paradigmologists
Cary,
I don't think your point is getting lost, so much as it is waiting in the wings.
My point remains that there is a distinction between being able to do something and it being the right thing to do.
Yes we can un-bundle IT in a lot of ways, and source each bundle individually on a best of class or lowest cost or whatever basis. Equally we could go to one mega supplier and leave it to them source the services and exploiting economies of scale. Both are perfectly feasible and valid options. Equally both have risks and costs attached to them. For that matter who is the "we"? If you can unbundle services do you actually need a central retained It organisation at all - are we about to witness a new form of shadow IT forming?
James Finister
www.tcs.com
http://coreitsm.blogspot.com/
Consumer and Customer
Ian
All your examples are paying customers, execpt the patient when healthcare is free but as you live in USA, you probaly did not consider that.
Our public healthcare has the same problem as IT. The customer is the City or County which pays for the service and the patient is the poor consumer. The problem has been that the patient has not had any right to choose. In most instances the system still works suprisingly well as the medical profession has high standards, but there are cases where it does not. In this case the patient, i.e. consumer is not the real customer.
Now our government is changing the rules and giving the consumer more power by letting the patient choose freely where to go. This will change the picture as the hospital gets their money per patient and the patient becomes more of a real customer even if she does not actually pay anything for the service.
But otherwise, I agree. The consumer is a stakeholder and has some power and the people who are working in the service organization must understand why they are working.
Aale
Who pays shouldn't matter when delivering the Service
This notion of distinguishing who pays for the service versus who consumes the service is useful when designing the service, but doesn't seem to be relevant when delivering the service. Making sure it is fit for use and fit for purpose is essential. We don't want to over design things that nobody wants to pay for.
However, once the Service is in use, the consumers of those services should be treated independently of whether they are actually paying for the service or not. As Cary pointed out, in the example of services I buy for my family, I pay the bills, but my family members are certainly the customers/consumers/users or whatever other word you want to describe them. How the service is delivered to them doesn't change whether they pay the bills themselves or I pay them.
In the corporate world, a member of the sales team that uses the order processing service doesn't directly pay for it, and it shouldn't matter. The payment for that service comes from a variety of places, but ultimately, the company is paying for the cost of providing that service.
If the service extends all the way to the businesses customers, for example an airport kiosk for checking into my flight, then as a paying customer of the airline who purchased a ticket, I am not paying anything extra for the Kiosk service, but I do consider it an extension of my original purchased service of getting from A to B.
My overall point here is that who pays for the service should be irrelevant when delivering the service.
-Chris York
Utopia
Chris,
This is a bit like the debate about VIP users. There are those who are vehemently opposed to the idea that some people should get a better service "just because they are senior", others who see it as part of alignment with the business (and who like the identity of VIPs and the criteria for inclusion in that category to be transparent) and those who use VIPs as part of a political game.
Understanding that customers, consumers and users have different requirements and should be serviced in different ways is not the same as saying we are offering users an inferior service, as such. what we are saying is that the decision as to what is important to the organisation has to come from the customer - which of course include the possibility of the customer devolving that decision to others.
To take the salesperson, yes they are important when they are using the sales processing service, but how relatively important they, their activity, and the sales process order system as a whole are to the organisation is a customer choice. In a situation where you have to decide which of two services to restore first the choice is again primarily a customer choice.
The other obvious way in which the needs differ is in terms of the service reporting the different groups need or want. As a user I might be less interested in overall service levels than in the service specific to my transaction. The customer might not be bothered that a specific transaction has failed as long as the overall service levels are being met.
Your distinction between roles in service design and delivery is a useful one in this context.
I suspect most of us in our careers have come across systems that were supposed to achieve one objective during conception and design, but which in delivery ended up delivering a different functionality in the view of users.
The kiosk is relevant to a different debate. For instance it can be substituted with a different kind of service, such as on line check in. Of course you can break the airline service down intro a whole series of mini-services, but you need to understand how they relate to the overall service. I've found the Kano model quite useful for thinking that through.
http://coreitsm.blogspot.com/2010/02/coreitsm-101-kano-model.html
James Finister
www.tcs.com
http://coreitsm.blogspot.com/
Restaurant Analogy - Sorry Rob
James, I understand and agree with your points. By the way, I am on the side of the VIP discussion who disagrees with providing superior service to VIP's just based on the status of the person.
Your example supports my statement that during the delivery of the service, identifying the customer is not necessary. When delivering support for the services, the IT staff need not understand who pays for the service. This shouldn't be a part of the decision process to decide which service to restore first. If Service A is paid for by Customer A, and Service B is paid for by Customer B, then you can't possibly ask the Customer. They will choose their own service that they paid for.
Rob started this thread by stating that "If I see another analogy comparing IT services to a restaurant I'm going to throw up". At the risk of him throwing up, I will respectfully disagree with the relevance of the analogy. In the restaurant, you typically have a group of people dining at a table. It is fairly common for a single patron amongst the group to be the 'customer' and pay the entire bill. While everyone else eating would be considered 'Consumers'. They are not directly paying for the service, but they are certainly recipients of the service.
If Table A, with Customer A and 5 Consumers have a problem, who is to say that they are more important than Customer B, with 10 Consumers?
-Chris York
Socialism & ITSM ;-)
Chris,
I just knew which camp you were going to fall into on the VIP question, but that isn't incompatible with the second option. If people have VIP status because what they re doing is intrinsically important, and they also happen to be of high status then I have no problem with that. Some organisations even manage their VIP lists dynamically based on the role, rather than the actor.
During delivery of the service the ghost of the customer should always be present. That sounded a lot better in my head than it does written down.
Your situation with the two paying customers is usually resolved in an internal situation by identifying the customers at CXO level. I might have a figure for IT spend on my budget, but if I can't flex that figure, or influence how it is spent, am I really a paying customer or just a consumer?
In an outsourcing model it isn't unusual for the order in which services get restored to be a commercial decision based on account size or some other criteria. And that is a key point, in deciding which user is currently our priority we will take a number of criteria into account, not just who is the customer, but those criteria have to be aligned with the customer.
Back to that restaurant analogy. Imagine that table of people isn't a family group or friends out to dinner, but a team of consultants having an audience with a senior partner. The dynamic is incredibly different.
And so to your final question. The point is that it is posed as a rhetorical question, but in the real world it needs a pragmatic answer. Whether you like it or not if you have limited resources to service (Customers/Users/Consumers - delete as appropriate) you have to make difficult choice and compromises. Perhaps the smaller table is less important, but by serving them first I maintain a better flow through the system with less total waiting time for everybody in the room - Hey we've invented ITSM Utilitarianism!
James Finister
www.tcs.com
http://coreitsm.blogspot.com/
Dangerous thinking
Those are dangerous ways of thinking. The exhibitors come only if the attendees come. Wait till you see a conference with more exhibitors than attendees.
The Soviet style did not work for Soviet Union and neither will it work for any corporation. The user-customer distinction is greatest in hierarchical organizations (like hospitals), but it is not a good model. I think Captain Abrashoff explained it quite well in Pink 11, the captain has to listen to what the crew needs. In most organizations the customers are also users, downtime may annoy the boss more than the staff who just take a break.
Then there is the completely ignored segment of IT services; business to consumers. Consumers buy IT services directly. Or is there a separate Rob the User who bitches at Rob the Customer who buys crap services?
Aale
The Market
In recent moths I have become increasingly concerned about the number of IT managers I meet who seem to have suddenly converted to the view that everything IT does can and should be treated as a service. So I see things such as "Database Administration" becoming a detailed entry in the service catalogue, telling the "customers and users" every detail of what the DBA team does. This is accompanied by supposedly negotiated service levels, and a dedicated DBA service manager. The net result of this is an IT bureaucracy and management overhead that confirms many people's negative view of ITIL. It seems that once again a smell element of what makes up an effective ITSM approach has been elevated to the status of a silver bullet.
Going back to my earliest involvement with ITIL, in v1 training days we always opened the managers course with a discussion of the product-service continuum. At the same time I was involved in the early stages of UK central government's move towards outsourcing services under the "Market Testing" banner. One way or another I have been involved in outsourcing ever since, moving at times between the roles of adviser, customer and provider. What strikes me in hindsight is how often IT departments have conjured up an artificial and arbitrary concept of customers. Inevitably what follows from that is a misunderstanding of how the market operates and IT strategies that reveal just how out of synch IT is with the business.
James Finister
www.tcs.com
http://coreitsm.blogspot.com/
Yes, I did not mean that
You are right, DBA is not a service and has nothing to do in the service catalogue.
I have also doubts of the concept of IT as business within business. If it is business then there should be competition, monopoly is not a nice form of business but I doubt that the internal IT really wants to have competition. Internal IT is a part of the business and if it well run, it helps the business to succeed using its special capabilities.
What I disagree with is the strong Customer - User dichotomy, I think it is just the British upstairs-downstairs culture that got into ITIL. In the times of V1 managers did not touch keyboards.
Aale
Customer User
Aale,
I don't think it has anything to do with class. If anything the last twenty years has seen a shift in British culture towards the citizen as a customer with choices rather than a dumb recipient of what is dictated by the great and the good. It does have everythignt o do with market forces and spending choices. A user does not and cannot make economic choices* and that in some cases included a user who was acting as a customer at the time a service was procured, and will return to being in a customer role when the service is next replaced. Coming from an outsouricng background I'm also aware that there is a complex framework of obligations - neither the customer nor the supplier operates with total freedom.
*Not strictly true, but it is for the purpose of this debate.
James Finister
www.tcs.com
http://coreitsm.blogspot.com/
Nordic perspective
James,
We should not argue about different national cultures. I apologize for starting it.
Yes, you are right. A corporate user is rather helpless, but one hears more and more stories of people taking things in their own hands. In a recent interview a person told that he has two laptops on his desk. One is the "official" and useless and with the other he does all his work.
The real danger in the user-customer thinking is that IT people will consider users as second class citizens and treat them correspondingly.
Aale
BYOM
Aale,
There are two possible sides to this. One is the user who chooses to bring in their own device because it suits their way of working better. This can be done with varying degrees of official approval. support and control. i'm seeing more and more of this. A second case is where the organisation actually expects the workforce to provide their own equipment. I can't say I've seen that in the flesh in EMEA yet, but I hear rumours that it is not unknown in the USA. An interesting question would be what factors does the user's own kit address that the corporate offering doesn't. In my experience to date it seems that small size and the ability to use entertainment and social media are big attractions, not the impact on the core functionality of the business services they are accessing.
Differentiating users from customers does not mean discriminating against users, but it does mean being realistic about how the needs of an individual user stack up against overall needs of the organisation and, yes, the overall politics of the organisation.
James Finister
www.tcs.com
http://coreitsm.blogspot.com/
restaurant analogy still applies, sort of
Are we in violent agreement?
Customer (ITIL end user) buys & eats the food (ITIL "Service").
Restauranteur (ITIL customer) sets the menu, decides what should be on the wine list, the grade of table-service, price to customer.
Kitchen/bar (ITIL IT Shop) cooks the food, makes sure that the ovens & refrigerators work.
Suppliers (ITIL suppliers) provide raw ingredients, kitchen equipment, maybe cleans the toilers because nobody wants to do it.
Don't see what the problem with this analogy is.
The Restauranteur is the customer.
Only issue with this is that @ most restaurants, the customers (and the customers) don't get a heck of alot of choice, but there's no reason as to why if the food is terrible, then the customer (user) should be able to request and pay a premium for something better via restauranteur (customer) approval.
Hopefully that makes sense.
Who's on second?
reverse it
i've been toying with the idea of reversing the perspective as a bit of a sanity check - by thinking "who do they think is providing them a service".
If you've (IT) picked someone and are thinking of them as being a customer - do THEY think of IT as providing them a service, or someone else.
For e.g. In an airport, yeah sure I am a customer. But as you are saying (I think), I'm NOT a customer of the IT dept. I am receiving a service from the airline, the airport company etc. Sure there are IT services involved - notifying me of flights etc. But I just see those as services of the airline/airport/something. If the IT service is wrong - I don't get pissy at the IT dept or outsourcing company, I get all hot and bothered at the airline.
The airline however probably DOES see their IT dept as providing a service to them - giving value by helping them to provide a good service to the traveling public.
There's probably holes in that idea (plug away Skep)- but I'm starting to think that if the customer does not see the IT dept/company as being the service provider, then they probably aren't actually the customer.