Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Evaluating Packages
Selecting enterprise-packaged software is a difficult and time-consuming task. It's not uncommon for companies to assemble a task force that will spend months on package selection, or to hire a consulting firm and spend $100,000 to choose a package. This section briefly discusses some of the processes and selection criteria for successful package selection.
Selection Criteria
Every company needs to develop its own requirements for the selection of an enterprise software package. But many of the issues in selecting a package are common to everyone. This list may seem sophomoric, but I've seen many horror stories of companies that were naïve in their purchases and paid a heavy price in implementation.
Cost
Purchase cost must be evaluated carefully, since software vendors have different pricing models. Some vendors price by connected user, others 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. And 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 anticipated one-time upgrade charges if applicable. The price of development and maintenance tools must also be considered, if not packaged with the software.
If you're considering buying a total enterprise solution, carefully consider the cost of other modules that 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
It's difficult to quantify the costs of speed and flexibility, but they are very real and worthy of due diligence with any prospective software vendor. Depending on the sophistication of your IT organization, there can be significant differences in the ease and speed of installing different packages. Some 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.
Functionality
The old KISS rule ("Keep It Simple, Stupid") is still the best—keep the package as simple as needed to do the job. Some packages have limited flexibility while others have every feature you may ever want. But remember that all those features that make your customers say "gee whiz" must be maintained, users must be trained, and hardware must be sized to accommodate the features. A colleague of mine recently installed a new financial package in a division of a large natural resource company. He picked a fairly basic package, with simple functionality. At the same time, another division selected a more complex and feature-rich package from a competing vendor. The simpler package was installed in two-thirds the time for half the price.
Technical and Architectural Issues
Packaged software vendors have different approaches to their architecture, and you need to make sure that their architecture is compatible with yours. Some vendors provide APIs that 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 those of 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 homegrown systems
Support for popular system management tools such as Tivoli
Utilities for backup, performance management, and system administration
Integration among modules for enterprise packages, and the coherence of the upgrade strategy among modules