We’re encountering a scheduling issue within Epicor
Our assembly line consists of 10 stations, each meticulously aligned with specific operations outlined in our Manufacturing Operations Management (MOM) job. Additionally, we’ve allocated singular resources to each station, alongside a resource for the “final assembly employee.”
Our primary concern arises when scheduling jobs with varying cycle times for different products. For instance, Product 1 requires 1 hour at each station, resulting in a total cycle time of approximately 10 hours. Conversely, Product 3 necessitates 3 hours at each station, extending the total cycle time to 30 hours.
The crux of the issue lies in the sequencing of jobs with shorter cycle times. Logically, these jobs should be completed after any job in front of them. However, we’re observing instances where jobs with shorter cycle times are scheduled to complete before the preceding job—a scenario that defies physical constraints.
In our operational context, it’s absolutely critical that jobs with shorter cycle times wait until the completion of the preceding job before proceeding. It appears there may be a setting or configuration oversight contributing to this discrepancy.
We’re reaching out to the community for any insights, best practices, or guidance on rectifying this issue. Any assistance provided would be immensely appreciated.
I’m not aware of any setting that would be able to have a job not consume an open resource based off of another job.
The only way I can think to try and do what you are asking (if I am understanding correctly) is to have your routers include all resources for each post operation. So, a 4 operation job would have all 4 resources on op 10, op 20 would have op 20 & 30 & 40 resources, op 30 would have op 30 & op 40 resources, and op 40 would only have the op 40 resource.
The scheduling engine is going to try and fill any open capacity it finds when running which is why the shorter cycle jobs end up jumping the longer ones.
Thats the thing, technically the resource is not open. All parts must visit all 10 stations in sequence.and at all times, all stations have something in them (sorta)
Say we started the line with a 3 hour piece, in 3 hours it moves forward. the 1 hour piece now starts in station 1. Technically there is only 1 hour worth of work on it, but it will have to hold for 2 more hours till it can move to station 2, and it will do that the entire cycle. untill the 3 hour piece leaves the last station. in which 1 hour later, the 1 hour piece will also leave the last station.
I can set everything up on a 3 hour cycle i guess, it is a bit tougher on the estimating side as it would over estimate the 1 hour piece. But that problem might be easier to solve.
It sounds like a Send Ahead type of Start-to-Start with a Send Ahead Offset of 1 Piece would help align the operations more closely to what the line is actually doing. @Craig’s screenshot shows where this is set in the method on each operation.
I agree, except shouldn’t that be doing the same thing since we run 1 job, 1 piece anyway. Every part going through the line gets its own job number, so the job would be finish to start from the next job and the send ahead would have nothing to send ahead. it works great if we keep all our our operation cycle times consistant across all products, but as soon as we change the cycle time, it messes it up.
Here is a diagram of a perfect line to us, vs what actually happens. The main problem, is whatever goes in last, will still finish last, not matter what. The jobs cannot hopscotch around.
Finite, but we are manually scheduling each job at the moment as infinite. it seems to schedule better doing it this way, but we also have ALOT of load on the system backing up my resources. Do you think if I global scheduled all jobs for say 6 months from now, and then starting bringing jobs in manually from todays date forward 1 at a time finite, that would work?
I would run it finitely. It sounds like a resource is having two operations scheduled on it at the same time, otherwise, jobs should not be jumping ahead.
