Ok! I did a lot of testing and was able to get the system to split operations across shifts, but it does not provide the cleanest results. Here is the writeup that I did.
Calendar Setup:
All calendars should have the Default Hours Per Day set to 24. Then the specific working hours should be selected each day.
Machine Resources
There should be as many calendars as the business requires that reflect what is reality. If a company runs two shifts, there should be a calendar for machine resources that run during both shifts. If there is a machine resource that only runs one shift, there should be a calendar for that. Etc.
Employee Resources
There should be a calendar for each shift. If employees get an hour’s lunch, the calendar can reflect that by leaving an hour open in the middle of the shift.
Resource Group/Resource Setup:
Machine Resources
The setup depends on the company’s current setup and if they split operations between machines to reduce lead time. My guess would be that a company that is trying to split across shifts does not generally try to split an operation between machines.
First the preferred option. To get the scheduling engine to split a job operation across shifts for machine resources, each RG should have only 1 Resource in it. This is because we are using Split Operations functionality and don’t want the engine to split the operation over multiple machines. The resource should be finite, have 1 scheduling block, and split operations as true.
The second option. If the company does want to split operations across machines and across shifts, they can use RGs or capabilities to group the like machines together. The resources should be finite, have 1 scheduling block, split operations as true, and a concurrent capacity equal to the length of a single shift.
Employee Resources
All employees can be in the same RG. The important thing is to put the correct calendar on each employee for the actual shift they work.
Method Creation
When creating a method, the scheduling blocks need to be set based on the total run time of the operation. If the shifts are 8 hours long and the operation will take 40 hours, the scheduling blocks should be set to 5.
Both the machine resource and employee resource need to be added as scheduling resources for the operation. An operation on 1 machine across two shifts would need two resources: the machine and the employee RG.
Results
Setting up Epicor this way will get the engine to split an operation over shifts. The machine resource will be selected and since it is a single resource in an RG, it will only split the operation over that one resource. The employee resource will select an employee for each shift based on the calendars that are assigned to the resources.
If a company cannot have a single resource in an RG, the same result can be reached using concurrent capacity. You can put an RG or a capability as the scheduling resource and setting the concurrent capacity will limit the engine to selecting only one resource per shift. There is the potential for the engine to schedule the operation on machine 1 for first shift and machine 3 for second shift, but you still get very close with less manual intervention.
Problems
Since Epicor is not really set up to be able to split operations across shifts, the above does come with problems. Here is what I have found so far:
- Split Operation does an even split of the hours. If you have an operation that takes 21 hours and you run 8-hour shifts, the engine will create three 7-hour blocks.
- You will get some really funny results due to split operations.
- Complex solution that will break easily if there is not someone who fully understands it at the company.
I have tested this out and it does work. Although my testing was done in the pilot environment and the solution has not been done in production. If a company implemented this, a lot of stress testing would need to be done to find other quirks.
Ideas
There are two main Ideas I came up with that would make Epicor be able to handle this type of functionality better.
-
A flag on Operation Scheduling Resources for “Keep on Resource”. This flag would tell the scheduling engine to only schedule the operation on the resource it first picks. Basically, once you pick machine 2 for the first scheduling block, every other scheduling block must be on machine 2. This helps get around the chance of the engine selecting different machines for different shifts. It would also speed up the engine as it is not checking every resource for every block. I think logic to check for a continuous block for the whole operation would have to be added too.
-
A flag related to Scheduling Blocks that would allow the engine to do an un-even split and dynamically determine the Scheduling Blocks. I picture the logic being like this
- Engine sees that an operation is estimated to take 21 hours and searches for a continuous time on a single machine resource.
- Engine finds a block that starts with 1 ½ hours left on an employee resource and schedules that.
- Engine calculates that 19 ½ hours are left and creates a second scheduling block.
- Engine schedules the same machine resource for 8 hours and then looks for an employee resource.
- Engine calculates that 11 ½ hours are left and creates a third scheduling block.
- Engine schedules the same machine resource for 8 hours and then looks for an employee resource.
- Engine calculates that 3 ½ hours are left and creates a fourth scheduling block.
- Engine schedules the same machine resource for 3 ½ hours and then looks for an employee resource.
Customization
I also thought of a customization that could be done to make the results better.
Since the engine is being run finitely, there could be a data directive and/or function to intercept the writing to RTU. Since each operation is being run individually, changing the output of the engine should not impact the next scheduling step as it will look at RTU and see whatever was changed.
