Rant - MRP bottlenecking (Waiting for next part)

Epicor ERP 10
1

MRP takes forever. I know, earthshattering news.

What I found today is that I have a kind of unsolvable problem. Basically, our sales backlog is so lopsided to two part numbers that using multiple process in MRP has a really finite limit of getting any more efficient.

Here’s the situation.

Roughly 100% of the revenue in the main plant comes from engineer-to-order, make-to-order trucks. An order might have dozens of lines for the same exact truck, but they are all quantity of 1 and make direct. (It’s so we can gauge the margins and schedule things. And each is tied to its own Project and always will be.)

So I ran MRP on 6 processes and took the MRP logs, all 890,000 rows of them, and made me a pivot table. Process 3 gets hammered. It actually has the fewest level-zero parts, but by a longshot it has the most make-direct order lines (and thus unfirm jobs) - by a factor of 2 or 3.

image

FYI, I did use Recalculate Part Low Level Code (aka conversion 580) ahead of time. All the truck part numbers are level zero.

When MRP runs multiple processes, all processes have to finish level zero before anyone can move to level 1. Makes sense, after all.

But while five processes have been done for hours, Process 3 is slogging away.

And the others are “Waiting for next part…” Here’s the log of Process 4:

Expand for pic of log

image
image707×1024 57.5 KB

Almost 8 hours of sitting around until Process 3 is done with level 0-0.

Each one of these trucks has a BOM that results in about 1700 rows of JobMtl, so these jobs take 2-3 minutes each for MRP to create. It actually goes the fastest in that time when the one process is running solo.

Not to mention deleting all the unfirm jobs is apparently NOT a multi-processor task, so that alone takes 5 hours.

I don’t see anything else I could do except somehow improving the overall processing speed. But it looks like there is no way to optimize this any better when the level zero demand is so lopsided.

2

What if you ran a DMT process to delete the unfirm jobs prior to running MRP? Would you gain back any of the (5) hours

1 Like
3

Since they are all make direct… you could also turn the parts into unique PartOnTheFly (POTF) - use the PARTNUMBER + Order/Line when defining the job… if the part numbers are different, then each different part would get its own processor, and would be processed faster. this might take a BPM to flip the job’s part number after the details are retrieved, but it would speed up MRP.

2 Likes
4

@E102016 Well, OK, but a few things with that.

  1. I did try that with 6 DMTs going at once. “You cannot modify a disposed object” or something like that is an error I got a lot. Multi-tasking the job delete doesn’t work well - which is probably why MRP does not do it.
  2. So it’ll still take at least 5 hours, just not in MRP
  3. If I do that during the day, all the demand disappears, so Time Phase is unreliable, etc.

@timshuwy

I don’t see what you mean. So, here, now:

  • MRP creates the jobs (jobnum is order-line-rel)
  • Method of the jobs is the BOM of the part number on each order line

You are proposing something different that I am not familiar with, I think.

5

I think he is suggesting you change the part number to force MRP to use a separate processor, then once its processed change it back via BPM.

6

@cfinley But where would MRP get the method from, for the unfirm job for that new imaginary part number?

7

@JasonMcD Duplicate Part in Part > Actions seems to copy the method

8

Ahh I see the problem with what I proposed… for some reason I was thinking “product configurator” while giving a non-configurator solution. (In the product configurator, we can change the part number while leaving the “base” part number alone… the “base” is where the details are retrieved from).
So… getting back to the problem. you have MANY ORDERS for the SAME PART, and each one is planned separately.

  1. are these all CURRENT jobs, or are some of them way out in the future?
  2. what would happen if the FUTURE jobs were combined into bigger jobs, while the current (next X weeks) were the only ones that were planned descretly (one job per demand)?
9

@cfinley Well, then I have a part record I didn’t want. More overhead to deal with, etc.

@timshuwy
Yes, very good summary.

  1. Right, some are future. But they are not way future to where I can do a cutoff. We have many components with very long lead times.
  2. That has certainly crossed my mind. I’d love some way to batch like a week at a time for the same part. But only past a certain date, as you described - yes, exactly.

So is there a way to do #2?

And one day we’ll do configurator. One day. We have the module. Just need the Engineering buy-in. So, never, basically.

10

So… this is exactly how the “Short Horizon Planning” window can be used… within the short horizon, you can have different planning rules, than outside the window… Example (screenshot of Kinetic screen below) you can have a 28 day (4 week) short horizon window… every job within this window is planned using these parameters. but outside the 28 days, you can follow new rules, including the Days of Supply to group things into different buckets.

image
image1583×712 88.5 KB

4 Likes
11

Cool. This is very thorough.

I made a rule eons ago that all trucks are max lot size of 1, so I would obviously need to set that to zero and allow the short horizon lot size to be where I set it to 1.

Wow, Days of Supply for manufactured parts. I’ve only cared for purchased before.

OK, this is new territory here.

So… with the parts made to order, will it put the multiple demand links on a single job?

I am excited to test this.

12

@timshuwy I did finally test this. The only way I saw it could work is to make the order lines NOT Make Direct. So I did that and there you have it in the pic below. For my test, I used 120 day “short” horizon and 7 days of supply, and it works well.

I’m just disappointed that it can’t batch the make direct lines into multiple demand links on a single job. But I see in the logs it processes “non-stock” demand first (one by one), then stock demand is batched.

It’s definitely one to keep in mind, especially if business keeps expanding. Maybe we will actually use Configurator then!

image
image772×976 43.6 KB

1 Like
13

Thumbs up for everyone in this thead. This has been more helpful than Epicor guides or consultants :slight_smile:

1 Like
14

You replied at a good time. This was a year ago, and we did not implement this, but we are planning to ASAP (in a matter of weeks), since the business (and our pace) has grown so much in the last year.

For my specific scenario (every order is make-to-order in quantity of 1 per job), I realized a few things.

This discussion eventually led to 2 classifications of supply: (a) Short Horizon and (b) regular planning.

But there are effectively 3:

  1. Order lines that are make-direct
    a. This overrides any other settings
  2. Short Horizon settings
  3. Regular planning settings

In this post, I was planning to abandon (1) and make the settings for (2) mimic what (1) was doing. But that’s counterintuitive.

So now, my plan is:

  1. For a sales order release Ship By date within 45* days from today, set it as make-direct
  2. Short Horizon settings to batch jobs by week if within 1 year* from today
  3. Regular planning settings to batch by month after that

*Numbers subject to change…

1 Like
15

Well, I did a lot of changes in our part setup and so.

First thing we had a SQL database error, where data was not truncated I think (not my field). That sped up the whole MRP process from 12+ hours to 66 minutes.

Additionally I trimmed down lot sizing days and short horizon planning to reduce the job suggestions from 25000 to 5000ish. Generally I used on lot sizing days of supply 30 and 30 days also for short term horizon.

We have a business need to see finite scheduling for all resources minimum 360 days, which is possible because we have really total 20 manufactured parts with around 400 components total. Some products have 9 levels, but only like 1-2 per quarter.

Also, a lot of resources were added without calendars and finite days. We had also people / operators as resources. One shift leader uploaded new operators without calendars and that caused delays in MRP process also or more like lag.

I did check all the steps here which helped to understand several bad parameters that were hiding in the system: Finite Global Scheduling Will Not Complete - #19 by GPareja

2 Likes