THE RISE AND FALL OF MRP


Back in the early 1980's as we were participating in the formulation of an MRP II system for one of the of the major software houses, we were excited. ....after all, this was slated to be a package of packages, providing most of the features that we wanted at least in the current MRP circles. At the time, most MRP applications were custom-designed and custom-programmed, simply because standard packages weren't available. And...most of the support systems at the time were standalone, batch, and the idea of having a fully integrated real time application was promising.
Material Requirements Planning had been around since the mid-1970s and was reaching its heyday, receiving a lot of hype. Computerization made it possible to crunch through thousands of records in an effort to provide a more effective way in managing materials. Materials and MIS managers were embracing MRP, and championing its implementation to assist in achieving primary objectives: improving customer service, inventory investment, and plant operating efficiency. It would, according to the proponents, help us plan priorities for the shop, determine when and how much material to order.
We saw the vision of a system capable of helping us manage our inventories: move materials through the plant, keep track of parts, so that we would know....the status of a job,.... what parts were missing, ....when they would arrive,....what was on the shelf, etc. The emphasis was on control, and our new system would provide the means. Little did we know what we were in for.
A Trojan Horse

What followed was typical to the experiences of many in implementing MRP. The package didn't do what we thought it would; the next version of the software wasn't anything like the one we were working with. Phone call after phone call continued in attempting to get answers to technical questions....this didn't work,... that didn't work. The documentation was incomplete (or non-existant). We felt like we experienced the toils of war throughout the endeavor. The project schedule lengthened continually, and the budget was overspent, but we stayed with it determined to win the battle. Typically to most purchasers of this revolutionary product, we justified the package through inventory reductions.

But when the software was installed, inventories weren't reducing, and we began to discover the reasons. First we had to have ninety-five percent accuracy in our bills of material for the system to work. And..98% accuracy in our inventory balances. Then, we needed to "close the loop", to provide feedback to the planning process. And we needed a heavy dose of education and training to ingrain the new philosophy in the masses. Then we had to diligently deexpedite the materials we didn't need (and most of us did not under fire), or inventory would rise.....and it did. Customer service didn't improve, and we certainly didn't gain better control of operations. It seemed that the people who had the most to gain were the ones with a vested interest in MRP, particularly the educators and the software houses.
A Fundamental Weakness in our Plan
Today, MRP horror stories are so common, this one seems like ancient history. Article after article has been written on the merits of MRP, MRP vs. JIT, etc. Certainly it's easier to review our experiences in hindsight, and more difficult to anticipate while facing the unknown, but hopefully we can learn from hard experiences. It took a long time for us to realize how far off course we were. Instead of focusing in on the real causes of our problems, we were guilty of treating the symptoms: trying to control an unwieldy manufacturing organization.
It's tough to reason a war when you're in the foxhole, and bullets are flying over your head. But today we can look back and contemplate our mistakes. The lesson that we learned is fairly simple in thi