A goal is what the resource scheduling optimization (RSO) solution aims to optimize. An example of a goal is to maximize working hours or minimize travel time. You define how bookings should be optimized (constraints and objectives). The RSO engine processes a list of resources and a list of resource requirements, along with existing bookings, to create the optimal route or list of bookings for the resources. Bookings are considered optimally scheduled if they:
- Meet all company constraints.
- Have the highest possible score for the company’s objectives.
Default optimization goal
When RSO is deployed for the first time, the system automatically creates a default goal with some constraints and objectives enabled. Users can modify as needed or create a new optimization goal and associate it as a default goal.
Engine Effort Level determines how much effort RSO makes finding the best combination of resources, route, and day or time. The higher the effort, the longer RSO takes to complete the execution. For example, the effort might be very light, light, moderate, intense, or very intense. The higher the intensity, the more iterations of possible combinations the RSO engine considers.
The default goal is used when single resource optimization is selected from the schedule board.
Schedule Within Working Hours
This creates the booking if it can be completed within the resource’s working hours. Verifies the booking is not scheduled out of the resource’s working hours. This includes travel time from the last booking to the resource’s end location, although it’s not visually displayed on the schedule board.
Meets Required Characteristics
This verifies the resource has all the required characteristics and should have minimum required skill level.
Meets Required Roles
As of RSO v3.0.19263.1+, RSO will respect the resource roles added to a requirement. If for example, the requirement calls for a resource with the role "Robotics Engineer", RSO will schedule to a resource who has that role. If the requirement calls for two resource roles, RSO will schedule the requirement to resources that have either of those roles, following "OR" logic.
Scheduling Lock Option
If marked, RSO will respect lock options configured on a bookable resource booking record.
- Time Range
- Resource + Time
If marked, RSO will schedule work to comply within the time window start and end fields on the resource requirement or booking record.
- If From Date and To Date on resource requirement or Date Window Start and Date Window End on resource booking are set as shown in the following example, it indicates you want RSO to schedule the booking on 5/24/2018 and time of day doesn’t matter.
- If Time Window Start and Time Window End are set as shown in the following example, it indicates you want RSO to schedule a booking from 2:00 AM to 6:00 AM and the date doesn’t matter.
- If Time From Promised and Time To Promised are set as shown in the following example, it indicates you want RSO to schedule a booking between 4:00 AM and 8:00 AM on 5/24/2018. It has to be a specific date and specific time range.
- If these fields are conflicting, RSO uses Time From Promised and Time To Promised first. Then it will use one or a combination of other fields.
- RSO will ensure the Estimated Arrival Time falls into the window specified above. It does not guarantee that the booking’s end time will fall within the time window.
- Empty time values (v3.0+) RSO will respect scenarios when only a start or end time is defined on a requirement.
In the following example, a requirement has only a time window start value; RSO schedules the requirement anytime after 1:00 PM regardless of date.
This logic applies to the following fields.
On the resource requirement entity: - Time Window Start and Time Window End - Time From Promised and Time To Promised - From Date and To Date
On the resource booking entity: - Time Window Start and Time Window End - Time From Promised and Time To Promised - From Date and To Date
Meets Resource Preferences
Formerly called "Restricted Resources" constraint, the constraint was expanded to include all resource preferences on requirements as of RSO v3.0.19263.1.
If marked, RSO will respect the three different types of resource preferences on a requirement:
- Preferred - RSO will give scheduling preference to the resource if the resource is available but will not guarantee as RSO may need to balance overall objectives such as minimizing travel time.
- Restricted - RSO will not schedule to resources who are added to requirements with this resource preference
- Must choose from - RSO will schedule to this resource given the resource is available during the time range of RSO. You can add multiple resources with a "Must choose from" preference and RSO will schedule to one of them; the first that is available.
If marked, RSO will respect the Territory field value on the requirement. As a reminder, a requirement can only belong to one territory, but resources can belong to multiple.
Matches Resource Type
As of RSO v2.8+, RSO will match the resource type between requirements and resources to decide which type of resource can fulfill a requirement.
Bookable resources include these types:
- Generic *
- Users *
- Contacts *
- Accounts *
- Equipment *
- Facility *
* Indicates resource types the optimization will consider
In general, resource types define how the resource relates to the organization. For example, resources with the resource type Users are typically employees, whereas the resource type Contacts or Accounts are typically contractors.
Additionally, requirements allow multi-select so you can specify which resource types you need for a given requirement.
Add and rank the objectives of RSO scheduling by using the Move Up and Move Down buttons, as seen in the following screenshot.
Maximize total working hours: The combination of the engine results
Iteration with the total highest aggregate work time will best meet this objective.
Minimize total travel time: The version of the engine results
Iteration with the total lowest aggregate travel time will best meet this objective.
This cannot be the first objective in the list. RSO might not schedule anything with the travel time as 0 minutes in order to meet the first objective.
Once a booking is created, a lock can be set on the scheduling lock options field in the RSO section of the booking. The options are Time Range, Resource, Time, and Resource and Time. When the locked bookings objective is selected, RSO will try to include locked bookings into the optimal route. For example, the following screenshot shows that Norbert has a booking that starts at 2:30 AM, and this booking is locked toTime. When RSO runs, the system detects a 30-minute idle time for Norbert in the morning, but none of the other requirement durations fit into that slot with the locked booking next to it, even though RSO tries to move it to other resources’ time.
If locked booking is a high-ranking objective, RSO will keep the locked booking there with 30 minutes of idle time before it by sacrificing the other objectives. The following screenshot shows the result.
If locked booking is not a selected objective or is ranked lower in the order of importance for objectives, RSO might ignore this locked booking (exclude this locked booking from the optimal route) and schedule other bookings for Matthew at 2:30 AM in order to achieve the highest score for top-ranking objectives, with the result shown in the following screenshot. It looks as if a booking overlaps, but actually the locked booking was ignored in this case. RSO would not delete the locked booking because it would lose the lock information defined on the booking record, which can’t be retrieved from the backing requirement.
High priority requirements
RSO will evaluate this objective and give priority to the resource/booking combination with the highest score for priority. The priority is set on the resource requirement record and is an option set with weighted values. RSO checks Level of Importance on priority to determine how important that priority is—for example, set Level of Importance = 10 for urgent priority and set Level of Importance = 1 for low priority and RSO will score 1 urgent requirement the same as 10 low-priority requirements because both scores are 10.
Maximize Preferred Resources (v3.0+):
RSO will consider the list of preferred resources noted on related requirements. The optimizer will try to assign bookings to preferred resources first while meeting other constraints and objectives.
This is achieved by adding the "Maximize Preferred Resources" objective to your RSO goal and adding a preferred resource(s) on the requirement that will be optimized.
The following screenshot shows an example of adding a resource to a requirement (for example: Jorge Gault) as a preferred resource.
After running an optimization schedule, the requirement is scheduled to the preferred resource. In the following example, work order 00100 is scheduled to Jorge Gault.
The Maximize Preferred Resources objective only applies to preferred resources.
Best Matching Skill Level (v3.0+)
RSO will consider the proficiency rating when matching characteristics required by requirements and the resources who possess those characteristics. This is dependent on the Meets Required Characteristic constraint within the optimization goal.
If the "Meets Required Characteristics" constraint is checked:
- Resources without the characteristic (skill) or lower-than-required proficiency ratings are not eligible at all
- Resources with the exact skill level (best matching) get the highest score
- The more overqualified a resource is, the lower score their score will be
If the "Meets Required Characteristics" constraint is unchecked:
- Less qualified resources and resources without the skill can still be booked
- Overqualified resources get a higher score than less qualified resources
- The more overqualified a resource is, the lower their score will be
- The less qualified a resource is, the lower their score will be
- Resources without the skill get the lowest score
For example, if a characteristic (skill) rating model ranges from 1 to 10, and the requirement asks for a skill level of 4, the following example shows the score distribution based on skill level of the resource.
In the 2020 release wave 2 update, the Best matching skill level objective was enhanced to prioritize assigning jobs to resources with fewer skills first. This is valuable for organizations that have a workforce with varying skillsets. Assigning jobs to resources with fewer skills or more common skills first when there is more capacity than demand allows RSO to reserve capacity for resources with multiple and unique skills for higher priority emergency situations. For example, imagine one resource has installation skills and another resource has installation and repair skills. RSO will initially schedule installation jobs to the first resource who only has installation skills. This is advantageous because if a repair job needs to be scheduled later, the second resource will have capacity; if all the installation jobs were scheduled to the second resource, then no one would be available for the repair job since the first resource does not have the skills for repairs. This improvement to the Best Matching Skill level objective requires no additional configuration and is an update to the background algorithm.
Schedule as soon as possible
Occasionally, there may be more resource capacity than there is demand for resources (for example, total time of work orders is less than total available time of resources). In these circumstances, there is a business decision about whether to fully book some resources or leave resources with some capacity as a contingency for emergency or unplanned work.
In order to effectively front load optimized bookings, add the Schedule As Soon As Possible objective into your Optimization Goal in the corresponding order: