MRP Does Work … A Real Story
Several years ago, an electronics original equipment manufacturer company hired me to salvage its investment in an MRP system. The company had recently been awarded a large contract on the condition it follow an aggressive timetable for the product launch.
After the annual shutdown, a group of concerned employees was waiting for me in my office. The buyer informed me that MRP failed to generate the requirements for the new product and suggested MRP “may work for some products but just doesn’t work for ours.” One of the planners also explained that MRP had generated requirements for old part numbers but the newly created part numbers were missing from the MRP run.
“Are you certain you loaded these new numbers into the part master?” I asked the planner. Without a word, she handed me the part master maintenance log for the last workday before the annual shutdown, which showed that all the new part numbers were loaded properly. Perhaps we entered the wrong buyer code on these parts or perhaps purchasing failed to load any buyer code at all,” I said. But the planner handed me the maintenance record for the item vendor file with all the buyer codes highlighted. “I entered them myself because I was afraid purchasing would forget,” she explained.
I had one more possible explanation for the missing requirements. “Did we fail to load a lead time?” I asked the group. “A blank in the lead time field functions as a zero, and MRP will tell us to order a part in the same time period as is required if no lead time is loaded.” The planner held out another piece of paper to prove the lead times were loaded. She also assured me the dates in the master schedule and MRP were in sync and every data element she knew to check were all loaded correctly.
Far in the back of my mind, I struggled with another explanation, something I had ome across years before. But my memory was fuzzy.
“Given how rushed we were to begin our annual vacations, I’m surprised all the data got loaded properly,” said the IT Manager.
“Describe the daily MRP run,” I asked eagerly.
“We run MRP on third shift after all the second shift transactions are completed,” he explained. “After the preliminary jobs, we launch the MRP run itself, and it usually takes about four hours.”
He then described a series of preliminary jobs that updated the data MRP needed to function. Because these jobs were launched by a computer operator in a predetermined sequence, I suspected that our lone third shift computer operator, the last person to start his annual vacation, had taken a shortcut.
The IT Manager completed his list of preliminary jobs. “After updating effective dates for engineering changes, we run the low level calculation,” he explained.
“That’s it!” I said, “I’ll bet the missing parts have no low-level circulation. The field is blank; telling MRP not to search for requirements because they don’t appear on any level BOM.”
“I suppose it would work that way if a part ended up with no low-level calculations.” said the IT Manager. “But why would the program fail on just the new part numbers?” he asked.
“Because we didn’t run the program the last time we ran MRP,” I replied. “Our third shift operator dropped it to get a jump on his holiday.”
“But if he hadn’t run this preliminary program, why did MRP generate requirements for anyhting?” asked the buyer. “Why aren’t all parts missing requirements?”
“Because if you fail to run the program, it will use whatever number it has from the time before,” the IT Manager answered. “But for these brand new part numbers, there was no time before. This scenario would seem to fit the facts.”
He began searhing the computer files for confirmation, and soon announced, “I’ve checked the job log for the last day before the annual shutdown, and the low level calculation program was not run.” The mystery was solved.
“So does this mean that I should just dump today’s MRP output?” the buyer asked. “No,” I replied. “Your output is correct for the part numbers it contains. It’s just missinga few. The missing ones will be there tomorrow, right?” I asked, looking at the IT Manager. The others filed out of my office.
“Right,” he replied and added, “If there are no new BOMs loaded to cchanges to existing ones, you can drop the low-level calculation without affecting MRP.”
“Of course,” I replied. “I’m sure that’s what our third shift operator was counting on. He didn’t figure on BOM maintenance happening the last day before the annual shutdown.”
As he left, I realized I had gained an ally. The inventory planning group had always supported me and now IT was behind me, too. You never know how alliances will be forged. When people are involved, you just never know.