HomeIndustry Commentary

Where the ITaaS IT-as-a-business metaphor does fit

Like Tweet Pin it Share Share Email

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.

Comments (4)

  • I must say I really learned a lot in a relatively few words about how some of the best managers I’ve worked for understand their jobs and responsibilities.

    Very enlightening. Thank you.

  • I am with you all the way with your criticisms of IT as an “internal business.” I begin to get uncomfortable when you talk about a “product/service” catalog with descriptions and prices. I think I feel that way because I think of IT not as a generic “professional services firm,” but as a consultancy. A consultancy, in my view, does NOT have products or services per se (although it may provide the same item or service for numerous clients), but instead focuses on how it can help its clients/customers achieve success with their products/services/processes. So instead of “IT offers A, B, and C,” I suggest it should be “IT offers to help you with your product/service/process; part of that help may (or may not) involve providing A, B, or C.”
    Rollie Cole, PhD, JD
    Founder, Fertile Ground for Startups, Small Firms, and Nonprofits
    “Think Small to Grow Big”
    Author of WHOLESALE ECONOMIC DEVELOPMENT http://preview.tinyurl.com/wholesaleeconomics

  • Rollie,

    While I see where you are going with the consultancy model, at the end of the day, a consultancy provides services. They may or may not sell products as part of the deal, but they are selling a service, and they should be able to associate a price with it at some level — even if we all agree that customizations and specific needs will greatly impact the price.

    If not, how will they know when they’ve accepted a deal that will fail to make them any profit?

    -ASB: http://XeeMe.com/AndrewBaker

  • Rollie and Andrew are hitting on an interesting point. If somebody in your organization want you to run IT as a business, do they think they want you to run it as a consultancy or as a contracting shop?

    A consultancy is expected to provide direction and guidance, and price comes out of a negotiation over potentially many weeks.

    A contract shop provides defined services — including software, hardware, and the people to run them — according to a fixed schedule and hourly rate.

    An organization may need both, but if someone thinks they’re asking for column A and you offer column B, or vice versa, it’s not going to go well.

Comments are closed.