Managing Software: The fatal flaws of software
Dealing with software vendors can be difficult. You need to understand what the system can do for you and they want to tell you all the great things that make them look good – the two lists usually do not agree. Your challenge is getting vendors to focus on what you need and what makes you money. It is important to be aware that most systems have flaws and these flaws can be fatal if they impact the key requirements of running your business.
Application software requirements differ by food category. The requirements do not differ in the administrative applications; they differ in the operational applications. Issues exist in the supply chain. Issues exist in production. The issues that make a difference are details. If you get the details wrong, the system will not work for your business. If your business needs certain functions and the software you select does not adequately provide these functions, the software has fatal flaws. Although an application software system may fit for 95% of your requirements, if the 5% of requirements that make up the fatal flaws are not provided – total failure may result.
One example is catch weight. Some products are prepackaged but priced by the pound, for example meats, cheeses and some fruits and vegetables. For these items, records and calculations must be based upon two sets of figure with different units of measurers—the number of units (cases) and the weight (pounds). The retailer orders a number of cases but the price is based on the pounds actually shipped. The manufacturer’s inventory, costing, planning, and other functions must reflect these two ways of accounting for the product. Since it is the way these businesses work, it is a fatal flaw. No catch weight means no selling in these markets.
In the meat category, a slaughterhouse is the classic example of an inverted bill of material requirement. While traditional bills assume that many items are combined to produce a single end item, a slaughterhouse starts with a single item (an animal) and produces many end items (various cuts, plus feathers, bones, etc.) Few application software products can model the inverted bill and even fewer can fully support the full operational and analytical needs stemming from this very basic requirement.
Not all food categories have it as tough as meat. For example a beverage bottler has a traditional bill of material, works with discrete quantities, and has few fatal flaws. Bottlers have a wide selection of application software products that can support their needs.
How bad can it be?
What are the results of underestimating the impact of the fatal flaws? A meat processor, which will remain nameless, recently embarked on an application software project. Of course, catch weight was a must have—a fatal flaw for their business. They asked the software salesman if the software had catch weight. After having to explain catch weight to the salesman (a bad sign), the salesman said “no problem.” It later proved that the salesman thought that catch weight was only a simple pricing issue. The meat processor did not probe into the details, was satisfied that catch weight was available, and signed a contract.The result: the project overran the budget and missed the schedule significantly. When the true nature of catch weight was explored the “no problem” reply took on a new meaning. The meat processor had to write a significant amount of customer code just to get pricing working correctly. They decided that they could not afford to do a complete job for inventory, costing and planning – which were key objectives of the project.
What was the result of not respecting their fatal flaw of catch weight? They experienced higher cost; a longer implementation cycle and now they will have a higher long-term cost of ownership to maintain the custom code. They also cannot afford to take future releases from the vendor.
Avoiding the trap
How could this meat processor avoid the fatal flaw trap? The answer is in the details. Seek out the fatal flaws for your category and your business. This may be more difficult than it sounds because people living inside a specific category and business may not understand what makes them unique. To them, what they do is normal — doesn’t every company need catch weight?How can you get help? Other companies in your category who have been through an application software implementation have scars that can be valuable. Consultants that have real experience in your specific category should know the issues. Ask the vendors, “What makes your product good in our category?” Ask enough vendors and you will gain insight into what the vendor community thinks are the fatal flaws. If a vendor understands your category and has a product that works in the category, they will know the issues. The really focused vendors will have a document that spells out these issues for you.
Make the vendor prove they understand the issues. Walk through the details of your requirements with knowledgeable people from the vendor. If the vendor understands and can satisfy your needs, it will come out during the discussions. If they do not fully understand the issues, they can never provide a solution that works.
You need to actually see what you are buying. This is common sense, but going into the details of a full package is impossible. Go into detail on the fatal flaws and actually see the product doing the things that are required. If a vendor tells you it is the next release, a red flag should go up. Is the vendor close enough to your category? Get comfortable with their claim. Ask to talk to the designers. Ask to see written materials that explain both the requirement and how it will be implemented in that next release.
Getting outside help for your implementation? Find a service organization that has experience in your category. Just because someone has worked in bottling does not mean they will understand sugar beets.
