Good morning,
We just had a meeting to review the process for splitting jobs in Epicor. Currently we split our jobs manually, completely outside of epicor. We do this when a job is going to run for a long time, but a handful of parts need to be expedited through the rest of the operations. For example, we know that job 12345/1 is running today for a total of 100 pcs. They are at op 50. At the end of the day, the manager wants to split off whatever number of parts are complete through op 50, and send them through to the next op. So the manager copies the 12345/1 paperwork, and physically amends it to be 12345/1A. They don’t know ahead of time how many will be split off, it depends on how many are complete at that time. Let’s say 5 parts are complete and get split off to 12345/1A. This split could happen many times, and could even be nested. So eventually there could be a job 12345/1B, 12345/1A1, etc…
Now when we tried splitting these jobs in epicor, we found a couple of major issues that just don’t work for us. First is that we need to split a job by linking more than one release. So In our example above we split off 5 parts, but the sales order only has releases for 3 parts for multiple release dates. So when we try to split off 5 pieces, we can’t just choose a single release. Instead we have to choose a release, then go to Job Manager and transfer some additional releases to the newly split job.
The problem with this is that the split job only pulls labor transactions for the operations/quantities from your original split. So, from the example above, I can only make anew split lot for 3 pieces (because the releases are all for 3 pieces). So the labor through op 50 gets pulled over for those three pieces. But now when I transfer the demand from a second release into the new split job, the labor transactions do not get pulled in.
Are we missing something big here? It seems like this is a normal process for splitting jobs, but the restrictions are making the process untenable for us.
Thanks for your time!
Nate
The split job functionality is, in my opinion, not worth the time trying to get it to work. There is too much that can go wrong.
What you are experiencing makes sense though. The split job functionality is what controls the splitting of cost, so if you add quantity to a split job, it just thinks you are adding more quantity. Not moving quantity from another job.
More importantly, do you put multiple demand lines with different dates on 1 job? As an example, you get an order from a customer for 100 widgets with 10 releases of 10 widgets each with different need by dates. If you do, Epicor can not schedule that job as it can only schedule to 1 date. I’m only bringing this up as I am familiar with your other posts and I know you are trying to implement scheduling.
Yes, we do. We understand that epicor can only schedule a job to one release date.
Thank you for your feedback. Before today, I was certain that we had to move towards properly splitting jobs in Epicor. Now it seems like it just won’t work the way we want it to. I am planning to review this issue with Epicor support as part of our recent APS or DMT purchase.
I am curious if anyone else has any positive experience with splitting jobs in Epicor.
Thanks!
Ok. Hate to be the bearer of bad news, but you will never get scheduling to work if you continue that practice. That is completely contradictory to how Epicor’s scheduling works. If you need to pre-build subassemblies, you would control that through the MOM and MRP.
Unless your jobs always, without exception, tie 1:1 to an order (I’ve seen this with repair work or hand-made custom orders), I strongly advise using a make-to-stock framework. Decoupling jobs from orders allows you to run jobs at whatever scale is most economical and efficient. It also makes splits trivial.
There are pros and cons to both make to stock and make to order. The decision needs to be made by each company based on their model. If you are a job shop, it generally should be a hybrid leaning more make to order. If you are an OEM, it generally should be make to stock. But like everything, there is no one answer.
As an example:
A customer orders 1200 widgets with 12 releases of 100 due the first of each month. You only make this part for this customer. There is an operation that takes 8 hours of setup every time you run a quantity. At $50 an hour that works out to $400. If you run each release separately it is $400 of cost on each release. If you do a make to stock up to that point and allow MRP to pull from stock to finish the releases as needed, that $400 is spread out over 1200 ($.33/piece) pieces instead of 100 ($4/piece).
Now there is risk making all of the parts as the customer may cancel the order and you would have to scrap what was done. But these are the types of decisions that management needs to make based on where they want their risk.
The biggest downside of make to stock is that everyone still, typically, thinks in terms of orders. “Does this order have enough material to run” vs “we have enough material to run jobs until X”. The upside is that you can execute decisions at scale rather easily. Just change 1 or 2 settings at the part level and let MRP do the hard work.
But yes, it’s a multi-stakeholder decision. The more repeat (and frequent) work you get, the more compelling make to stock becomes.
In short, sales orders create demand for parts at the site level and jobs + PO’s are scheduled to fulfil shortages in said site. All that matters is the part# and the date and the qty you have/need on that date.
For research, start with the built-in help on MRP and then to the tech refs on EpicWeb.
My very first job in the Epicor world, lo those many years ago, was as the IT admin/ERP Support guy in a machine shop that made components for a defense contractor (this was on Vantage 8). Each week they’d send us their updated order book, which we would fold, spindle, and mutilate into a Service Connect workflow that updated OUR order records. It was all make-to-order.
But with all the changes each week, that just got unmanageable on the documentation side of things. Our customer wasn’t really so concerned with which actual finished good went with which actual PO line, they just wanted the parts they wanted when they wanted them. We changed our entire shop from MTO to MTS, put one of our Quality people at the end of the production line to collect all the paperwork, and then Production just had to respond to quantity and date signals instead of matching order numbers with jobs. It took several months to get everything straightened around, but in the end it was really worth it.
Tim’s STORY TIME:
Job Splitting is a very expensive task… especially in a lot tracked world where I came from. Every time we split the job, we also had to split all the documentation… all routings, all signoffs, etc.
I became the Production Control Manager for a company (in addition to my IT job) and I saw the splits happening… at least 30-40 per week. I asked “Why are we splitting so many jobs?”… answer came back. "Because there was a problem and we had to expedite the good parts.
I did my analysis… I found that after splitting, MUCH of the time, the “Bad” parts ended up being certified/corrected, and in many cases, the “bad” parts finished ahead of the good ones (because they were a smaller set of parts)…
Sooo… I made a new rule: "Before any job gets split, I want the job split data written down on this pad of paper (a paper log was good in 1990s)… I want the Job, Part, Job Qty, New Job #, with new qty, AND a “reason for split”… There was a place for me to initial/approve each split before they did the actual split. Note I NEVER disapproved of any split. I approved every one that was written down… BUT the number of splits was reduced from the 30-40 per week down to 5 (amazing!)…
Turned out that people were just splitting because “That is what we do if there is a hang-up” but in reality, we really didn’t need to split after all. We didn’t have any additional late orders, and we saved money.
Moral of the story? Make sure that you are splitting for a REAL reason.
You may all return to your normal work now.
We call this a “Process Issue” in the field. Your Mileage May Vary.
In each of the cases above, I feel pretty confident that MULTIPLE different processes were tried (whether by accident or on purpose) before a solution was developed (or run into headfirst).
Our orders are not consistent enough that we can plan ahead and make jobs to stock. (This also makes me worried that MRP is not going to work for us either.) If MTS is not the answer, then it seems like we have to keep doing MTO, and figure out how to split jobs in Epicor.
The biggest problem seems to be that we can’t split the demand releases to reflect the job demand. Has anyone figured this out yet? We could manually adjust the sales order releases by changing quantities and adding new releases, but that has its own problems. I think it has to do with tracking costs and labor.
Are you MTO and do you split jobs? Do you split/adjust your demand when you split your job? Do you have any tricks for getting the costs and everything to work out correctly?
I know it is a long shot, but I want to make sure I haven’t missed something.
