Good morning,
I have a curious situation. A job, 12345/1 contains 2 sub-assemblies. The job needs to be split so that some of the sub-assemblies can move ahead. However, we do not need to split one of the sub-assemblies in the job.
We currently split jobs on the floor, but not in epicor. We are trying to move this splitting process to epicor so that we have more accurate data. In our current process, one of the sub-assemblies for the job needs to be split. Since we have separate job travelers for each job/assembly, we can choose to split only some assemblies of the job. However, if we split in Epicor, it splits the entire job (all sub-assemblies) by default.
I am not sure if it is possible without creating separate jobs for each sub-assembly.
How do you all handle these situations?
EDITS:
Assuming I canāt split sub-assemblies in a job separately from the main job, how do I create multiple jobs that all combine together to make one job? Is this like a āprojectā? We donāt have that module.
What about make to job? I think I could setup all of our jobs that have subassemblies as single jobs that are each make to job, up to the main job. What do you think about this approach?
Our engineers didnāt like the idea of breaking up our method masters into multiple jobs by assembly. This would require recreating most of our methods. Instead of having one main part with many sub assemblies, we would just have a bunch of disparate parts that all get consumed by the top level job. That top level job would be make to order, but all the assemblies that are required by it would be make to job.
Is there a relatively easy way to separate an assembly from a job, and keep the entire method for that assembly intact? Or do we really have to rebuild every part method?
If you make the subassembly part numbers non-stock and mark them as Plan As in the method, then MRP will create separate jobs with make to job demand links for them. Nothing changes for engineering other than those two fields.
I am doing some experimenting on this concept. If I have a top level part with two subassemblies, and I want to be able to split one of the sub assemblies, can I just set that one sub asm to Plan As, and have the other sub assembly stay as a sub of the main part? I think this should give me the ability to split the job that is for the sub assembly without needing to split the top level job, or the assemblies that donāt need to be split.
I have been reading your posts for a while now and what you really need to do is stick dynamite under your current processes and light it. You will continue to struggle to make the system āfitā the way you currently operate as the system does not support how you operate. My last job was the same way. They would get an order with multiple releases and wanted to manufacture up to operation X. Then they leave all of the parts in WIP and move the amount needed for a release forward as needed. The problem is that it ends up being an extremely manual task to maintain it and you canāt really use scheduling or MRP properly. You will just continue to chase your tail as Epicor will not support how you operate. Just my opinion on how to really solve your business problem.
I know I can always count on @jkane to set me straight! I agree, we need to start over. Management is starting to look at alternative ERPs. Can I retire yet?
soā¦ I have a fairly strong opinion about job splitsā¦ where I used to work, we did tons of splitsā¦ we had to example āwhyā we were splittingā¦ in theory, splits are not something that should be part of the āregularā planā¦ they should be the exception. If you find yourself splitting lots of jobs, then you have not designed your BOM/BOO correctly. It doesnāt matter what the engineers wantā¦ they should be designing the product ot be able to be made without modifiction at the job level.
SOā¦ in MY history, we typically had 250 jobs on the floor at a timeā¦ our jobs would take about 30 days to complete, so we were typically shipping about that many jobs per month as well. BUT I also found that we were splitting about 50 jobs per week (20%). When I became the Production Control Manager, i asked āWhyāā¦ i was told āBecause we had a problem, so we need to split off the problem and continue with the balance of good onesā. Then I looked at the results, and 9 out of 10 times, the āproblemā was resolved quickly, and many times, the problem parts finished before the parts that we split off to āexpadite.ā.
SOā¦ I made a new ruleā¦ for every split, the planner had to put an entry into a paper log. they had to bring that to me to sign. That was itā¦ i never rejected any request to split. and we reduced our splts down to less than 5 per week.
Moral of the storyā¦ stop splittingā¦ it just causes extra paperwork, confusion, and inaccurate dataā¦ AND if the parts require re-engineering, make it so. fix the problem at the source so that people dont need to split on the fly.
I love this story Tim. I have shared it with our folks a couple of times. They even started doing your idea of validating each split. While we keep finding that we need to keep our splits in place, it seems to be just because we canāt imagine another way to do it. Every time we come up with a potential solution, some other part of it causes issues. Like John said, we need to start over, and no one wants to agree to that.
Thank you again for sharing this. It is important to keep this perspective.
