Wednesday, May 9, 2012

Another Sworn Enemy of Lean (sometimes)....MRP

As discussed previously, sometimes, e-mail can sabotage your lean journey. In this blog, let's look at MRP (manufacturing Resource Planning) software. 

In 1999-2000, I led a team at my company to source, select, and implement an MRP package that would tell us what to buy, when to buy it, how much, what to make, what to ship, etc. This software package was going to run the company. Implementation took a solid year. And we paid cubic dollars for it.

According to Wikipedia, Material requirements planning (MRP) is a production planning and inventory control system used to manage manufacturing processes. Most MRP systems are software-based, while it is possible to conduct MRP by hand as well.
An MRP system is intended to simultaneously meet three objectives:
  • Ensure materials are available for production and products are available for delivery to customers.
  • Maintain the lowest possible material and product levels in store
  • Plan manufacturing activities, delivery schedules and purchasing activities
Sounds great! Unfortunately, it seldom works like you think. Garbage in, garbage out. If it said we had 50 widgets, we had 2. If it said we had 2, we had 50. After spending all this time and money, I went down my TPS enlightenment trip, and one of the first things I learned was the computer system was usually wrong, and it hides problems! I learned how to make demand visible with boards and colors so everyone could see what needed to be shipped today. We bought everything based on consumption using kanban. (we were always running out or had too much when the computer was doing the thinking!) Not to mention the darn thing refused to ship an order if one digit of a 12 digit lot number was entered wrong. The software is still in use, but it no longer "runs" the business.

I began to think of the computer as an employee like Tommy Boy (above). One with a drinking problem. Who stayed up all hours of the night and can't be depended on to run things. Someone you had to constantly babysit. (cycle counts, inventory adjustments, etc.). It was someone I could assign tasks to, but not really depend on. How about your company? Is Tommy Boy always right?


  1. It's Herbie Hancock... Hey I think you nailed it with garbage in an garbage out... I think software is a tool, it can be as powerful as you want it. Think of Uncle Ben from Spider man, with great power comes great responsibility. If you use the power the right way and also the way it was intended it can help more than it hurts. If you have enterprise visibility I think it is a good thing, you just need to be disciplined when you input your data. I think you can argue this one either way...

    Love Tommy Boy though!

  2. Thanks for that Kevin. We always felt like we were chasing our tail before we went visual, particularly in purchasing and receiving what we needed when we needed it. Thanks again, great food for thought for me.

  3. I've only been on the periphery of our MRP project at my current job. But from past experience working at a software house and my observations here, there needs to be a sort of astrological alignment for MRP to accomplish the goals you pointed out.

    First, the software must be robust and mature (fully vetted and debugged, from years of running on production systems). It should also have been written by programmers who understand the business need, not 'worker bees'.

    Second, it must be implemented by someone who has an intimate knowledge of both the software's capabilities, and the methodologies 'on the ground.' If those two opposing forces can't be reconciled by configuring the system properly, there will be a lack of flexibility that will only cause frustration.

    Third, there needs to be an on-site champion who will take full ownership of the software. Someone that can be the conduit between the materials manager and the MRP consultants. Otherwise the consultants (and the end users) are flying blind. This person is the one who should be making sure the input isn't garbage (which automatically makes their job the hardest of the bunch!).

    Lastly, the end user needs not only solid training, but motivation (management or otherwise) to actually use the software and not cut corners. This is probably a difficult line to walk, when reports aren't giving them what they need. Often, communication levels between the end user and the "champion" trail off. This is the weakest link in the chain, because the result is that the software ultimately doesn't provide what they need.

    It's easy to see how hard it can be for information to pass from the end user back up to the person who can actually solve their problem (programmer). It's like the old telephone game. But this issue is not exclusive to MRP.

    What makes communication breakdowns more pronounced with MRP is that (as you pointed out), reliance on the system isn't mandated. Survival mode kicks in and self-contained workarounds are invented, leaving the system in a half-baked state for potentially long periods of time.