Scheduling Blocks : An analysis

Scheduling blocks seems like a simple feature at first glance but multiples layers of complexity are hidden under the surface. The documentation is severly lacking and a lot of people are asking questions on this forum. So, here is the summary of all the tests we did over the years.

English is not my first language, sorry in advance for typos

Configuration - Resource Group

To enable the use of scheduling blocks, the “Split Operations” check box must be checked. This instructs the scheduling engine that operations assigned to this resource group can be divided evenly between multiple scheduling blocks.

There is also the possibility to assign the number of scheduling blocks at the resource group level. However, this value doesn’t have any impact on the scheduling engine ; it only defaults the scheduling blocks value when an operation is added to a job, having this resource as primary scheduling requirement configured in operation maintenance.

It is possible to set the “Split operations” only on specific resources within the resource group. If so, you’ll have to uncheck “Use resource group values” and use the “Split operations” checkbox at the resource level.


Configuration - Job Operation

In the job operation, first make sur that a resource or resource group with “Split operations” enabled is assigned. Then, assign the number of scheduling blocks desired in the corresponding field


Theorical Behavior

As per the field help : “The Scheduling program will divide the production time by the number of scheduling blocks. This program then finds resources that have capacity available in the required time frame”

For example, if an operation with a Prod Standard of 30 hours has 1 scheduling block, the operation is scheduled as one single block of 30 hours. If the operation has 2 scheduling blocks, the operation is scheduled as two distinct blocks of 15 hours, and so on :

Now, each block can be assigned to a different ressource, which can reduce the lead time of the operation.

For example, here is the previous 30 hours operation with 2 scheduling blocks. Both scheduling blocks are assigned to the same resource, one after the other :

The resource works on the first block for 15 hours, then on the second for 15 hours, for a total actual man hours of 30 hours and a lead time of 30 hours.

Now, this time, the scheduling blocks are assigned to different ressources :
image

In this last example, both resources works at the same time on the same operation for 15 hours. The total actual man hours is still 30 hours but the lead time is reduced to 15 hours.

So, in theory, scheduling blocks can be used to specify how many “people” are working at the same time on an operation to reduce the lead time.

The reality is a little bit more complex, and the behavior is widly different between finite and infinite scheduling.


Real Behavior - Finite Scheduling : situation #1 - (Operation assigned to a resource group)

For this first situation, we’ll work with job #000973. The operation is assigned to a resource group :
image

This means that we let the scheduling engine selects the first available resource in this resource group to work on our operation. Now let’s say that this resource group only has 2 active (available) resources :
image

Now we remember that our operation has a prod standard of 30 hours and 2 scheduling blocks :

What happens if we lauch global shceduling in finite mode ? Something like this can happen :
image

In this situation, another job 000971 had a higher scheduling order, so it was scheduled first. It was assigned to the same resource group than our job 000973, so the first available resource (BSP_AMS_01) was assigned to its operation.

Then, job 000973 was scheduled. The operation is divided in two 15 hours scheduling blocks. The engine find that ressource BSP_ASM_01 is not available so it schedules the first 15 hours block to resource BSP_ASM_02. After that, the engine tries to schedule the second block. Since BSP_ASM_01 is still not available, it schedules the second block right after the other, on resource BSP_ASM_02. The operation lead time is 30 hours even if we set 2 scheduling blocks.


Real Behavior - Finite Scheduling : situation #2 - (Operation assigned to a resource group)

Here is another scenario. Job #402200. The operation is assigned to a resource group :
image

The resource group has 2 active resources :
image

The operation has a prod standard of 30 hours and 3 scheduling blocks :

Let’s run global shceduling in finite mode. Something like this can happen :
image

In this situation, another job 402197 had a higher scheduling order, so it was scheduled first. It was assigned to the same resource group than our job 402200 and had two scheduling blocks. Since both resources were available, both scheduling blocks were assigned at the same time to both resources.

Then, our job 402200 was scheduled. The operation is divided in three 10 hours scheduling blocks. On the 24th, the engine finds that both ressources are available and that the scheduling blocks can fit before job 402197 starts, so the blocks are assigned. The third and final block now wait for any resource to be available, which happens only when job 402197 is done. So, the final block is assigned after job 402197 is done.

The total man hours for our operation is still 30 hours but the lead time is nowhere near the theorical 10 hours.


Real Behavior - Finite Scheduling : situation #3 - (Operation assigned to a resource group)

Job #404040. The operation is assigned to a resource group :
image

The resource group has 3 active resources :
image

The operation has a prod standard of 30 hours and 3 scheduling blocks :

Run global shceduling in finite mode. Something like this can happen :
image

In this situation, other jobs had a higher scheduling order, so they were scheduled first on resource #1.

Then, our job 404040 was scheduled. The operation is divided in three 10 hours scheduling blocks. On the 4th, the engine finds 2 out of 3 ressources are available, so two blocks are assigned. The third and final block now wait for any resource to be available, which happens only when our first two blocks are done. So, the final block is assigned after blocks #1 and #2 are done.

The total man hours for our operation is still 30 hours, but the lead time is 20 hours. This also mean that 2 employees start working on the job at the same time but, after 10 hours, one employee stops working and let the other one finish alone for another 10 hours.


Real Behavior - Finite Scheduling : situation #4 - (Operation assigned to a single resource)

Job #040185-1-1. The operation is assigned to a single resource this time :
image

The resource group only has 3 active resources :
image

The operation has a prod standard of 30 hours and 3 scheduling blocks :

Let’s run global shceduling in finite mode. Here is the result :
image

Our job was scheduled. The operation is divided in three 10 hours scheduling blocks. Since the operation is assigned to a single resource, all the scheduling blocks must be executed by this single resource. So, even if other resources were available, all the scheduling blocks were assigned consecutively by the engine.

The total man hours is still 30 hours and the lead time in this scenario is 30 hours.


Real Behavior - Finite Scheduling - Conclusion

Using scheduling blocks in finite scheduling means that the production time of the operation must be split equally in the specified number of blocks. Each of these blocks will be scheduled to available resources one after the other, indepedently. The behavior depends heavily on the resources load at the time when the split job is scheduled.


Real Behavior - Infinite Scheduling #1 (Operation assigned to a resource group)

For this first situation, we’ll come back with our first scenario but, this time, scheduled infinitely. Job #000973. The operation is assigned to a resource group :
image

The resource group has 2 active resources :
image

The operation has a prod standard of 30 hours and 2 scheduling blocks :

We run global scheduling in infinite mode. Here is the result :
image

Just like the first scenario, job 000971 had a higher scheduling order, so it was scheduled first. It was assigned to the same resource group than our job 000973, so the first available resource (BSP_AMS_01) was assigned to its operation.

Then, job 000973 was scheduled. The operation is divided in two 15 hours scheduling blocks. Since we are scheduling infinitely, it doesn’t matter that ressource BSP_AMS_01 is loaded, so the two scheduling blocks are assigned at the same time on resource #1 and #2. The total man hours is 30 hours and the lead time is 15 hours.


Real Behavior - Infinite Scheduling #2 (Operation assigned to a resource)

We’ll repeat the previous scenario but this time the operation will be assigned to a single resource.
image

Resource group has 2 active resources :
image

Our operation has a prod standard of 30 hours and 2 scheduling blocks :

We lauch global shceduling in infinite mode:
image

Since we are scheduling infinitely, it doesn’t matter if the resource is loaded. So, the engine can assign both scheduling block at the same resource at the same time. The total man hours is 30 hours and the lead time is 15 hours, even if one single resource is required


Real Behavior - Infinite Scheduling - Conclusion

Contrary to finite scheduling, using scheduling blocks in infinite scheduling will always split the lead time of the operation by the number of scheduling blocks since resource load is not considered. This behavior may not be wanted, as per the last example when we assigned the operation to be executed by a single resource.


A quick word about crew size

When assigning scheduling resources to an operation, there is a field down below labeled “crew size”

This field doesn’t have any impact on the scheduling engine. It is used for reporting and/or financial purposes.


Here is a real business problem

In our case (as for many manufacturer), we have workstations with mulitple employees. We want the lead time of the operation to be split by the number of employees. So, if my operation has a prod standard of 30 man hours and 3 people are working at the same time in the workstation, we want the lead time of the operation to be 10 hours.

Now that we know how the scheduling engine handles schedulig blocks, what would be the best approach ?

Well, if you can schedule infinitely, just assign the number of employees as the number of scheduling blocks.

If you want to schedule finitely, you have to find a way to stay clear of all the undesired behavior showed previously. The way to achieve this is the following :

1- Make sure that the resource group has the exact number of active resource as the number of employee in the workstation
2- Make sure that each and every job operation that is scheduled to this resource group has the number of scheduling blocks equal to the number of active resource.

This way, if all goes well, it should work.

Here’s the real problem : what if the number of employees assigned to the workstation changed ? Instead of 3, there are now only 2 employees assigned to the workstation.

Now, you have to not only update the resource group number of active resources, but the number of scheduling blocks of every single job operation assigned to this resource group. Good luck with that.


An idea of improvment

You know what would be great ?

First, add some kind of checkbox on the resource group level that would tell the scheduling engine, along with the “Split Operations” checkbox, that it must assign all the active resources of the resource group, at the same time, to a job operation.

Also, when this checkbox is checked on the resource group level, the scheduling blocks fields on the job operation would be greyed out. The scheduling engine would split the operation in the exact number of scheduling blocks required to assign all the active resources of the resource group.

Something like that


End word

Please let us know if there is a mistake or anything in what was demonstrated, learning the scheduling engine is no easy task. I don’t know what I would have done without this forum, so thank you all.

14 Likes

Wow. Far and away the best discussion of this topic I’ve ever seen. I’ve saved it to a PDF document and will study it later today… thank you so much!

This is excellent! Thank you so much for taking the time to put this together. I am sure it will prove a valuable resource to many of us!

Let’s try an example:
We have a resource group VMM for Vertical Milling Machines. It has 10 machines in it. I have a rare big job for our shop coming up that makes 10,000 parts. Each part goes through one operation at VMM. We have enough labor to run all 10 machines.
Can we split this one operation to run on 10 machines, so that each machine runs 1000 parts?

I’ve never tested spliting quantities since we are only interested in spliting time at our shop. Never seen anything about spliting quantities in the documentation either.

Let’s say that one part takes 10 minutes to machine. For 10k parts, the total estimated time would be 100k minutes. If you set 10 scheduling blocks on the job operation, the scheduling engine would split the operation in 10 blocks of 10k minutes. Each block can then be scheduled to a cnc machine.

In this scenario, the machine would be instructed to run for 10k minutes on this job, not specifically instructed to machine 1k parts.

That makes a lot of sense! Why restrict the part count, when it’s the time that matters. Thank you again!

Moved to experts corner this is good stuff! Thanks!

1 Like

Goodness Gracious. This is AWESOME!

I’m privileged to work with you.

EDIT. You’re teaching me a lot about humility. Thanks man.

1 Like

This is fantastic!! Thanks for putting this together @mbilodeau . I have a feeling this post will prove invaluable.

Great info…thanks!

On a related note, a long time ago I compared methods where NonStock or Phantoms were/weren’t involved. If I remember, the overall times didn’t really change but… the differences in where/how displayed were pretty dramatic.
Thinking it might be worth repeating…only time.

This is great. We run infinite and use one scheduling block for almost everything. The Pieces per hour is the takt time of the process and is immovable. The crew size is the personnel load on the line. I believe (Someone correct me if I’m wrong) that the overload informer will look at the number of resources available and this can be used to see if you need to increase resources down the line. For example, we have one custom machine to do something. If that resource is overloaded 3 months from now (more hours assigned than it can run) the overload informer will tell us and we have two choices. Spread the order into multiple releases or duplicate the machine and double the scheduling blocks in the method. To me this is one of the most powerful features of Epicor.

On the crew size side of things, it’s essential for a shop using labor tracking to take this into account. The crew size x run time is how much labor you should have logged towards the job for efficiency calculation. If you are attaching cost to labor this is also important for job variance caluculation. The system will expect a certain cost during the completion and closing processes.

Thank you mbilodeau, this is a great research project and excellent learning discussion. We use a 21 date finite horizon so we often see both of these scenarios as we schedule our operations and this helps me better understand what I am seeing on our schedules. We usually adjust the scheduling blocks to match the work load. Our parts vary every time through so it is often a review prior to going to the shop floor considering total hours on the operation and how many people (scheduling blocks) we can safely have working on an operation at the same time. I like what you are suggesting with your end conclusion but also think that in our low volume high variability situation I think we will have to continue to manually adjust. Again thanks and nice work.