The Keys to Cutting Long-Term Software Application Costs
What the RFP Doesn't Tell You
Companies do their best to cover all the bases when it comes to writing an RFP for a new customer system: weeklong demos, site visits, and more. But how many enterprises are truly clear about what each application will cost when 10 years from now it is reviewed?
It's a case of what you don't know can hurt you, because considerably more than half the total cost of application ownership occurs after the software is up and running. How many people are required to support and maintain the application? What will it cost to upgrade-and will upgrades be available? What is the opportunity cost associated with a more-versus less-complex marketing process? With the ability to access all of a customer's accounts within three seconds? With case management that lets fewer key account representatives handle more accounts?
Fortunately, getting the answers to just four additional questions before you release your RFP can make all the difference when to comes to minimizing your total cost of customer-application ownership:
How will you handle business processes that span multiple applications?
How much will it cost to tailor the application to your specific business needs?
How much will it cost to keep the application up to date?
Does the software quality meet your requirements?
Interaction between the customer system and other applications
Interactions come in three forms: interface, integration, and interoperability.
An interface is usually a one-way data exchange between two distinct applications. The data format is fixed and must be programmed on either side. Interfaces are suitable for periodic interactions, such as a daily upload of meter reads to the billing or billing (revenue) upload to general ledger, are fairly static and the least costly method of interaction.
Integration is required when the two applications must be synchronized more frequently. A customer address change needs to reach bill processing immediately. The utility customer service representative answering the phone in the afternoon needs to know that a customer was successfully hooked up that morning.
Interoperability is used for two applications that must seamlessly work together to accomplish a business process. To the end user it appears as one application; there are no manual hand-offs, no re-keying of data, no asking the customer for their account number when they have already entered it into the IVR system.
Customer expectations for application interoperability are increasing every day. But interoperability can be expensive to build, based on the underlying technology of the applications. And the biggest danger of building interoperability is removing the independence of the underlying applications. You don't want to lock yourself into a forced upgrade of one application if the other application has a new release with features you want to take advantage of in your business.
Making the application work for your business
How much will it cost to tailor the application to fit your business? That depends largely on which strategy is required to accomplish the tailoring: change, configuration, or customization.
Using the application as is, out-of-the-box, almost always means you must change your business processes. That adds risk, testing, training, and documentation to the project.
Configuration gives you a series of options from which you choose. But you don't touch the underlying code, as you do in customization. Altering code makes the application far more expensive to maintain, support, and upgrade. The best vendors and the wisest businesses avoid it.
Keeping software up to date
Most vendors say they offer upgrades. But look behind the curtain. To control upgrade costs, you should be able to:
upgrade each individual component of the application separately, without impacting any other component;
preserve all configurations you have selected;
preserve most or all of your integrations to other applications; and
use vendor-supplied, automated upgrade and testing scripts.
Check a vendor's existing clients and compare upgrade costs and time from vendor to vendor. Fast, low-cost upgrades can slash long-term application costs and enable you to retain an application indefinitely through many business and market changes. In addition, you can take advantage of new features and functionality sooner, continuously improving your business processes.
Quality counts
Bug-free software doesn't exist, but you can minimize the risk. You'll find fewer bugs in mature product with lengthy production histories. And the more clients served, the lower the risk of finding software problems.
But records vary greatly from vendor to vendor. As part of the RFP process, request vendors' customer support list of bugs and requests for enhancements. Review the severity of the problems and how long it takes to publish fixes or to include enhancements in subsequent releases.
Answers to the above questions will require some digging on your part. You'll need to take a close look at where your business is going and the market risks you face. But the savings available to those willing to plan long-term can make a considerable bottom-line difference.
Karen Edge is market and research strategy manager for SPL World Group. She can be emailed at karen.edge@splwg.com. Please visit www.splwg.com