Having just gone to the CWG (configurator workgroup) for the first time in many years, I was reminded of my most famous story. My friend Barry Scott Walton even told the story in his presentation. He was nice enough to remove the names, to protect the guilty. Some of you probably even remember this story… It’s not the peanut butter piehl story, but perhaps I’ll share that one too someday… This was the story of how Mike Piehl shut down MRP because I used very complicated BOM dependencies.
This was back when I worked for ADC Telecommunications and there was a mad scramble to get all of our CTO product lines converted onto to SAP before the dreaded Y2K. Well, I was frantically working on product lines, and of course pushing the envelope, because no one ever said not to. ha ha ha. It all started on Wed. I still remember grumblings of MRP being really slow, and wondering if I had done anything. At the time, I couldn’t think of anything I did… thursday came, the same issues were still occurring. Then Friday, it became critical. MRP hadn’t finished in 3 days, and no one seemed to know why. After lots of digging, working with planning, IT, and even calling SAP’s platinum hotline, we narrowed down the issue. We had created about 30 material variants and added a forecast to them. In a normal world, this wouldn’t have been an issue. But in my design, I used every tool I could in the BOM to make things work. Well, my design was spot on. The problem, which Barry later explained to me, was that MRP doesn’t read complex dependencies in the Bill of Material well. And when I had a bunch of material variants, all with these complex rules, and then it read them over and over and over (because of the forecast)… well, let’s just say, I become famous.
As soon as Barry explained the MRP issue (which in my defense was never documented anywhere in SAP), I quickly found a work around to get me by until I could rework all of the selection conditions. I moved my variant table to a database table. Now, I do not recommend this approach because you lose the tracability, but we had to do something quickly, and this gave us back the performance to get MRP running again (and still forecast those 30 parts).
The work took significantly longer, because I pulled all of the complex logic out of the selection condition, and moved it to the configuration profile. This meant more characteristics at the top level, but the trade-off was well worth it.
To this day, I encourage all of my clients to keep it REALLY simple in the BOM. SAP has done better in adapting MRP to handle variant configuration rules better. But, in my opinion, you want the configuration profile to do all of the heavy lifting anyway, so this approach won’t steer you wrong.
Anway, learn from my experience… Keep your BOM rules simple… don’t add tables, don’t do complicated calculations… just do simple assignments. You’ll thank me later =)