The IT Skeptic - Comments for "Who is the customer?"

giddy

skeptic — Fri, 03 Jun 2011 20:12:00 +0000

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

Madeleine — Fri, 03 Jun 2011 10:54:48 +0000

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!

Rob Stroud's view

caryking — Fri, 03 Jun 2011 01:48:00 +0000

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

Either way

skeptic — Wed, 01 Jun 2011 14:34:45 +0000

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

Synthesis

JamesFinister — Wed, 01 Jun 2011 12:13:19 +0000

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/

Costing

CaryKing — Wed, 01 Jun 2011 04:23:18 +0000

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!

A service is ...

skeptic — Wed, 01 Jun 2011 02:56:41 +0000

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.

pretending to be a grown-up

skeptic — Wed, 01 Jun 2011 02:43:56 +0000

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.

DBA services & other thoughts

Charles T. Betz — Wed, 01 Jun 2011 02:41:26 +0000

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

Bring on the paradigmologists

JamesFinister — Tue, 31 May 2011 21:42:10 +0000

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/

Perhaps my point is lost here

CaryKing — Tue, 31 May 2011 20:50:24 +0000

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?

Socialism & ITSM ;-)

JamesFinister — Tue, 31 May 2011 20:43:52 +0000

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/

A plumber

CaryKing — Tue, 31 May 2011 20:34:47 +0000

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.

Restaurant Analogy - Sorry Rob

Chris York — Tue, 31 May 2011 19:39:19 +0000

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

IT Pizza

JamesFinister — Tue, 31 May 2011 16:56:00 +0000

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/

IT as caterer

hazyitsm — Tue, 31 May 2011 16:41:54 +0000

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.

Utopia

JamesFinister — Tue, 31 May 2011 16:22:46 +0000

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/

Who pays shouldn't matter when delivering the Service

Chris York — Tue, 31 May 2011 15:39:26 +0000

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

Consumer and Customer

aroos — Tue, 31 May 2011 11:35:09 +0000

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

Consumers have types

ianclayton — Tue, 31 May 2011 10:24:46 +0000

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