By Harris Kern
Packaged software has long been used to perform standard corporate functions such as accounting, payroll, purchasing, human resources, and manufacturing. As technology has improved over the years, software packages have become more flexible, branching out from their standard fare and adapting more to individual business needs. Now, packaged software is assumed to be suitable for most core business functions.
With the arrival of integrated enterprise data systems such as SAP, many IT managers assume their data architecture can be built entirely around off-the-shelf software, and in-house capabilities can be abandoned or outsourced. But that is not always the case. Before you buy, make sure you understand the business implications of using purchased software. There are specific questions to ask and considerations to make before deciding on packaged software for specific business functions. If you can’t get the answers you want or the features your business requires, you might need to look into building your own software instead. Here’s a close look at the process of evaluating packaged software.
When packages make sense–and when they don’t
Packaged software works best for commodity functions that are slow to change and are not strategic to your business. The best example is basic accounting. No business should have difficulty finding an off-the-shelf accounting solution that will meet its needs, except for organizations that are institutionally unique in their accounting practices.
However, if you believe that a function is strategic or if your business model is unique, beware the packaged solution. Many companies have suffered by trying to fit inappropriate packages into their operations.
When is a business function strategic? When it’s a part of a process used to gain competitive advantage. For example, Federal Express spent millions to develop the Powership system, which allows customers to quickly prepare their goods for shipment and to quickly track packages throughout Federal Express’ system. Powership gave Federal Express a competitive advantage over UPS. If FedEx had used a packaged solution, the business practices embedded in that package would have been available to any competitor.
If you want to move ahead aggressively in implementing a new technology or business practice, you need to either carefully select a package that will enable that practice, or be prepared to write your own solution.
Selecting enterprise-packaged software is a difficult and time-consuming task. It’s not uncommon for companies to assemble task forces that spend months on a package selection, or to hire a consulting firm and spend $100,000 to pick a package. Here are some of the processes and selection criteria needed for a successful package selection.
Purchase cost must be carefully evaluated since software vendors have different pricing models. Some vendors’ price by connected user, others price by named user (even if not connected). Some price by platform, with installs on MVS mainframes priced higher than systems on NT, even if the number of users is the same. Also, be sure to ask for the total cost of the software from pilot to full deployment or you may be in for a shock.
Your cost must include annual maintenance and support fees, anticipated during the life of the system. These recurring fees must also include one-time upgrade charges, if applicable. The price of development and maintenance tools must be considered, if not packaged, with the software.
If you’re considering buying a total enterprise solution, carefully consider the cost of other modules you may want in the future. If you’re buying a general ledger system, will you also want a cost accounting or purchasing package from the same vendor? And don’t forget the cost of consulting and support.
Speed and ease of installation
Some software packages are tightly integrated in their functionality, while others can be more easily installed in modules. Some packages have better GUI-based tools to ease setup and maintenance. Some require learning a proprietary language or database. Others may have particularly long training periods. Talking with recent customers and reading the literature can be helpful in bringing these issues to the surface.
Keep the package as simple as is needed to do the job. Some packages have limited flexibility while others have every feature you may ever want. But remember that those features must all be maintained, users must be trained, and hardware must be sized to accommodate the features.
Technical and architectural issues
Packaged software vendors have different approaches to their architecture, and you need to be sure their architecture is compatible with yours. Some vendors provide APIs that will allow you to bolt on specialized or legacy systems. Others provide proprietary languages to customize the screens or functionality. Some vendors have built their systems with object layers to enable higher levels of flexibility between modules or between their systems and other vendors’. Here is a quick checklist of issues to discuss with every prospective package vendor:
- Support for open standards, popular operating systems, and hardware
- Development tools for modifying the data structures and input screens
- APIs to connect other packages or home-grown systems
- Support for popular system management tools, i.e., Tivoli
- Utilities for backup, performance management, and system administration
- Integration among modules for enterprise packages and the coherence of the upgrade strategy among modules
The essential challenge here is to involve the functional customer groups to gain their buy-in, while not confusing them with technical issues. This process can be daunting and time-consuming. If you have some money in your budget, every major consulting firm has a package-selection practice and can help you and your customers buy wisely. If you want to do it yourself, the following is a simple roadmap for package selection.
Initial requirements selling
Setting functional and performance goals for any new data system is the most difficult task. Customers always interpret their needs in terms of what they know, and I have seen customers drive decisions toward packages that look like their existing systems but with the rough edges knocked off. It’s IT’s job to make sure that the enterprise’s needs are being met and that the new system has the functionality and flexibility to be integrated into the corporate architecture.
In setting requirements, be sure that all participants understand the reasons for shopping for a new package. Are there functional deficiencies that will no longer support the business model? Is the existing system too old and does it cost too much to maintain? If you’re replacing a package, is it because the existing vendor is failing to keep up with evolving technology?
Selection of candidates
When the requirements have been decided, IT should produce a Consumer Reports-style chart for each candidate vendor summarizing how well each vendor’s capabilities maps into your requirements. At this step, disqualify any vendor that has clear deficiencies. Don’t be swayed by vendors selling futures or spreading FUD (fear, uncertainty, or doubt). Your goals are to reduce the number of packages to two or three candidates worthy of serious consideration. Complexity grows exponentially with the number of vendors. Now is the time to be tough.
Scripted functional demonstrations
Scripted demos have become a popular way to allow your functional customers to become familiar with the capabilities of the package, while learning more about their own needs as well. Every customer has a wish list of needs, but as they run through the scripted demos, customers begin to learn the trade-offs vendors have made, and they learn which features are “must haves” and which features they can live without.
This is also the time for you to begin learning about the vendors. How responsive are they to issues that arise? Do they approach problems the way your organization does? Are their people empowered? Do you have access to management when you need it? If they don’t impress you now, they won’t likely impress you later.
The goal of this process is straightforward: You need to determine whether your organization can live with the package in terms of your architecture and technical vision. If you can’t, don’t touch it.
Be sure you clearly understand purchase costs, maintenance fees in future years, training costs, upgrade costs, technical support costs, and what insurance you have in the contract to enable you to control those costs. Get all the costs on the table—including training costs, technical support costs, and upgrades to your infrastructure—before you decide. Going back to management with a bunch of gotchas later is not a career-enhancing move.
Living with packages
If you go with a package, remember that the vendor now controls the introduction of new functionality. If internal customers request changes to a package function, they may have to wait or, if the requested feature is not in the vendor’s product plans, do without.
Second, don’t underestimate the requirements for upgrades and maintenance. A major revision to a package can take days or weeks. Some vendors do not (or may not) use common data formats between releases. The result is that data may need reformatting and file structures may need to be completely rebuilt. Most vendors will supply conversion tools, but the job can be time consuming and, in the case of large enterprise systems like SAP, can require considerable advance planning for a successful upgrade or revision.
The final issue of living with packages is that you must assume the business risk of the package vendor. If the vendor goes into decline or bankruptcy, or is merged or sold, how will you maintain and improve the package and at what cost? The risk can be mitigated but never eliminated.
For more information on the Harris Kern Enterprise Computing Institute, visit the company’s Web site.