Before we discuss the components of vendor pricing we should dwell for a moment on value rather than cost. To value something is to estimate it’s monetary worth.
As any of you who have been active in the vendor marketplace know, vendors and their products are not the same so understanding what you are getting for your dollar is as important as how many dollars are required to pay for it.
In comparing vendors it is necessary to compare several aspects of their offerings before you can determine the best deal for your organization. An obvious example is functional footprint; if one vendor’s solution includes a viable print solution but another does not then you need to factor that into the price comparison.
Similarly, if vendor A requires that you buy and install a third-party product—say an rdbms—in order to run their software, but vendor B does not this fact needs to be accounted for in the price comparison.
There also is the more nebulous issue of how much your organization values one function over another. Vendor A may have a more functionally-mature billing system than vendor B, but if your organization does only simple, direct billing and therefore does not need all that additional functionality the distinction may be irrelevant.
So, before you consider the actual pricing that each vendor is offering construct a framework for how you value what is being offered. And a final comment for now on value as opposed to price: Market results show consistently that carriers do not buy on price alone. The least expensive vendor does not always win, and the notion of the “best price” does not necessarily equate to the lowest price; rather it equates to a combination of understood costs, estimated value, and perceived risk. Carriers will pay more for added value and they will pay more for lower risk.
That said, it is of course important to understand the cost of purchasing and installing vendor software. Software costs have three or four components depending on whether or not the business deal involves an ASP arrangement.
The license price is the cost a carrier pays to a vendor for the rights to use a defined set of software for a defined purpose for a defined period of time. The defined purpose is usually more concerned with what the carrier cannot do, rather than what it can do. For example, the defined purpose will usually exclude the use of the software for anything other than the carrier’s core insurance business and also may exclude the processing of business from acquired carriers.
The usage language may be broadly written, granting the carrier an enterprise license, but may include additional costs as the written premium processed on the system increases. The language may be price sensitive to the introduction of new lines of business and/or new states.
Two important features to understand are: Does the license grant access to the source code? Is there a license term or is it perpetual? The provision of source code is obviously important if the carrier intends to take over maintenance of the system and become independent of the vendor.
This is a common feature of legacy “package” environments where in-house staff has so heavily modified the system that taking vendor maintenance releases becomes extremely difficult. However, with modern configurable software, access to the source code is less of an issue. Configurable systems include a toolkit which is used for maintenance and enhancement of the application. It is access to this rather than the underlying source code in which the tool kit is written that is important.
On the issue of term, it is important to know if the carrier is being granted a permanent license to use the software or whether a new license term will be required in the future, which carries a new license fee.
The most common arrangement in software pricing in our market remains the license fee/maintenance fee model. A maintenance fee gives the carrier access to ongoing software updates, enhancements, bug fixes, and certain defined levels of support. In this model the maintenance fee usually costs about 20 percent of the license fee and runs for five years.
It is important to know what happens at the end of the initial five-year term. In many contracts the carrier can choose to non-renew the maintenance agreement and continue in-house support. Part of this decision is the perceived value of the agreement.
Carriers have commonly complained that the cost of maintenance bought them limited value in terms of added system capabilities. The carrier should understand what is included in maintenance and what is not. For instance, one area of contention is compliance changes, which may or may not be included in the maintenance cost. Secondly, the carrier needs to understand how and when specific enhancements areagreed and scheduled into releases.
Often the largest cost component of a major system acquisition is implementation services. It also is the most difficult to estimate in a reliable way for obvious reasons.
The license fee is for something that already exists (we sincerely hope), and the maintenance fee is pretty much a function of the license fee. But the implementation cost is based on project estimates for something that has yet to be done, and which therefore carries significant risk.
At its simplest, the implementation cost estimate is an estimated number of service hours multiplied by an hourly rate. The hourly rate is the only concrete number we are dealing with at this point in time and many carriers focus significant energy on negotiating this number down. Doing this before an overall estimate has been provided is somewhat self-defeating and allows the vendor to give on hourly rate only to make up the difference on hours.
Also, these costs are seldom fixed price. Rather, they are estimates that, while they may be written as “not to exceed without written permission” will still be exceeded should they prove inadequate. The reassurance afforded by a fixed price contract is also somewhat illusory.
Two facts about fixed price are: The vendor will pad the numbers because the perceived risk has shifted to their side of the ledger, so the initial costs may be greater; second, and more important, if the fixed price proves inadequate the vendor will return looking for additional money.
Should this situation deteriorate into legal action the carrier had better have a tightly defined set of agreed deliverables, along with a demonstrable track record of keeping their end of the deal in terms of delivering requirements, testing, etc. in a timely manner, and without changing the scope. Otherwise it’s hard to hold the vendor to a fixed price deal.
Maybe the best insurance in terms of holding to the implementation cost estimate is to focus hard on the vendor’s implementation track record and their knowledge of your business during the selection process, rather than trying to negotiate terms that appear to shift risk to the vendor and away from the carrier.
But what if an outsourcing deal is part of the mix? How does this affect the pricing structure and overall cost?
There is no one single answer to this question. A vendor may blend the license and maintenance fees into the monthly processing fee, or keep them separate. The monthly processing fee will probably be a function of the breadth of services being provided and the volume of business being transacted on the system.
Volume may be measured in various ways, the most simple of which is, again, written premium processed, but it may be calculated on record counts or even on certain transaction counts. An ASP deal will also involve certain minimums to cover the vendor’s set-up costs.
These minimums may apply one time to the system start up or may also apply to new states and/or products. Again, read the fineprint and build a spreadsheet that predicts costs in various growth scenarios.
There is no overall rule of thumb as to how much a given software acquisition and implementation will or should cost for a given shape and size of carrier. The carrier can, however, get prepared and educated relatively early in the selection process by asking for standard terms and conditions and for initial implementation costs.
Any vendor on a shortlist of three to five should be prepared to furnish these initial estimates and also to explain how their pricing structure works. This allows the carrier to begin to estimate an overall cost and also to compare how the vendors differ in their pricing approach.
The carrier should understand that what they get initially is the “list price” for each type of cost. Vendors will often negotiate significantly lower prices in order to win a client, but as we noted earlier it is incumbent upon the carrier to make sure that they are really being offered a discount, and not merely a disguised cost shift.
As always the important phrase is “buyer beware.”
The content of “Shop Talk” is the responsibility of the author. Views and opinions are those of the author and do not necessarily represent those of Tech Decisions.