In My Opinion: Tiered Pricing

  • Smaller Small Medium Big Bigger
  • Default Helvetica Segoe Georgia Times

When I first contacted Midrange Computing about writing this article, I was sure that someone else was already working on the topic. But to my disbelief, MC said that no one was. What has happened? Have we accepted tiered pricing as a fact of life, such as getting heartburn after eating a burrito? Let's examine tiered pricing as its ugly naked self. If I understand the theory behind tiered pricing--and I'm not admitting I do--I suspect the reasoning is this: There should be a charge for each person who uses the software product. That is all good and fine, but is this the way it is? The way software companies charge for usage is to charge a higher fee for each model of the AS/400 or charge an upgrade fee if you move from one model to another.

Their theory is that if you are upgrading your system it is because their product is so good that you have to upgrade your AS/400 to accommodate all the users who wish to use that product. Dream on. I have been through eight major system upgrades during my seven years in this business, and not one of the upgrades was because there was a need to add more users, but because of the need for more throughput. This is probably the case in most upgrade situations. A business upgrades its computer system because of growth. Unfortunately, to plan for a hardware upgrade, you must cost-justify the hardware and software. How do you cost-justify software you are currently running? You know, the one you paid full price for, plus the usual 15 percent annual maintenance fee? You don't get any additional benefits from the product. How many of us have tried to explain this to a CFO or CEO?

Well, if the software companies want to charge more for more users, what if I were to tell you the exact opposite sometimes happens? This is most apparent on software development tools (CASE tools, documentation software, etc). Here's an example: A data processing shop with two programmers is on a D60. Their programming backlog increases greatly and so they decide to implement a CASE product on their D60 at a cost of $98,000 ($49,000 per user). Down the road, there is another DP shop with 10 programmers. They run four D80s, all maxed out, utilizing massive disk mirroring, all tied together by phone lines, token rings, bungi cords and dental floss. Did I mention they had a development machine? All programming is done on their D35. They install the same CASE product on that machine at a cost of $58,000 ($5,800 per user). The moral of this story is that if you are on a D60, D70 or D80, then buy a development machine. Purchasing an AS/400 C10, OS/400 and CASE for development will cost you half as much as buying the CASE product for a D80. Your response times will be better, too.

What I want to know is, why couldn't software companies speak honestly and say, "Gee, Mr. MIS Director, we're so glad your company is doing well. Now that you can afford a machine upgrade, you can fork us over a cut. We will be expecting a check, and your software won't work until you do. We've got you by the wazoo, and there's nothing you can do."

Why Ask Why?

Now, with that said, guess who is apparently making the first move to correct tiered pricing? I recently read in a trade magazine where IBM has said it is going to address the problems of tiered pricing with OS/400. I believe IBM has realized that tiered pricing could be curbing some upgrade plans for a lot of customers.

I can only hope the rest of the software industry will address its pricing structure. And, why shouldn't it? The capabilities for limiting the number of users who can simultaneously access a program exists now on the AS/400. Utilizing this procedure would be fair to all parties. This way, you can buy a CASE product for $5,000 per user and allow one person to use it. If the product is so good that you want two more people to use it, then upgrade your license for an additional $10,000. Utilizing this concept, royalties would be paid back to the software companies from the strength of their products, and not from an unrelated event such as a badly needed upgrade. I wonder if a software company has enough confidence in its own products to structure a pricing scheme on a user basis.