Problem Analysis
Though there is a growing sentiment that enterprise applications are reaching a commodity status (see If Software Is a Commodity, Can You Still Win Some Competitive Advantage? ), software pricing does not seem to be following the same rules. Indeed, we can hardly think of any top-of-the-line enterprise application (the equivalent of a Lamborghini or Harley Davidson, say) that a wealthy business would deploy just to feel "cool," regardless of the application's high price-per-performance ratio. (Forgive us if we are not yet aware of an enterprise application that run on Macintosh, which would allow customer-supplier collaboration, and permit customers to order and track their complex products via iPod-based portals).
Part One of the series Is There a Panacea for Enterprise Software Pricing Yet?
Joking aside, while enterprise software is apparently reaching commodity status, no one can determine with certainly what a fair price should be for a solution that fits the needs of most enterprises. If the price is dependent on the functional fit, then should a highly functional enterprise resource planning (ERP) or supply chain management (SCM) cost $1,200 per user? Should it be more? Less? Working on the assumption that the product fits the prospective customer's needs "like a glove"—and the importance of this fit cannot be overemphasized—what would be a fair price? Note that we're not necessarily talking about a "fair" price. After all, in the free market, pricing is based on supply and demand, the customer's state of urgency, and the perceived value of the product.
The real problem is how to compare one vendor's pricing against others in a like-for-like manner. After all, total cost of ownership (TCO) calculations should not be rocket science. One has to start by determining application software license fees (which occasionally include third-party software license fees). To this, add professional services costs (which typically includes training, implementation services, and so on), hardware costs, and annual support and maintenance costs (which may also include support for third-party software and hardware, such as bar code readers in the case of radio frequency [RF] applications).
Comparing License Fee Pricing Methods
Certainly, there might always be some optional software or service costs, but basically, TCO revolves around total software- and service-based costs. So what is the problem? Well, let us first tackle comparing common license fee pricing methods. When we are involved in the software selection process, we normally help clients come down to a few finalist solutions based on functional and technological fit, whereupon they then ask us to help them negotiate the best contract price, and finally select the winner. Yikes! Deciphering the US Tax Code is a simple task compared to that!
Plenty of vendors, of course, may produce nominal price lists for their software modules, but if chief information officers (CIO) at prospective user enterprises (or professional negotiators acting on their behalf) want to know the actual pricing benchmarks that similar customers have paid, they either must have insider knowledge, or a hotline to some of the vendor's reference enterprise customers. And of course, they can only gain access to this information when such details are not protected by confidentiality or non-disclosure agreement (NDA) clauses. Even then, these figures are typically muddled by an absence of like-for-like pricing models.
One vendor charges license fees per user (named, concurrent, or casual) and per module (or per bundle of functional modules in a suite). Another bases prices on server/central processing unit (CPU) size. And still another bases prices on its perception of how large (read "wealthy") the customer is, the likelihood of implementing a total functional footprint, and the total number of users the customer might ever want to have. What can one discern from all this? Such a scenario is truly comparing "apples with oranges," and then dumping berries into the mix. However, some vendors will rightfully say that they cannot simplify pricing because different customers want different pricing systems, and they have to do what customers want.
For example, many customers resent the notion of paying for functionality they are not likely to use. In some instances, even if a large corporation needs expanded functionally down the road, they will only pay for the modules they need at the time of selection. Lengthy implementations of (for example) financial management and consolidation, or human capital management (HCM) systems over several divisions and several hundreds (or even thousands) of users worldwide, may make an enterprise reluctant to embark on another lengthy implementation adventure right away.
Thus, a vast majority of business application software vendors still generate most of their revenues by selling their software licenses based on the number of named or concurrent users or seats, typically on a per module or per suite basis. They may also generate revenue based on an excessive "wall-to-wall," "all you can eat" functional scope. The accompanying implementation service, post-implementation service, and support and maintenance services also add to the "pot." These are all are priced as a percentage (and more often multiples) of the software license fees.
However, from the user perspective, there is a fitting analogy: in one trip to the store, no one will ever buy a lifetime's worth of snacks and coffee. We are selective, and over the course of a lifetime, we will buy different products based on what we feel we need or want. Software applications should be treated the same way. To return to our analogy: the stockpile of snacks will ultimately go stale, and the coffee will lose its flavor, or go rancid. Little is consumed, except hard-earned money.(see Application Erosion: Eating Away at Your Hard Earned Value). The same happens with software that is not used.
However, purchasing software la carte is easier said than done. The trouble comes from the "fine print" addendums in software purchase contracts, which are often longer than the main contact itself. These clauses are typically designed to protect the vendor from any future liabilities or to "nail" the gullible customer with extra costs. The fine print will customarily include a statement to the effect that the contract includes only the stipulated basic functionality. Any additional modules will use a different pricing structure, whereby the client will likely pay far more at the end of the day than if the whole application license had been purchased up front. Smaller enterprises (given their smaller number of users, and less complicated implementations), typically want most of the available functional footprint implemented at once, with the option to expand to additional functionality later. These customers might appreciate the option of "wall-to-wall" functionality up front.
Another pricing option variation is based on what users use, and not on what they can get. This is the so-called "pay as you go" option. Typically, enterprise software comes with parametric "switches" that can be set based on a need. For example, a small-to-medium enterprise (SME) user might set a switch to use multicurrency, consolidate financials, use warehousing management, or use standard or actual costing. Based on a contractual agreement, these switches can be set at the "software factory" to limit the functionality that is available to the user. If an enterprise decides later to activate a function, such as warehousing management, the enterprise would have to pay. While feasible, this requires serious contract management and tracking, and an argument could be made that SMEs that use less functionality require less support.
Service and Support Calls
This brings us to the next fine print item, the point which is possibly among the most controversial: service and support calls. With some large software customers reportedly spending obscene amounts of money just to patch their existing software, the cost of poor software quality is becoming painfully apparent to software customers. Vendors typically provide a short period of time—from ninety days to a year—as a "warranty period," within which software fixes are available for free. After that initial period, software customers must pay for service and maintenance, on an annual subscription basis, or on a per-incident basis. As a result, many customers feel taken advantage of, and those who select the solution are presumed "guilty" of paying for the vendor's ineptitude to deliver quality software in the first place.
From this vantage point, many wonder whether the urge to hastily implement these systems prior to the Y2K deadline was so big that it blinded common business sense. Consequently users have ended up on the losing end of their contractual rights, and have become the victims of exorbitantly high costs for enterprise software use, upgrades, and administration.
However beside user frustration, vendors are facing the pressures of cutthroat competition, which is pushing prices downwards. Users also have strong expectations that improvements in software quality should allow vendors to significantly extend the "free" period to something closer to the expected life of the software.
Software customers have a legitimate right to expect their vendors to stand behind their products for a few years or more. During this time, vendors should back product capabilities based on the user's requirements (these capabilities are all too often easily "promised" by aggressive sales personnel). This backing would also make certain that the cost of the software product would remain fixed (and known) during that time. Through this approach, software vendors would have more difficulty in passing the expense of poor quality software to their customers through arbitrary rate increases for software maintenance. Rather, they would have to focus on producing better software to reduce their support costs, in order to remain viable players in the market.
Business-related issues related to software use inevitably arise daily. These issues may result from flaws or bugs in the software, a misunderstanding about how the software works, or both. In any case, software customers want to be able to contact a qualified expert to discuss the issue and resolve it in a timely fashion, with minimal impact on their business. The customer does not really care whether the issue arises from a bug, user error, or lack of knowledge.
Software vendors need to provide unlimited access to support services, including experts trained in the detection and fixing of design flaws in the software, as well as having the ability to explain (in lay terms) how to get the software to perform the functions required by the customer. To that end, no one wants to plow through the fine print to understand how many free-of-charge calls are permitted. Instead, it would be more reasonable to allow for unlimited calls during a multiyear warranty period.
Then comes the dreaded 15 to 20 percent (or more) of nominal license fees for annual service and maintenance costs after the software purchase. Many customers wonder why they should cover the future developments of a few early-adopter customers, since they do not necessarily need additional functionality or the latest "bells and whistles" any time soon (this is what software vendors claim is the reason for these recurring annual costs). Their customers' grievance is akin to the irony of car insurance, where the majority of decent drivers have to pay for an inept few.
Software customers do not see these technological changes as changing the business value of their software, nor do they see them as a justification to pay more money to their software vendor. They are unwilling to pay their vendor to port the software onto a new operating system (OS) or server platform if the value provided by the software has not really changed. They might be willing to pay their vendor for more functionality if it drives additional business value, but even then, they want to pay only when the functionality is generally available and required, not while it is still in development.
Business processes and practices do undergo constant change (see What's Wrong With Application Software? Business Changes, Software Must Change with the Business). For example, changes in business strategy (such as shifts to lean manufacturing) can mandate changes to business processes. Regulatory changes, such as those stemming from the US Food & Drug Administration (FDA), the Heath Insurance Portability and Accountability Act (HIPAA), or the Sarbanes-Oxley Act (SOX), can also mandate changes to business processes. Software vendors have an obligation to keep their products from becoming obsolete even in these contexts, and customers have the right to expect that they can use updated products to address these issues, including reasonably easy and cost-effective upgrade processes.
One can only imagine the public outcry and revolt if car manufacturers decided to charge car drivers an annual fee—a percentage of their nominal car model price, say—indefinitely, for future developments! At this stage, software vendors are participating in a practice similar to that of pharmaceutical companies. Pharmaceutical companies justify the exorbitant prices of critical medications for consumers by professing the need to reinvest part of their hefty profits for future developments, but even in this case, customers know what they have to pay when they are at the counter. Maybe if enterprise software development could come up with a cure for cancer, AIDS, or Alzheimer's, or implement some other supreme benefit to humanity, then software users would also put up with the recurring service and maintenance costs.
SOURCE:
http://www.technologyevaluation.com/research/articles/is-there-a-panacea-for-enterprise-software-pricing-yet-18320/
Though there is a growing sentiment that enterprise applications are reaching a commodity status (see If Software Is a Commodity, Can You Still Win Some Competitive Advantage? ), software pricing does not seem to be following the same rules. Indeed, we can hardly think of any top-of-the-line enterprise application (the equivalent of a Lamborghini or Harley Davidson, say) that a wealthy business would deploy just to feel "cool," regardless of the application's high price-per-performance ratio. (Forgive us if we are not yet aware of an enterprise application that run on Macintosh, which would allow customer-supplier collaboration, and permit customers to order and track their complex products via iPod-based portals).
Part One of the series Is There a Panacea for Enterprise Software Pricing Yet?
Joking aside, while enterprise software is apparently reaching commodity status, no one can determine with certainly what a fair price should be for a solution that fits the needs of most enterprises. If the price is dependent on the functional fit, then should a highly functional enterprise resource planning (ERP) or supply chain management (SCM) cost $1,200 per user? Should it be more? Less? Working on the assumption that the product fits the prospective customer's needs "like a glove"—and the importance of this fit cannot be overemphasized—what would be a fair price? Note that we're not necessarily talking about a "fair" price. After all, in the free market, pricing is based on supply and demand, the customer's state of urgency, and the perceived value of the product.
The real problem is how to compare one vendor's pricing against others in a like-for-like manner. After all, total cost of ownership (TCO) calculations should not be rocket science. One has to start by determining application software license fees (which occasionally include third-party software license fees). To this, add professional services costs (which typically includes training, implementation services, and so on), hardware costs, and annual support and maintenance costs (which may also include support for third-party software and hardware, such as bar code readers in the case of radio frequency [RF] applications).
Comparing License Fee Pricing Methods
Certainly, there might always be some optional software or service costs, but basically, TCO revolves around total software- and service-based costs. So what is the problem? Well, let us first tackle comparing common license fee pricing methods. When we are involved in the software selection process, we normally help clients come down to a few finalist solutions based on functional and technological fit, whereupon they then ask us to help them negotiate the best contract price, and finally select the winner. Yikes! Deciphering the US Tax Code is a simple task compared to that!
Plenty of vendors, of course, may produce nominal price lists for their software modules, but if chief information officers (CIO) at prospective user enterprises (or professional negotiators acting on their behalf) want to know the actual pricing benchmarks that similar customers have paid, they either must have insider knowledge, or a hotline to some of the vendor's reference enterprise customers. And of course, they can only gain access to this information when such details are not protected by confidentiality or non-disclosure agreement (NDA) clauses. Even then, these figures are typically muddled by an absence of like-for-like pricing models.
One vendor charges license fees per user (named, concurrent, or casual) and per module (or per bundle of functional modules in a suite). Another bases prices on server/central processing unit (CPU) size. And still another bases prices on its perception of how large (read "wealthy") the customer is, the likelihood of implementing a total functional footprint, and the total number of users the customer might ever want to have. What can one discern from all this? Such a scenario is truly comparing "apples with oranges," and then dumping berries into the mix. However, some vendors will rightfully say that they cannot simplify pricing because different customers want different pricing systems, and they have to do what customers want.
For example, many customers resent the notion of paying for functionality they are not likely to use. In some instances, even if a large corporation needs expanded functionally down the road, they will only pay for the modules they need at the time of selection. Lengthy implementations of (for example) financial management and consolidation, or human capital management (HCM) systems over several divisions and several hundreds (or even thousands) of users worldwide, may make an enterprise reluctant to embark on another lengthy implementation adventure right away.
Thus, a vast majority of business application software vendors still generate most of their revenues by selling their software licenses based on the number of named or concurrent users or seats, typically on a per module or per suite basis. They may also generate revenue based on an excessive "wall-to-wall," "all you can eat" functional scope. The accompanying implementation service, post-implementation service, and support and maintenance services also add to the "pot." These are all are priced as a percentage (and more often multiples) of the software license fees.
However, from the user perspective, there is a fitting analogy: in one trip to the store, no one will ever buy a lifetime's worth of snacks and coffee. We are selective, and over the course of a lifetime, we will buy different products based on what we feel we need or want. Software applications should be treated the same way. To return to our analogy: the stockpile of snacks will ultimately go stale, and the coffee will lose its flavor, or go rancid. Little is consumed, except hard-earned money.(see Application Erosion: Eating Away at Your Hard Earned Value). The same happens with software that is not used.
However, purchasing software la carte is easier said than done. The trouble comes from the "fine print" addendums in software purchase contracts, which are often longer than the main contact itself. These clauses are typically designed to protect the vendor from any future liabilities or to "nail" the gullible customer with extra costs. The fine print will customarily include a statement to the effect that the contract includes only the stipulated basic functionality. Any additional modules will use a different pricing structure, whereby the client will likely pay far more at the end of the day than if the whole application license had been purchased up front. Smaller enterprises (given their smaller number of users, and less complicated implementations), typically want most of the available functional footprint implemented at once, with the option to expand to additional functionality later. These customers might appreciate the option of "wall-to-wall" functionality up front.
Another pricing option variation is based on what users use, and not on what they can get. This is the so-called "pay as you go" option. Typically, enterprise software comes with parametric "switches" that can be set based on a need. For example, a small-to-medium enterprise (SME) user might set a switch to use multicurrency, consolidate financials, use warehousing management, or use standard or actual costing. Based on a contractual agreement, these switches can be set at the "software factory" to limit the functionality that is available to the user. If an enterprise decides later to activate a function, such as warehousing management, the enterprise would have to pay. While feasible, this requires serious contract management and tracking, and an argument could be made that SMEs that use less functionality require less support.
Service and Support Calls
This brings us to the next fine print item, the point which is possibly among the most controversial: service and support calls. With some large software customers reportedly spending obscene amounts of money just to patch their existing software, the cost of poor software quality is becoming painfully apparent to software customers. Vendors typically provide a short period of time—from ninety days to a year—as a "warranty period," within which software fixes are available for free. After that initial period, software customers must pay for service and maintenance, on an annual subscription basis, or on a per-incident basis. As a result, many customers feel taken advantage of, and those who select the solution are presumed "guilty" of paying for the vendor's ineptitude to deliver quality software in the first place.
From this vantage point, many wonder whether the urge to hastily implement these systems prior to the Y2K deadline was so big that it blinded common business sense. Consequently users have ended up on the losing end of their contractual rights, and have become the victims of exorbitantly high costs for enterprise software use, upgrades, and administration.
However beside user frustration, vendors are facing the pressures of cutthroat competition, which is pushing prices downwards. Users also have strong expectations that improvements in software quality should allow vendors to significantly extend the "free" period to something closer to the expected life of the software.
Software customers have a legitimate right to expect their vendors to stand behind their products for a few years or more. During this time, vendors should back product capabilities based on the user's requirements (these capabilities are all too often easily "promised" by aggressive sales personnel). This backing would also make certain that the cost of the software product would remain fixed (and known) during that time. Through this approach, software vendors would have more difficulty in passing the expense of poor quality software to their customers through arbitrary rate increases for software maintenance. Rather, they would have to focus on producing better software to reduce their support costs, in order to remain viable players in the market.
Business-related issues related to software use inevitably arise daily. These issues may result from flaws or bugs in the software, a misunderstanding about how the software works, or both. In any case, software customers want to be able to contact a qualified expert to discuss the issue and resolve it in a timely fashion, with minimal impact on their business. The customer does not really care whether the issue arises from a bug, user error, or lack of knowledge.
Software vendors need to provide unlimited access to support services, including experts trained in the detection and fixing of design flaws in the software, as well as having the ability to explain (in lay terms) how to get the software to perform the functions required by the customer. To that end, no one wants to plow through the fine print to understand how many free-of-charge calls are permitted. Instead, it would be more reasonable to allow for unlimited calls during a multiyear warranty period.
Then comes the dreaded 15 to 20 percent (or more) of nominal license fees for annual service and maintenance costs after the software purchase. Many customers wonder why they should cover the future developments of a few early-adopter customers, since they do not necessarily need additional functionality or the latest "bells and whistles" any time soon (this is what software vendors claim is the reason for these recurring annual costs). Their customers' grievance is akin to the irony of car insurance, where the majority of decent drivers have to pay for an inept few.
Software customers do not see these technological changes as changing the business value of their software, nor do they see them as a justification to pay more money to their software vendor. They are unwilling to pay their vendor to port the software onto a new operating system (OS) or server platform if the value provided by the software has not really changed. They might be willing to pay their vendor for more functionality if it drives additional business value, but even then, they want to pay only when the functionality is generally available and required, not while it is still in development.
Business processes and practices do undergo constant change (see What's Wrong With Application Software? Business Changes, Software Must Change with the Business). For example, changes in business strategy (such as shifts to lean manufacturing) can mandate changes to business processes. Regulatory changes, such as those stemming from the US Food & Drug Administration (FDA), the Heath Insurance Portability and Accountability Act (HIPAA), or the Sarbanes-Oxley Act (SOX), can also mandate changes to business processes. Software vendors have an obligation to keep their products from becoming obsolete even in these contexts, and customers have the right to expect that they can use updated products to address these issues, including reasonably easy and cost-effective upgrade processes.
One can only imagine the public outcry and revolt if car manufacturers decided to charge car drivers an annual fee—a percentage of their nominal car model price, say—indefinitely, for future developments! At this stage, software vendors are participating in a practice similar to that of pharmaceutical companies. Pharmaceutical companies justify the exorbitant prices of critical medications for consumers by professing the need to reinvest part of their hefty profits for future developments, but even in this case, customers know what they have to pay when they are at the counter. Maybe if enterprise software development could come up with a cure for cancer, AIDS, or Alzheimer's, or implement some other supreme benefit to humanity, then software users would also put up with the recurring service and maintenance costs.
SOURCE:
http://www.technologyevaluation.com/research/articles/is-there-a-panacea-for-enterprise-software-pricing-yet-18320/
No comments:
Post a Comment