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.