Hello, tldr; What can we be doing to drive our Process MRP times down? Anyone else experience Slower times in the new version rather than Faster? Wasn’t sure if this really fit in the main area since it’s a bit of a ramble so I threw it in off-topic.
For context and as a disclaimer, I’m aware of all the safe harbor warnings at the EUG so I’m not expecting sympathy, but I was still very excited and a little let down after our upgrade.
Back in Spring or Fall 2023 (don’t remember the last one I was at, keep having to miss out lately ), at the Wisconsin EUG - if I recall, there was a mention of 85% on average speed increase to MRP, though admittedly I think it was mentioned there was one customer that was actually slower. I was very excited for this as our purchasing team would love to be able to generate new suggestions on their lunch break if it was at all possible to get down to those speeds. Unfortunately, looks like we were in that minority where our speeds got worse. We finally upgraded to 2024.1 this week, and though we aren’t sure the speed decrease is permanent (shifting resources from old server to new server to increase performance), we definitely didn’t the 85% time reduction average, not even close.
That makes me wonder, what sort of best practices were people using that helped them get this miraculous speed increases? Or what is causing some to take so much time? Too many dead parts? Too complex of BoM’s? Not enough layered BoM’s? Any suggestions for us that would help us drive our MRP times down and maybe get within a reasonable midday runtime length? Right now, our Process MRP takes around 3 hours. And even though it should be enough, we even have to run Generate Suggestions again later or it misses some deeper BOM level subassembly suggestions. So overall, prior to the upgrade we were running from the process set from 7pm to 12am and now we are running the process set from 7pm to around 1am after the update.
I’m curious the difference between companies that experienced the 85% increase in performance vs those that didn’t.
I think the WI EUG meeting with @timshuwy was about not processing parts without demand and the new Include Only Part with activity or min/safety checked.
If you have a lot of parts without activity and no min/safety, then you’ll likely see the benefits.
They can generate purchasing suggestions without running MRP. Also, if they are trying to generate suggestions for a specific part, or list of parts, part class, etc they can utilize the filtering options. This should go much faster than a full MRP run.
Hate to admit but I’m a little embarrassed I didn’t check the actual process configuration on the Kinetic version of the screen… A majority of our parts are dead parts.
@Mark_Wonsil is correct… you need to check this box he illustrated in order to gain the faster speed.
Note that not everyone has an amazing speed increase. some have only 50%… a few have had 10-20%… one had 99% (7 hrs to 4 minutes). This is ALL dependent on the makeup of your data structures in the BOM.
ALSO NOTE that this little switch that Mark mentioned, is available in Generate PO Suggestions. We have seen even bigger improvements in speed here.
Please report back your results with this switch flipped.
Part of it is user training and how they coordinate, our purchasing team tends to run solely off suggestions and have no clue what they are going to be suggested in order to do those filtered runs. We definitely could teach them to run it against their commodity, but not sure how long it would take in the current system.
There are also additional things that you can do to make MRP even faster… but you need to read about these, and understand the periodic extra steps.
Net Change - net change only looks at parts that changed… many people run net change daily, and then full regen weekly. This takes care of challenges where net change misses some weird types of changes (revision becoming active for example). Note that there is another process called “Net Change Needed” which you can run before each net change which makes it so you don’t have to run full regen.
Recycle Jobs. IF you have very complex BOMs or Product Configurators… this can really help, as MRP “reuses” the unfirm jobs that already exist, changing quantities and dates, but not changing the BOM structure (unless the revision changes).
I had one customer who reported that the new speedup checkbox only had a moderate speed increase, but when I suggested that he turn on net change and recycle jobs, the speed increase was more dramatic.
Preliminary results are in, with the checkbox enabled being the only change it went from 3 hour average over the last 4 days down to 35 minutes. Awesome! Still going to save the part dtl records and compare to the regular run.
I believe you. The way I understand it is like this:
Let’s say it takes 5 computer “cycles” to check to see if there is a min/safety or demand, and it takes 100 computer “cycles” to process a part for MRP.
The gamble is that more parts will use only 5 cycles instead of 100. If a part has a min/safety or demand, then it will take 105 cycles to process a part: 5 to check plus 100 to process MRP.
I am guessing you have very few “dead” parts, or most parts have a minimum/safety stock set.
Well I explained it in that thread, but it’s the nature of the business here. We sell one thing (but customized to death - ETO), and the BOMs are massive. That’s what takes all the time.
The new feature fixes death by 1,000 paper cuts.
Our MRP suffers from scythes.
(We do have plenty of dead parts, though. It did help that area slightly. But it’s minuscule compared to the BOM-copy routine.)
warnings at the EUG so I’m not expecting sympathy, but I was still very excited and a little let down after our upgrade.
), at the Wisconsin EUG - if I recall, there was a mention of 85% on average speed increase to MRP, though admittedly I think it was mentioned there was one customer that was actually slower. I was very excited for this as our purchasing team would love to be able to generate new suggestions on their lunch break if it was at all possible to get down to those speeds. Unfortunately, looks like we were in that minority where our speeds got worse. We finally upgraded to 2024.1 this week, and though we aren’t sure the speed decrease is permanent (shifting resources from old server to new server to increase performance), we definitely didn’t the 85% time reduction average, not even close.
A majority of our parts are dead parts.
Yessir!