ManagementSpeak: We’re a service bureau. We’re doing this project because the client is willing to pay us good money.

Translation: We’re members of the oldest profession.

This week’s contributor, on the other hand, did it for the satisfaction.

Are you sure you want to go through with this?

We’re still taking about IT as a Service (ITaaS) — the shiny new buzzword for the well-worn idea that CIOs should run IT as if it is an independent business. And as in past weeks, rather than railing against it, we’re trying to make it work.

ITaaS proponents don’t really think you should run IT like an independent business, possibly because many don’t know what’s needed to run an independent business. Doing it for real would deeply distress just about everyone, both inside and outside IT.

It’s just a metaphor. As with all metaphors, you shouldn’t push it too far.

Last week’s column explored the boundary:

  • Growth — real businesses want it; few CEOs want IT to do it.
  • Sales and Marketing — real businesses do it; no CEO would want IT to do it.
  • Competition — most real businesses have it, but not all — there are monopolies, both de jure (by statute) and de facto (they just are). ITaaS’s proponents might want IT to give up its de jure monopoly, but the long-term impact is likely to be a race to the bottom, culminating in a shoddy and poorly integrated systems environment.

Here’s one more metaphor boundary challenge: affinity. I nearly said loyalty, but as employer loyalty toward employees has gone out of style, they can hardly expect employees to feel loyalty to them in return. (Many executives do expect this; why is an ongoing mystery. But I digress.)

The question is whether you want your company’s IT professionals to feel a sense of affinity for the whole company, or only for the part that falls inside the IT organizational chart. That will determine whether they base their day-to-day decisions on what’s best for the business as a whole, or on what’s best for the IT department.

After all, while vendors try to provide value for their customers, they try harder to maximize their own profitability.

Why should ITaaS be any different?

Let’s get to it. Every business has to deal with ten areas of endeavor. Five face inward: People (who does the work), process (how they do it), technology (the tools they use), structure (who is responsible for what), and culture (the unwritten rules of how we do things around here). Whether you run IT as a business or as a department you’ll need to deal with these, so we can mostly ignore them as ITaaS differentiators.

It’s the five outward-facing areas we need to think about right now:

  • Products: What you provide to customers that they pay for, including bundled ongoing support.
  • Pricing: Not only what you charge for products but also contract terms and conditions, and your pricing philosophy (for example cost-plus, value-delivered, or what-the-market-will-bear).
  • Customers: Who you sell to. More precisely, your true customers … the people who make or influence buying decisions; plus the consumers who use your products and services and the wallets who pay for them.
  • Marketplace: The business ecosystem you operate in — your suppliers, partners, distributors, competitors, population of potential customers, and their interconnections and interplay.
  • Messages: Everything you want customers, consumers, wallets, and your marketplace to know about your company and its products and services.

Once the ITaaS singing, dancing, and tuba-playing is done, its proponents are really recommending that IT be explicit about products and pricing — that it should establish a service catalog. All the rest lies on the other side of the metaphor line-drawing boundary.

Also, just in case you’re wondering, this is a clear case of vocabulary inversion. Once upon a time, what you sold for a profit was called a product, and we had to distinguish between “services” that were products in that we sold them and made a profit on them, and “service,” which was something we did at no additional charge to support our products.

Now, in IT, everything is a service, so instead of talking about the ERP suite as a product we provide to the business, we talk about providing the ERP suite to the business as a service.

That’s okay, so long as everyone uses the vocabulary the same way. Service catalog it is, and like all catalogs it should provide the name of each service, its price, and promotional copy that entices the reader to want the service so much they can taste it.

Oh, wait, no … that’s sales and marketing, which we aren’t supposed to do. The IT service catalog should describe each service in the dullest possible terms so only people who really, really need it will ask for it.

Or maybe just describe it with clarity.

* * *

Can you take one more? Next week — the ins and outs of creating and pricing a service catalog, and also whether it’s really possible to carve only products and pricing out of the business metaphor and still have something that makes sense.