Resource Constraints¶
The following constraints all affect which resources any activity may be allocated to.
Skills¶
An activity may have some required skills specified for it: if so, then it must be performed by a resource which has all of those skills. If no skills are specified on an activity, then any resource may do it. See the schema entities Skill, Activity_Skill and Resource_Skill.
Resource Skills may specify a Resource_Skill_Availability, which limits the times at which the resource has the skill. This would be useful, for instance, to represent certifications or licences that need to be renewed annually.
Resources may have skills with a certain proficiency. More proficient resources will complete activities more quickly than less proficient ones. The proficiency may also be linked to an availability to allow the proficiency to vary over time.
Skill costs and preferences¶
Resources may have costs which apply to individual skills when they are used to complete an activity. This is set using the in_use_cost and not_in_use_cost attributes on the skill. This is useful when you want the scheduler to allocate activities to resources that meet the skill requirements, but do not have an abundance of extra skills; thus keeping higher skilled resources free.
Instead of a cost, a multiplier can be defined on the resource's preference. This is set using the in_use_multiplier and not_in_use_multiplier attributes on the skill.
The 'in use' skill attributes apply when the skill is available and in use. The 'not in use' skill attributes apply when the skill is not being used but is available.
All four attributes: in_use_cost, not_in_use_cost, in_use_multiplier and not_in_use_multiplier are available on the Skill, Resource_Skill, Resource_Type_Skill and Resource_Skill_Availability tables.
Note
In the case where multiple skill availabilities overlap with the same override priority, we take the maximum values.
Note
The 'not in use' attributes are to be used only in the case where urgent work is expected to come in frequently and we want to keep higher skilled resources free.
Note
The 'in use' attributes are used to give preference to a certain resource based on a skill, this will not affect the duration of the activity unlike a proficiency does.
Note
When a team resource is created from modelling data, the Resource_Skill has the skill attributes set up in the following ways: the in_use_cost and not_in_use_cost attributes across the relevant resources are summed together for the team resource; the in_use_multiplier and not_in_use_multiplier are calculated by multiplying the maximum multiplier greater than 1 with the minimum multiplier less than 1. For example, if there were three resources making up a team resource and (for the same skill) they have in use costs of 50, 100 and 150 respectively, the in_use_cost for the team resource for this skill would be 300. If they have in use multipliers of 0.5, 1.5 and 2, the in_use_multiplier for the team resource for this skill would be 1 (as we would take 0.5 * 2).
Regions¶
Regions may be specified for activities and resources, and these are commonly based on geography, although they do not need to be. If an activity is in a region, then the resource must be in the region also, or in a region whose parent region (or more distant ancestor) is the activity region. See the table below for an example.
If an activity is in more than one region, then the resource must be in all of the regions. If an activity is not in a region, then all resources may do the activity (from the point of view of regions)
Regions are actually specified using Location_Region (for activities) and Resource_Region (for resources).
| Activity Region | Resource Region | Result |
|---|---|---|
| Nottinghamshire | England | Scheduled. Resource is in a parent region. |
| England | Nottinghamshire | Not scheduled. Resource is only in a child region. |
| England, Subcontracted | Subcontracted | Not scheduled. Resource is not in both of the required regions. |
| None | England | Scheduled. No regions are required by the activity, so anybody can do it. |
Region Preferences¶
Regions do not have to be a hard constraint, as described above. Instead of insisting that a resource is in the same region as an activity, this can be specified as a preference, so that the Dynamic Scheduling Engine will try to schedule the activity to a resource within the region, but if none is available, it will use a resource from outside the region.
To determine whether regions are a hard or a soft constraint, each resource has an out_of_region_multiplier. If this is set to zero, then the resource may not work outside their region(s). If it is set to 1, then regions have no effect: they may work anywhere. If it is set to a value between 0 and 1, then they will prefer to work in their own region, but may work outside it if needed.
It is also possible to set a within_region_multiplier for a resource and a given region, which may be used to specify that a resource has a preference to work in that region.
If an activity requires a resource to be in multiple regions, then the within_region_multiplier values for the resource in those regions will be combined. When combining multipliers, the 'override_priority' attribute is used initially to filter which multipliers are applied - only those with the highest override_priority will be used. Any remaining multipliers are then applied in combination.
The following table illustrates the above points with some examples.
| Activity Region | Resource Region | Multipliers | Result |
|---|---|---|---|
| Nottinghamshire | Leicestershire | out of region multiplier=0.5 | May be scheduled, if there is no better resource. Constraint is now a preference for the resource to not do activities in Leicestershire, rather than a hard constraint. |
| Derbyshire | Derbyshire, Leicestershire, Nottinghamshire | within region multiplier=1.5 (Notts); 1.2 (Derbys); 0.9 (Leics) | Scheduled. Resource prefers to do activities in Nottinghamshire, and then Derbyshire, and then Leicestershire |
| Nottinghamshire, Subcontracted | Nottinghamshire, Subcontracted | within region multiplier=1.5 (Notts); 0.9 (Subcontracted) | Scheduled. Preference for resource is 1.5 * 0.9 = 1.35. |
| Nottinghamshire, Subcontracted | Nottinghamshire, Subcontracted | within region multiplier=1.5 (Notts); 0.9 (Subcontracted). override_priority=1 (Notts); 2 (Subcontracted). | Scheduled, but preference for resource is 0.9, so another resource may be preferable. |
Note
(For those who don't live in the UK) Derbyshire, Leicestershire and Nottinghamshire are all counties in England, and we assume that the region hierarchy has been set up with this information - i.e. the counties are all child regions of England. "Subcontracted" is a non-geographically defined region.
Region Availability¶
Regions may also have a Resource_Region_Availability specified, which defines a period of time in which the resource belongs to the region. Activities requiring the region may only be scheduled to the resource at times within the availability (this can be start-based or end-based - see the Availabilities section in this guide). The within_region_multiplier may be set in this table, allowing the multiplier to vary over time.
Warning
It is recommended that Regions are not used unless strictly necessary. The Dynamic Scheduling Engine will in any case try to keep resources near their home location, in order to minimise travel, so there is no need to add regions merely to reduce travel costs.
Parts¶
A resource may require a part in order to perform an activity, and each resource may have a given number of parts. For instance, a washing machine repair engineer may only carry two spare washing machine drums in their van, so it is not possible to do more than two such activities in the day, unless they return to base to collect more.
There are many ways of using parts and depots, full details of which may be found in the document Scheduling Concepts - Parts
Resource Pools¶
Resource Pools define a set of resources that are grouped together. Activities can then be grouped together in activity chains, ensuring that all resources assigned to that chain's activity are members of the same pool. This can be useful to assiging work to resources that should perform a set of activities together but gives the Dynamic Scheduling Engine the power to select which pool is best to perform the activities. The shift_id may be set on the resource_pool_item table to allow resources to join pools for given shifts.
Full details of using resource pools and activity chains may be found in the document Scheduling Concepts - Linking Activities
Resource Preferences¶
Resource Preferences instruct the scheduler to prefer to choose a given resource or resource type for an activity, activity type or location or prefer not to do so. The preference is on a sliding scale from 0 (don't do it) to 1 (must do it). Values between 0 and 1 specify preferences, rather than a hard constraint.
If any resource preferences are created with values of 1, then one of these resources must be used for the activity or location. So if resource A and B have a preference of 1 for an activity, and resource C has preference 0.9, then only A or B may be allocated to the activity, despite the strong soft preference for resource C. As another example, if resource preferences are created with values of 0.5 and then one with a value of 1 then only this last one will be considered for having the activity allocated.
The DSE will prefer particular resources for an activity by internally modifying the value for the activity if that resource is used. So for example an activity with a normal value of 1000 will have a resultant value (for allocating the activity to a resource) as shown below for various preference values:
| Preference | Value | |
|---|---|---|
| 0 | 0 | (activity will not be allocated to this resource) |
| 0.1 | 200 | |
| 0.5 | 1000 | |
| 0.9 | 1800 | |
| 1.0 | 2000 | (also stops resources with a preference less than 1 being chosen) |
| Not specified | 1000 |
Note
When no resource preference is specified for some resources but exists for others then those without a resource preference defined have a default preference value of 0.5.
Note
Where a preference exists for the resource type and the resource of that type against an activity/location then the preferences will be combined as follows. If either of the preferences has a higher override priority than the other, then it will be used. With equal override priorities, if either of the preferences is 0, the result will be a preference of 0. If either of the preferences is 1, the result will be a preference of 1. If the preferences are 0 and 1, this is invalid and the result is undefined. Otherwise, the preferences A and B will be combined using the formula "(A * B) / (((1 - A) * (1 - B)) + (A * B))".
For example, if a preference of 0.8 is combined with a preference of 0.3 then the resulting preference would be (0.8 * 0.3) / (((1 - 0.8) * (1 - 0.3)) + (0.8 * 0.3)) = 0.63.
A resource preference can be defined to only apply for a particular period of time by setting the availability_id or availability_pattern_id columns. A resource preference without any defined availability will apply for the entire timeline. If no defined resource preference can be found at a particular time, then the default resource preference of 0.5 will be used.
If two availabilities overlap, or an availability is used when there is also a preference applying over the entire timeline (no defined availability), then the two preferences will be combined in the same way as described above.