Currently working on implementing scheduling(APS) at my organization. Production necessitates a 2 day rest period after the first op is complete. The MoM’s are very simple with 3 ops.
Expected outcome:
OP10 scheduled to start 6/2/205
OP20 scheduled to start 6/4
Op30 scheduled to start 6/4
Job will be completed on 6/4.
It is important to note OP20 and OP30 utilize the same shared resource group with the same people resources. Operators move between op20 and 30 in a fluid way in the same work area. They are distinct operations conducted by the same shared pool of resources. It is unknown and cant be known/dictated how many operators will be working OP20 or OP30 at any given point in the day. For this reason Queue time will not work as it applies at RG level.
Move time does accomplish this nicely and will follow the dates as ive detailed above as move time is housed on the OP10 RG which is distinct from OP20 and OP30. However, move time ignores weekends. So if OP10 occurs on Friday for example OP10 would be scheduled to start Friday, weekend ignored 2 day move time starts Monday and OP20 scheduled to start on Wednesday. In actuality Production would start OP20 on Monday as the product rested 2 days over the weekend.
Come Monday global reschedule does move jobs to Monday and schedules “correctly” However, the schedule is technically wrong until this happens.
Has anyone ran into to a similar scenario at their organization? How did you handle it? I can likely use a dummy op between OP10 and OP20 with 48 hour fixed time and a calendar that runs through the weekend, however I would really prefer not to go this route.
Currently we have Use calendar for move time checked. Im assuming with this unchecked it doesnt reference calendar in Move time. Seems like a potentially simple solution that I didnt recognize prior. Thanks, I will test with un checked.
I am in the middle of this same dilemma, we have a 24hr curing time between op 10 and op 20. Although I am leaning towards doing exactly what you stated you didn’t want to do…adding in another operation “Curing” with the same resource group, adding a resource for “Curing” and giving that resource its own calendar that is 24/7 and a 24hr move time with no production standard.
In my case move time wasn’t working because that waits till op 10 is complete before move time kicks in and essentially the curing can start right as op 10 starts, or like you mentioned the calendars on those ops don’t include weekends. So my new op 20 “Curing” is set to ‘Start-toStart’ with op 10 so they both start at the same time, make Op 20 ‘Backflush’ so that no employees need to clock into the operation. op 20 can run through the weekend to give accurate Job Start-Job Due Dates when scheduling.
I don’t know another way around what you’re trying to do and will be curious what others have to say. Calendars seem to be the limitation here when weekends can be used for this move time.
From the jobs I have scheduled around different scenarios deselecting the “use calendar for move time” seems to be the ticket. It will count 48 hrs(or whatever value you input) regardless of your calendars. It also appears that if the end of your move time falls on a non work day, the following op will schedule to start at the nearest work day associated with the calendar on the next op, which is perfect.
We have other product lines with true “curing” times and while we are not scheduling through Epicor yet we build MoM’s as you described with a curing op and its own calendar. In the case ive detailed the 48hr has no effect on the fit/form/function of the product, in fact op20 could start 1 second after op10 finishes. Its only purpose is to provide down stream production with plenty of jobs to pull from at any given day. If we did not buffer in 2 days its possible production crew would be standing around waiting for op10 to finish on each job. Op10 is machine limited while op20/30 are not. In my case it would be a true dummy op which is my reluctance for going this route.
Hi,
I am trying to do exactly what you listed above (have 2 days on the first operation).
I have tried using move time, kit time and production prep buffer.
Every time I test and run MRP, the start and due dates stay the same on the operation.
Any ideas why I can’t get this to work for me?
*** Edit to add - We specifically want the start date to be 2 days earlier than the due date on a specific operation to allow for time the job sits there waiting to be picked.
Can you add a resource called “waiting for paint to dry” or something and have that as a mandatory op with 2 days of time, but with the “waiting” resource group credited at $0 for their labor?
I may need to test that one.