Simple Glitches Led To

 
 
By Larry Barrett  |  Posted 2002-11-01 Email Print this article Print
 
 
 
 
 
 
 


Major Downtime">
Simple Glitches Led To Major Downtime

Fields says he couldnt begin to guess how many times a simple disconnected or damaged serial cable brought production to a standstill. Sometimes it would happen twice or more a day. Sometimes it would happen only once a week.

With a dozen plants operating throughout the U.S. and Mexico, Fields says it seemed as though there was always a problem with some line somewhere in the organization. The management team demanded an immediate improvement.

When one line was down for a considerable amount of time, HON would have to adjust on the fly by having other lines pick up the slack. That not only eroded HONs overall on-time delivery performance, it also caused redundancies in instances where inter-plant communications fell apart. When the line would return to service, workers would race to continue a run of a particular product only to realize later than another plant had already taken care of that weeks shipments.

Then HON would be stuck with a bunch of inventory it couldnt move, not to mention the additional overtime and regular pay it shelled out while the line was inactive and then later when it resumed production.

"They (management) didnt care about the cost or the technology or any of the details," he says. "They just told me to take care of the problem. We couldnt afford to have these lines down anymore. Period."

The old system was composed of hardware that included serial cables, disk drives, printers, bar-code readers and dumb terminals, which basically only provided a video display and a keyboard. When an order was scanned through the bar-code reader, the specifications for that product were printed out and given to line workers. On the software side, a crude in-house program was developed to record what products were being manufactured and to transmit that data to a Unix server.

"We had a dumb terminal that could tell us what wed made and what we needed to make, but it couldnt tell us what went wrong with the system when it crashed," Fields says. "We needed a way not only to leverage the information we were creating on the lines, but also a way to monitor the system to identify and resolve technical problems as they arose."

Fields says he and the rest of his staff looked into either going with Microsoft Windows or even a version of MS DOS to upgrade their manufacturing systems—clearly a safer and more popular choice back in late 2000—or take a gamble on the emerging Linux operating system.

"If we had made this decision based on risk alone we wouldnt have gone with Linux," Fields says. "It was pretty new and, frankly, had we not seen the level of commitments being made by IBM and other big-name hardware and software vendors, we wouldnt have gone in this direction."



 
 
 
 
Senior Writer
larry_barrett@ziffdavisenterprise.com
Larry, of San Carlos, Calif., was a senior writer and editor at CNet, writing analysis, breaking news and opinion stories. He was technology reporter at the San Jose Business Journal from 1996-1997. He graduated with a B.A. from San Jose State University where he was also executive editor of the daily student newspaper.
 
 
 
 
 
 
 

Submit a Comment

Loading Comments...
 
Manage your Newsletters: Login   Register My Newsletters























 
 
 
 
 
 
 
 
 
 
 
Thanks for your registration, follow us on our social networks to keep up-to-date
Rocket Fuel