I think I know the issue now. I read it on another thread. My job is for quantity 1. And scheduling blocks doesn’t work for qty 1… I need to check the Split Operation box to get scheduling blocks to work when qty = 1. So I overcame that issue finally and I’m on to the next thing… ugh.
Yes, my MOM has 1 operation. Prod Standard is 3 hours per piece. Once I checked Split Operation it finally used two resources.
I was just reading the Scheduling Tech Ref guide and I think I had the way to put scheduling blocks on REs backwards. If you have a maximum amount of people who can work in a single bay, I would set the bay RG scheduling blocks to that number. The RG for the employees should be set to 1 scheduling block I believe.
Glad you figured that out. Just be careful as that split operations also means that operation can be split 1 hour today and 2 hours next wednesday.
The crux of this whole thing seems to be rooted in the fact that scheduling blocks exist at the operation level… it wants to break all scheduled resources into those blocks, not just 1 or the other. What happens with 2 blocks on the job is that we end up with 2 installers scheduled to do their work concurrently (in 1.5 hours) but the bay itself is scheduled back to back 1.5 hour blocks taking a total of 3 hours.
I have not done the extensive testing that he did, but I think he is wrong in that you need to use split operation. You don’t want to split your operation, you want to have more resources lower the time.
I think the bay RG needs the scheduling blocks set to how ever many employees can work at one time. Everything else should be 1 because that RG can be split, but nothing else.
At least that seems to make sense. I’m trying to test.
@dr_dan , I’ve been testing this and have a couple of ideas that I wanted to test out. Is there a max number of employees that can work in a bay at the same time?
Wow - you totally didn’t have to do that. I really appreciate it. Max employees is 4. I’m not entirely sure, but that’s an educated guess. You can only fit so many people on or under a truck chassis and not be on top of each other, you know?
Throw down a twister mat and you can play and work at the same time
Pretty sure I got it! I’ll have to do some more testing and will post it later. In the image below, WC200 was always going past the 2 employees until this try.
Did you have to halve the standard hours to achieve this? Or were you able to dynamically let the system calculate available resources using scheduling blocks?
It seems like the only way I can get this to work properly are either one of the two scenarios… but neither is what I was hoping to achieve.
Set up my operation with my location as a scheduling resource and set 2 capabilities for the people as a scheduling resource (a total of 3 resources). Then halve the production standard so the system will plan on using 2 people for half as long always. This version uses scheduling blocks = 1. This is not ideal because the production standard will be confusing to people that it is not the “correct” hours. It may work, but will introduce a steeper learning curve, more resistance to change, and ultimately does not represent the “best” solution.
Set up my operation with my location as a scheduling resource and set 1 capability for the people as a scheduling resource (a total of 2 resources). The operation has 2 scheduling blocks each resource group allows split operations. The location resource is set as infinite and the labor is finite. This will divide the labor properly into two equal blocks stacked on top of each other but it also divides the location into two equal blocks and when there is only 1 acceptable location, it will stack two concurrent blocks in the same location (this is good). The problem here is that it will not allow me to use a capability where more than 1 resource is available and keep it in one resource only (which makes sense, because we’re telling it to divide it into two blocks and git er done faster). I know this is not the ideal way because it will force a person to specify which bay, specifically, they want the install to be conducted in instead of using a capability to allow the system to decide based on available capacity.
So where do we go from here? If I don’t see any other option, I’d pick option 1. I can live with having to do math and I think that in time people would get used to this.
The main thing we wanted to achieve was to use capabilities since our bays are setup to do certain types of trucks and the installation personnel are also trained in different areas and should be prioritized according to the type of work available at any given time. If we can’t use capabilities, then the best alternate would be a way to schedule everything so we can at least get the jobs scheduled out properly to fulfill all the orders and still require some human intervention to tell which people are doing which trucks. I feel like just scheduling to the bays would be fairly trivial. It’s basically what we do today except that we’re infinite today so there is no attempt to back-schedule appropriately to hit due dates.
Just wait, I’m still testing different scenarios. But I used scheduling blocks in my example. I did not halve the standard.
Welp, I’m not giving up, but it is beginning to look like it is not possible. I keep on getting close and then each time I try to expand it out, it does some wonky things.
I ran into the same issue you did in #2 where it would schedule another resource when you want it to only stay on 1. It seems like you cannot get the system to handle the dynamic aspect of it.