Missing inventory? Blame the tech

I was the IT person for a manufacturing company during the Y2K switch. One of the business managers’ favorite mantras was that everything had to ultimately be “flexible,” and any rule could be broken if the situation demanded it. Where inventory was concerned, they were constantly robbing Peter to ship to Paul, and then wondering why their shipment to Peter had so many back-ordered items. This became my problem when I was tasked with creating inventory tracking software.

We had just chosen an ERP to replace some non-Y2k-compliant systems. The ERP implementation was slated to take two years. However, the inventory problems were serious enough that management wanted me to replace our existing workflow (paper-based data that was keyed into our legacy manufacturing system) with an electronic system right away. They wanted inventory movement handled by RF barcode scanners, and I was told to come up with a solution. I went with the ERP’s preferred data collection partner.

I designed the system so the interface on the RF scanners would be the same regardless of the back end. Until the ERP arrived, I had to interface the inventory movement to the legacy manufacturing system, hosted on a nonstandard obsolete platform that had been deprecated by the manufacturer.

The system worked well enough: Our inventory was the most accurate it had ever been (which still isn’t saying much). We gave the warehouse staff a thorough tutorial on how to use the RF scanner and track the inventory. However, we were still plagued with inventory losses.

When the new data collection system had been in place for a little over a year, quarterly financials showed that we were on track to lose over $8 million. Focus quickly turned to inventory problems and my inventory movement system. To combat the ever-increasing scrutiny, I designed a test of the system to show once and for all that the inventory system worked.

The plan was that we would run a program that would “move” every item of inventory to a dummy location called “Foo.” Then, on a Sunday when the factory was down, an army of people using the inventory guns would manually count and scan everything from location Foo back to their true location.

The first benefit was that our inventory would then be correct — all errors would be in Foo. The second benefit was that we would be running a huge amount of data through the system, proving its stability or exposing any weaknesses.

The test started. In addition to 8 to 10 of the normal warehouse workers, we had people like the CIO, the MIS director, the VP of production, and the controller running inventory guns. The process was to scan the Foo location (bar-coded on a paper for their convenience), scan the target location, scan the part number found there, then count and enter the quantity. Everyone else started scanning while I collected statistics about how the system worked.

Over the next few hours, our crew of about 25 methodically worked across the warehouse, “moving” inventory and generating data traffic in the system that was many times greater than that seen on a normal day. At the one-hour mark, I brought the first set of reports down to the floor. I was able to show that all of the data had transferred correctly. I could show that everyone had made a handful of errors, including “Larry,” who had spent his morning moving the inventory to the Foo location, instead of away from it — doubling the errors.

We corrected Larry’s errors and got back to work. Every hour I brought down the latest set of reports, showing that all transactions that showed up at the first stage in the system made it through correctly to the inventory database. On my fourth trip down to the warehouse, I ran into the CEO’s chief grunt, “Buck.” Buck didn’t have a job title — he just drew a salary and did whatever the CEO told him to do.

That day, he was wheeling a cart through the warehouse, loading it from a list written out on a legal pad. I asked him to stop and called everyone over. It turned out that one of our biggest customers needed a bunch of supplies for a project that day, and Buck had been sent to the factory by the CEO to get what was needed. We asked if there was any paperwork for this order, and Buck held up the legal pad. He assured us that this was OK, because he did it all the time.

Buck left the warehouse with over $20,000 in inventory. The scanners went back to work, correcting inventory that everyone knew, somehow, would be incorrect again very shortly.

Due to activities like Buck’s and other problems, inventory inaccuracy continued. Management was unwilling to change these practices (“We have to be flexible”) and soon fell to blaming my system again. I started looking for a new job, and in the two years following my departure, the company gradually laid off just over half of their employees and suffered major profit losses.

Creating technological solutions for business problems, documenting, and training others on those solutions is usually the simplest part. Getting others to actually follow new rules and procedures is not nearly as easy.

In the years since this project, business and IT both are more aware that the solution to a business problem is seldom just found in technology. A project of this magnitude requires business process changes, as well as fancy new software and hardware. No project can succeed unless you can get buy-in from both management and users, so it’s always a good idea to persuade the top managers of the importance of the rules and procedures and why they must be followed. Learn to speak their language — show them in their terms of ROI and profits. Whatever works.

This story “Missing inventory? Blame the tech,” was originally published at InfoWorld.com. Read more crazy-but-true stories in the anonymous Off the Record blog at InfoWorld.com.