No, I don't think you're missing anything. The global by nature is a total available record batch reset process.
Unless a job has the Lock Schedule checkbox set to true, the global will include it in the initial unload pass.
It will then, based upon whatever sequence Calculate Global Rescheduling Order came up with (or adjustments to that order you made with Adjust Global Scheduling Orde) reload all unloaded jobs into remaining available resource capacity (if finite).
You might be able to create a batch import utility to select a range of jobs that you only want the global to rejuggle, mark ALL OTHERS as Schedule Locked (JobHead.SchedLocked = TRUE), execute the global, and then (in another batch import process) unlock your temporarily locked job schedules.
It doesn't appear that there are any other OP level table.fields you might also have to lock in concert with JobHead.SchedLocked - but who knows if the data dictionary is complete and there really isn't some additional related table.fields?
If you try this, DEFINITELY do it in an offline copy of your live db!
Rob
Unless a job has the Lock Schedule checkbox set to true, the global will include it in the initial unload pass.
It will then, based upon whatever sequence Calculate Global Rescheduling Order came up with (or adjustments to that order you made with Adjust Global Scheduling Orde) reload all unloaded jobs into remaining available resource capacity (if finite).
You might be able to create a batch import utility to select a range of jobs that you only want the global to rejuggle, mark ALL OTHERS as Schedule Locked (JobHead.SchedLocked = TRUE), execute the global, and then (in another batch import process) unlock your temporarily locked job schedules.
It doesn't appear that there are any other OP level table.fields you might also have to lock in concert with JobHead.SchedLocked - but who knows if the data dictionary is complete and there really isn't some additional related table.fields?
If you try this, DEFINITELY do it in an offline copy of your live db!
Rob
--- On Sat, 9/27/08, Ken Williams <ken@...> wrote:
From: Ken Williams <ken@...>
Subject: RE: [Vantage] Finite Job Scheduling
To: vantage@yahoogroups.com
Date: Saturday, September 27, 2008, 12:48 AM
Rob I wanted to thank you for your very detailed analysis.
I believe we've got things in place (scheduling blocks was our biggest hurdle, setting it to one has in fact relieved some problems we were having). We're going to kick off finite scheduling for one of our departments next week, and assuming all is sell, deploy it company wide soon after.
One question I have is on Global Finite Scheduling. We basically have three job areas currently, and it'd be very nice if we could run global finite based on something like job numbers. Am I missing something obvious to be able to do this?
Ken
____________ _________ _________ __
From: vantage@yahoogroups .com on behalf of Robert Brown
Sent: Wed 9/17/2008 6:55 PM
To: vantage@yahoogroups .com
Subject: RE: [Vantage] Finite Job Scheduling
Sorry for the delay responding Ken... Very hectic week compounded by a stomach bug the last two days that won't go away.
Your example looks like it is easily modeled in 405a as long as you have AMM licensed and installed (to surpass the 4 OP max limit per method you would otherwise face).
To your questions: I'm going to answer in a way that doesn't necessarily follow your questions point for point but I hope helps clarify.
Resource GROUPS: All individual resources (which are what can have finite capacity defined for them via a unique MS-outlook-like shop calendar) must be created under a Resource group. Even when the resource group only contains one resource, this is true.
In your case LASER and PAINT will be single resources each under their own corresponding group.
You will have 5 Fabrication resources (FAB1, FAB2, FAB3, etc.,) - each potentially using its own unique capacity calendar (but it is possible you can get away with one applied to all). They will reside under a general FAB resource group.
The same paradigm applies to Final Assy and Testing. You will have to resource groups with 4 resources under Final Assy & 2 under Testing.
Since your capacity limits seem to be people (not equipment), you might want to use unique capacity calendars for each resource. That way you can turn off std work days when people are scheduled for vacation or add extra hours on specific days (in advance if you want) to represent planned overtime.
A word of caution on setting scheduling blocks greater than one for a resource group: If a resource group is assigned a 5day x 8hr/day week calendar, setting resource blocks to 2 means you can parallel process 2 OPs - but in HALF the calendar defined capacity. SO: 40hr wk, 1 sched block means 1 OP at a time thru the 40 hr capacity. 40hr wk, 2 sched blocks means 2 ops in parallel over a 20 hr (per block) capacity, 40 hr wk, 4 sched blocks means 4 ops in parallel over a 10 hr (per block) capacity.
Of the 4 consultants we've dealt with, NONE recommended ever setting scheduling blocks greater than 1.
The number of scheduling blocks (apparently) also has costing impacts. My memory on the details is fuzzy (as we just don't need to do it) but I think it results in your defined cost/hr being divided by the number of scheduling blocks when job costs are generated. (I could be very wrong about this... It was over a year ago we even entertained the thought of using multiple scheduling blocks).
That is why, since your capacity truly seems to be people based, creating multiple resources under resource groups likely makes more sense for you.
A decision you have to make is whether a job OP can be spread across all resources (if there are multiple ones capable of the process) or if you want an OP to always be scheduled sequentially through one of the five (using your FAB resource group as an example) resources under the group.
If a single OP split up into parallel activity is the rule, there is a checkbox in the set up to allow it. If you'd rather have five OPs from 5 jobs processed in parallel, don't check the box.
This can not be overridden within individual methods. It is purely a decision of desired behavior at the multi-resource resource group level.
Operations: Standard Operations are created that reference one or more resource groups or specific resources (with no limit I've seen yet as to how many can be specified.
Yours look simple:
A LASER std OP calling the laser resource group. (Doing this instead of calling the specific laser resource gives you the flexibility of buying a second laser some day and not having to update your system other than to add a 2nd laser under the laser resource group.)
A FAB std OP calling the FAB resource group. This will allow the scheduler to pick the 1st free FAB resource within the group to process your job OP (if you aren't allowing parallel processing of a single OP) or, if you have enabled parallel activity to be allowed, the scheduler will try to load portions of the OPs load as soon as additional FAB resources have free capacity available in your schedule.
(Etc., Etc., for the remainder of your resources - They will all be 'collected' for use in a part-rev method of manufacturing under the std OPs you create.)
A small (for us) but more complex example that might explain some things: We have 23 manual drill presses as resources under a resource group, 2 tappers as resources under a resource group, 2 old bridgeports & 1 old horizontal DRO mill as resources under a manual milling resource group, a 4 ton press + a stamping machine + a paint booth as resources under a 'finishing' resource group. That is 31 pieces of manual equipment. Our primary capacity limit is the people that operate them (14 people) so we have a labor resource group with 14 labor resources defined.
A std OP for Drilling would call for the drill press resource group (thus allowing the scheduler to use any of the drill presses available) AND the LABOR resource group (thus telling the scheduler at least one person resource must also be available).
We have Std OPs that have up to 3 resource capacity constraint references to resource groups and/or specific resources (like our 4 ton press).
At the method level, you create the OP to call the std OP and add the setup and cycle time for the specific processing you are doing to produce a part at that OP - and then you can add additional constraints (in our case - specific unique and qty limited tools and/or fixtures that are set up as resources under a general massive tools/fixtures resource group).
You asked how the global would treat two jobs as you described below. If they have the same req'd by date and the scheduling code you applied to each have the same priority multipliers associated with them, it would be confronted with a 'tie' of priorities (relative days late - relative in relation to the most late job in your shop - multiplied by each job's sched code priority multiplier would result in the sequence the global will schedule the multiple job ops in).
The higher the number calculated by the pre-global "Calculate Global Scheduling Order" process, the higher the priority so these jobs are attempted to be rescheduled by the global 1st (given first crack at your unloaded capacity model) versus ones that are very early and carrying low sched code priority multipliers.
When a 'tie' exists between two jobs, it appears the global resorts to a tie breaker of doing the alphanumerically lower job number 1st.
Clear as mud? :)
Rob Brown
--- On Sun, 9/14/08, Ken Williams <ken@intermountainel ectronics. com <mailto:ken% 40intermountaine lectronics. com> > wrote:
From: Ken Williams <ken@intermountainel ectronics. com <mailto:ken% 40intermountaine lectronics. com> >
Subject: RE: [Vantage] Finite Job Scheduling
To: vantage@yahoogroups .com <mailto:vantage% 40yahoogroups. com>
Date: Sunday, September 14, 2008, 4:46 PM
I appreciate the response Rob.
Fortunately, we're on 405a. I'll outline a high level overview of what we've got, perhaps you and the list can offer input moving forward.
As a quick recap, we've been live on the system for approaching two years. All our resources have been scheduled infinite. Our scheduling has always been a mess (going back before Vantage) and we're hoping to fully tackle it now. Finite scheduling seems to be a great way for us to do that.
We currently have 5 operations that need to be scheduled, all are Start-Finish:
Laser - machine ran by one operator
Fabrication - five people
Paint - one paint booth, though multiple projects can technically fit in at the same time, one person
Final Assembly - four people
Testing - two people
We've gone into the test server and tried to schedule everything using the global finite scheduling process, but we were unable to follow any sense of logic the system tried to apply. Here's a rough idea of a typical job with the following operations (10 hour day & ignoring weekends for easy math):
10 - Laser - 10 Hours (1 Day - Start 10/1, End 10/1)
20 - Fab - 100 Hours (2 Days - Start 10/2, End 10/3)
30 - Paint - 5 Hours (.5 Day - Start 10/4, End Mid 10/4)
40 - Final Assembly - 100 Hours (2.5 Days, Start Mid 10/4, End 10/6)
50 - Testing - 20 Hours (1 Day, Start 10/7, End 10/7)
So, things we're hung up on:
1. What is the system difference between an operation, resource & scheduling blocks?
For instance - Fabrication is an operation with a fab resource group that has 5 fab resources and 5 scheduling blocks, what should this operation look like?
2. What exactly is global finite scheduling process supposed to do based on the example above if we scheduled 2 of them?
3. What is global finite scheduling going to do when we say double the amount of hours in Fab for a 2nd job?
Hopefully this a good start. If we can get the above figured out, I think we can get the rest figured out, especially number 1.
Thanks for your help,
Ken
-----Original Message-----
From: Robert Brown [mailto:robertb_ versa@ yahoo.com]
Sent: Saturday, September 13, 2008 8:07 AM
To: Ken Williams
Subject: Re: [Vantage] Finite Job Scheduling
Ken,
What specific version are you running? I ask as there were SIGNIFICANT AND NUMEROUS bugs within the global finite scheduling processes prior to 405.
Even within 405, there is one (newly introduced) significant finite sched related bug that impacts forward scheduled jobs that can result in operations being scheduled out of the sequence defined in your methods (under certain common conditions).
...Not looking for a 'pay me' job (NO time to commit to that as I'm still dealing with our own Vantage issues)... But would be glad to offer any insights via email if you can describe your processes, resource paradigm and typical load issues as well as any 'soft' issues in your shop (people issues, equipment reliability issues, etc.,).
If your interested, please email me directly at xxx instead of the yahoo address if you have supporting docs to attach that yahoo will filter out.
If not, no problem - Good luck to you. You are in for an 'interesting' next few months.
Rob Brown
--- On Wed, 9/10/08, Ken Williams <ken@intermountaine l ectronics. com> wrote:
From: Ken Williams <ken@intermountaine l ectronics. com>
Subject: [Vantage] Finite Job Scheduling
To: vantage@yahoogroups .com
Date: Wednesday, September 10, 2008, 1:54 PM
We've been using Vantage for approaching 2 years, and in that time we've
done everything on infinite scheduling. We've also missed every due
date along the way.
Okay, that might be exaggerating, but it's obvious we don't know the
scheduling process as well as we'd like to. It seems finite scheduling
will actually be a huge step in the right direction (even though our
resources aren't quite as locked down as finite would make it), but
we're just having some issues understanding everything (scheduling
blocks vs operations vs resource groups vs resources, etc).
I'm hoping someone on this list would be willing to contract a few hours
of their time to help us out. A few of us have followed Epicor's
scheduling education program, we've read the help file inside and out,
we've been using the system for a long time....we just need some minor
tweaks and full descriptions of some things that we just can't seem to
get otherwise.
If you're willing and able to help us for a few hours, we can share our
desktop and allow you in to help us out. We're more than willing to
pay for this service, and we can even do it after hours if necessary.
Please contact me off list if you can help,
Ken Williams
ken@intermountainel ectronics. com
[Non-text portions of this message have been removed]
[Non-text portions of this message have been removed]