Early next year I'm going to ask Sourcing & Vendor Management professionals to vote on which software companies' licensing policies they most resent as Unfair. Fairness is a subjective quality, but it seems to me that some policies penalise customers for circumstances beyond their control that are unrelated to the value they are getting from the software.
Others have serious consequences that may not have been apparent to the buyer when he agreed to the contract. Fair software pricing charges some companies more than others, but in a logical, transparent way that is related to value. Jim Hagemann Snabe (SAP's co-CEO) explained software pricing best practice extremely well in this recent interview.
"Q: What is SAP doing to meet user demand for greater clarity on licensing and pricing?"Snabe: "The problem is a logical one. On the one side, customers would like a very simple price list with as few items as possible, and on the other side they don't want to pay for stuff they don't use. So we need to find a balance between these two. We are constantly working on simplicity of the price list. Ideally, you have a main price concept which is the number of active users, and not what they use. And then the idea is if I produce more functionality, then maybe more people will use it instead of pricing every piece of functionality on its own. Now there are some functionalities that can't describe their value in number of users. In fact, the goal is that there are very few users, like payroll. You basically need only one user. So there you need to find other ways of describing the value, so that a large company pays for the value associated with solving a large problem, and a small company pays only for the value associated with a small problem. In that case, it is the number of payroll slips [that counts] which is a reasonable simplification of the value creation."
Every software company's VP of pricing strategy should read and follow the above advice. Unfortunately, many publishers, including SAP, depart from JHS's guidelines with indefensible policies. Top of my list right now is the multiple-charging for people who access trading partners' systems to collaborate with them, a.k.a. External Use, which I wrote about last year: Do Your Software Contracts Permit External Use?For example, suppose I have a user ID for my customer's business system to work with him on a design project, plan production schedules, and/or finalise a joint marketing promotion. Even if I have a valid user license for my own SAP system (or Oracle, Microsoft, etc.), my customer still has to buy another user license to enable me to access his system. I've recently seen several situations where a publisher is trying to get two, three, . . . , n user license fees for the same individual in a situation where multiple supply chain partners access each other's business systems. That can't be right. And don't say "Oh, in that situation the customer should license by processor." My answer to that includes the words "cloud," "multi-core," "virtualisation," and "off!" No, software publishers should fix this increasingly common problem by simply extending a user licensee's rights to cover trading partners' systems, possibly for a small extra fee.
Here are some candidates for "Unfairest Policy Of 2010":
- Prohibiting or charging extra for external use.
- Charging maintenance on shelfware (unused products and undeployed license capacity).
- Counting a quad-core CPU as two or more processors, when it is clearly one physical CPU (see Per-Processor Licensing — It's All About Core Values).
- Making a customer pay full price for software that it accidentally deployed on extra devices, but never used.
- Similarly, making it pay for options it accidentally installed when the customer has no way to relate what he is installing with the publisher's SKUs in the price list.
- Limiting how frequently a customer may move licenses between physical servers within a virtualised data center.
- Charging hosting service providers multiple times for the same software if one server supports multiple clients.
- Processor Value Units.
- Charging maintenance from the date of the purchase order, instead of the date of deployment or use.
- Increasing maintenance prices each year (e.g., by a CPI %) when the product's list price has stayed the same.
Posted by Duncan Jones