I’m trying to put the pieces together from various threads, but something isn’t clicking. What are the cardinality (one-to-many, etc.) relationships between operations, capabilities, and resources?
How is a resource selected based on some property of the work? The classic example is a big drill and a small drill. The big drill can do small jobs, but the small drill can’t do big jobs. So I think you’d define capabilities like “drill-big” and “drill-small”, and add both resources to the “small” capability, but only add the big drill to the “big” capability… right? The part I don’t understand is how you then determine whether a job is big or small. Do “big” jobs have an operation that is only associated with the “big” capability, while “small” jobs have a different operation that is associated with both capabilities?
This can be very complex as Operations (top level in my cardinality example) can utilize N > 0 resources depending on your company’s needs. This can be a Big Drill, plus an Human Operator, plus an optional Drill Sharpener. The capabilities are defined as needed then attached to each resource in the group (part of the setup process in ERP). I would limit their creation to only the specific differences. You would not need a ‘small jobs’ capability if all of your resources in that group can do small jobs - you would only need a ‘big jobs’ capability to differentiate those resources that can do large jobs (and can do small jobs). But you could do it either way really.
Then it becomes a function of how you are going to get the ‘need’ for a capability onto the operation and send the hint/clue to the scheduler to choose the correct resources for the operation. You can do this in the original MOM, alter it in the MOM when a job is manually created/configured, or if you use the Configurator, it can be done using logic and rules to add capabilities dynamically based on options chosen.
Without more to go on, that’s the best generic answer I can start you off with. Hope that helps.
While this makes sense, this is not the understanding I’ve gathered from numerous conversations on these forums.
From what I’ve been told:
Resource Groups are a larger group.
Resources are individuals within those groups.
Capabilities are used to cross resource groups. Capabilities with a single resource can break scheduling.
Following this logic. Small drills would go in one group. Large drill would go in another group. A capability for small drills would be given to all these drills.
When designing the operation, the drill-small capability would be chosen as a requirement for those operations where it is needed. This would allow global scheduling to pull from either resource group.
If the drill-big “capability” were required for an operation, the resource group holding the single large drill would be chosen as the requirement. A capability would not be used for this.
This is my understanding from my conversation with @Gil_V and others. Hopefully if I’m misspeaking here, others can correct me.
Capabilities are weird. They do work, though. Generally, a capability allows you to break the resource group/resource relationship on an operation when a resource is overloaded.
You have to remove the resource group AND resource callout, and add the capability. Then, the capability has to specify the resources (and you select the order in which they will be loaded). It is important to specify all of the resources that the part can run on, as the operator will only be allowed to specify the resources contained in the capability when clocking. (We learned that the hard way).
What I generally do is specify the alternates as the first possible choice (oddly enough, that means it will have the “highest priority number”). Then, I list the original resource as the “lowest priority number”. I’ve snipped one below for illustration.
In an infinite environment, I have no idea how the system selects the resource from the capability. (we run full finite here). I suspect it will take the “highest priority number” resource, as that seems to be normal operation of the scheduling engine.
Machine 14 is in a different resource group than machines 55 and 78. The way this will work is the system will look for time on machine 55 first, machine 78 second, and lastly Machine 14.
A lot of shops use resource groups to combine machines with similar capabilities, that is a very common business practice. This feature allows you to work around that when you have an item with unusual characteristics - in that the capabilities of the equipment are NOT common for the part/op you are examining. (Think of a lathe that operates with a certain specification. You may have three large lathes in a group, and three small lathes in another group. But, only one of the lathes in each group has the specification the item requires, and the part can run on either large or small, but needs this specification). Instead of having to reconstruct the resource groups, you just create a capability for the part/op.
This may not answer your question directly, but hopefully is helpful.
We have a similar scenario: Heavy Press Resource Group. Two Resources: 1000 ton and 600 ton.
1000 ton can do everything a 600 ton can do, but not reverse.
Capability 1000Ton is assigned Resource 1000TonPress
Capability 600Ton is assigned Resource 600TonPress (priority 3) - and - 1000TonPress (priority 1)
3 is the higher priority.
MOM Operation BLANK Capability is set to 600TonPress (or 1000TonPress) as appropriate.
We found that the scheduling system, for the 600TonPress, scheduled all of the work to the 1000TonPress until we made the Resources Finite and Scheduled Finite (through Process MRP or Job Scheduling when jobs were created).
There may be alternate ways, with the above setup, to make the system schedule in both presses even if they are both infinite.
Thanks for all the replies. It does sound like capabilities are the right tool for what I’m trying to accomplish. We have two production lines, one automated and one manual. The manual line can do any material and switch materials easily. The automated line is more efficient, but it takes time and wastes a significant amount of material to switch materials. So we have the automated line set up for the most common material, and we want jobs using that material to be scheduled on the automated line until it’s running at capacity. Excess jobs using the common material, and all jobs using other materials, should go to the manual line. So I think the special capability I need to represent is the “odd size” capability of the manual line, and add/keep that capability on the MoM when the configured material is an odd size.
We use capabilities to manage our print abilities. Example take a Paper Bag size 8 1/2 x 11. We can produce that on machines 102, 106, 107, 108 without print. So we created a capability for plain bags with all those machines on it. Then a capability for 1 color, then 2 color, then 3 color and so on. We have one machine that can run 4 colors all the rest can only run 3 max
I have never heard that, but could it be that if a Capability has only has one Resource then why use a Capability, you could just put the Resource on the MOM.
We may need a Tim Shoemaker type person to answer some of this.
Just expanding on the mechanics and logic of above comment.
If you decide to you have one Resource to one Capability, then if you have 5 machines that have that capability, you have to create 5 Capabilities X1, X2,…X5.
And, since you can only load one Capability to the MOM (per OpDtl) you limit your scheduling flexibility. And…you could just load the resource and get the same result.
We do it for consistency sake and future flexibility. In most cases we can buy parts that make our workcenters capable of additional printing. So say we have 500 parts setup with capability x that has only one resource vs having the group and resource filled in. We update a machine and add that machine to capability Y. Now all 500 parts automatically can be scheduled on the new machine no re-engineering necessary.
That might very well work, at one time I envisioned an environment where all you used were capabilities (instead of resources) on the methods, and you allow the scheduler to balance the workload across capabilities instead of across resources.
It would be much more flexible than the default “resource group/resource” callouts. It is in effect a way around the limitations of the default resource group construction.
At one of our facilities that is essentially what they do, capabilities run almost everything. Caveat; it is unproven, but I think mostly because of transactional discipline/accuracy, and some other supporting parameters and processes.
