I just got some encouraging news from Hal Vandiver, executive vice president of business development for the Material Handling Industry of America. He tells me you folks are going to be buying material handling systems this year. He cited the new Material Handling Equipment Manufacturing (MHEM) brief just released by MHIA (go to www.mhia.org). It expects capital spending to improve by 4 percent to 5 percent compared to 2002. That’s based on the improvement in your corporate profits.
So does that mean I’ll see you at McCormick Place in Chicago for ProMat? I hope so. But before you ask your CFO to cut you a check for whatever it is that knocks your socks off at the show, you should be able to assure him or her that you’re not investing in a lemon and that, in fact, the investment will return to your company’s coffers very soon — two years, at most.
How do you avoid lemons? By not planting them in the contract with your vendors. John Usher, a professor in the department of engineering at the University of Louisville, told me he’s reviewed many flawed contracts from material handling projects. They all have common elements:
• Incorrect terminology;
• Non-standard methodologies;
• Incorrect calculations;
• Poor definitions of failure.
That last one is the most problematic, especially when it involves a complex material handling system. What you consider a failure might not be thought of as such by the system provider. In explaining this to me for our Automation report, Usher used a five-vehicle automatic guided vehicle system (AGVS) as an example. Consider this: If a single vehicle in this system were to fail, is this a system failure?
“Probably not, if the repair takes only 16 minutes, “ Usher told me. “But what if repair takes 16 weeks? Generally, for complex systems, failures should be stated in terms of specific component failures or be related to system performance. If a vehicle fails to operate, that's a system failure. Or if throughput drops below 200 packages per hour (for any reason), that's a failure.”
The point is, both customer and supplier must agree on the definition of "failure." The same is true of software. Any good contract should include sections on warranties and remedies as well as testing and acceptance. Tompkins Associates, the Raleigh, North Carolina-based logistics consulting firm, says the contract should state clearly who made the warranty and to whom, what may be excluded and the remedies available and procedures for obtaining the remedies. It should also specify:
• The time allowed for the vendor to correct breaches of warranty;
• Method of repair;
• Location of warranty services;
• Any warranty extensions due to ongoing error correction.
Testing and acceptance specifies the method of testing, test data to be used, where test data will be sourced and responsibilities of the vendor and user. It should include a well-defined process for identifying and communicating errors. Tompkins emphasizes the need for explicit acceptance criteria.
MHIA’s optimism about the economy is good news, but it’s up to you to take your share of the spoils. That means making the most of your automation project by sharing authorship of its fine print. Optimism’s fine, but it can be snuffed out quickly by terrorism or war. Make your success bulletproof by prevailing in the war of words.
Tom Andel, chief editor, [email protected]
