Go back two years plus. The company had been using its first system for almost three decades, so MIS and users assumed that they could select a new system without encountering any problems. To paraphrase an ex Secretary of Defense, they didn't know what they didn't know. They didn't know much about systems other than their own, heavily customized one.
The search team created a very skimpy list of needed and desired features, based on their old system. It was so skimpy that entire functional areas were "described" in less than ten words; it was really an outline. The team assumed that all the systems they would investigate would have all the features not on their list.
Reading through the industry's most widely-read magazine, someone found a list of software packages. The search team assumed that every system on that list was specific to their industry. They also assumed that there were no other appropriate systems other than those on the list. Wrong; had they done a little research they would have found a few more worth exploring.
The skimpy list of desired features, along with some questions, was sent to several vendors whose names were on the list in the magazine. But, the team omitted some key questions, because they assumed that they could get that information later -- which they forgot to do.
Using the skimpy list of system needs as the agenda, several vendors conducted demos. The team assumed that vendors would know from the list which features and functions to address in detail. But the list was so general that the vendors presented what they wanted to present, not what was expected by the distributor. As a result, some of the presentations were considered poor, and the team then made a classical mistake -- they assumed that a poor presentation meant that the system was poor. They eliminated at least one system that would have been a better fit than the one selected. Use of the skimpy list also resulted in demos that did not identify the need for costly modifications, although at least one vendor promised to make several mods for free.
In the final selection process, the team eliminated one system with a better fit and higher cost, because they assumed that the less expensive systems would provide the same functionality. (A close look at the features and functions of the three finalists revealed that both eliminated systems would not have needed most of the mods needed for the selected system).
The contract with the selected vendor did not list the mods that that vendor had promised to make for free. The team assumed that the mods would be made for free, which happily they were, but it could have been otherwise. Although the vendor had told the team to assume that modifications would come to about 10% of the license fee, no one had even attempted to identify the chargeable mods; obviously, no list of mods appears in the contract.
Shortly after the conversion and installation process got underway, the need for costly mods surfaced; many of the unexpected mods required unexpected extra, billable training. The principals were aware of the vendor's earlier assumption that modifications would cost about 10% of the license fee, so they didn't pay attention to the bills, nor keep a running total -- until it was too late. They assumed that the team would monitor the cost of mods, but the team was way too busy preparing for the new system.
There have been so many modifications -- and there are more coming -- that it is questionable whether the distributor can use the vendor's software upgrades without an expensive retrofitting for each upgrade. Maybe, for technical reasons, they couldn't use upgrades at all.
A few brief lessons from this costly story. Define system needs in excruciating detail, and include features and functions that might be needed in the future. If there is some doubt about being able to create such a definition, seek professional help. Very few software directories are industry-specific, nor do they list all software that is available (because some vendor refuse to pay "tribute" money that some publishers demand for a listing). Require that vendors address every requirement in the list of system needs. Read each vendor's response to the needs definition, and identify problems and questions; address the problems and questions before scheduling any demos. Be cautious when comparing costs of different systems -- some vendors include for free modules that others charge for. In the contract, get specific performance guarantees, such as the cost for modifications; even if modifications will be free, list them in the contract.
©2009 General Business Consultants, Inc.
About the Author
Dick Friedman is a recognized expert on information technology (IT) for distributors. He has 30+ years of experience helping foodservice distributors acquire and use IT in offices and warehouses. Dick does NOT SELL systems or software, or provide comput¬ing services. He helps select the right ERP and WMS systems, and warehouse technology, while avoiding the pitfalls and problems; and he obtains contracts with specific performance guarantees. Dick is a contributing author to IDReport. Call 847 256-3260 for a FREE consultation, or visit www.GenBusCon.com for more information or to send e-mail.
Members help make our journalism possible. Become a Restaurant Business member today and unlock exclusive benefits, including unlimited access to all of our content. Sign up here.