Exploring Automated and Assisted Scheduling

Within Field Service Management, three modes of scheduling are distinguished. They differ in the balance of manual involvement versus machine processing.​

Manual Planning

is the classic way of assigning activities to technicians: by drag and drop, possibly using the various filter options on the planning board to find suitable technicians.

Assisted Planning

consists of various functions on the planning board that help the dispatcher find suitable technicians and fill or rearrange their schedules in an efficient way. These functions are triggered manually, on request by the user.

Automatic planning and optimization

-also referred to as Autoscheduling- refer to completely automatic assignment of activities to technicians, or the re-optimization of existing assignments. Autoscheduling has similarities with Assisted Planning, but is executed without user input, instead relying on event- or schedule-driven business rules.

Both Assisted Planning and Autoscheduling share much of the same technical infrastructure and use the same data. Both features rely on so-called policies, that determine which candidate assignments are valid, and which candidate assignments are considered 'optimal'.

Assisted or automatic scheduling can be used in a number of different ways. These use cases are supported by different features and APIs. In the background, the features and APIs rely on the Field Service Management Autoscheduling Framework for processing the data and delivering the required output. Examples include the following:

• Best Matching Technician (also called 'Find Matching Technician'): who is best suited to execute a currently unplanned job
• Planning Widget: assign several currently unplanned jobs in an optimized schedule or sequence

A further feature, the Slot Finding API, helps, for a given activity, to find the best-matching technician in one or more time slot slots. This feature is however only available via a technical interface (API), and is not available on the UI. As such, it is not discussed further in this section.

Autoscheduling refers to scheduling and optimization without user intervention, usually through a business rule. It can be based on specific events (as detected on the database) or on specific schedules. Autoscheduling can also be triggered externally, for example, by an external service or system.​

Depending on the use case, a set of activities are newly assigned and/or reassigned ​to a set of technicians.

For example, a periodic re-optimization could do the following: every night, a business rule selects the activities already assigned for execution the day after tomorrow, and unassigned activities that could be executed in the same period. It selects technicians with the job title 'field service engineer'. It then calculates a new optimal schedule, possibly assigning new activities, possibly discarding existing assignments, and possibly rearranging the sequence of activities for technicians.

Another example is the automatic assignment of a new activity: When a new activity is created (for example through integration), this event triggers a business rule that starts optimization framework for this single activity and all available technicians. This prevents jobs from backing up in the queue awaiting a scheduled planning round or manual intervention .

All functions relating to assisted- or automatic scheduling rely on a consistently high data quality. For example, data related to dates and times, locations, and skills/skill requirements need to be available and precise. More on this in the related advanced section.

In automatic scheduling, a business rule:

1. Reacts to a trigger: either a schedule or an event.
2. Collects the necessary data: arrays of activities and technicians.
3. Adds various parameters regarding the required autoscheduling behavior.
4. Combines this data into an API call, sending it to the Field Service Management autoscheduling component.

The optimization component, upon receiving the API call, proceeds to collect the necessary additional data. The optimization module then generates many possible candidate assignments of activities to technicians. Invalid assignments are discarded and the remaining ones are scored. The best-scoring assignments are selected and implemented. The generation, scoring, and selection of assignments continues until all activities have been assigned, or no more assignments are possible.

For example, a periodic re-optimization could do the following: every night, a business rule selects the activities already assigned for execution the day after tomorrow, and unassigned activities that could be executed in the same period. It selects technicians with the job title 'field service engineer'. The data is sent to the optimization framework, which proceeds to collect the necessary additional data. The optimization module generates, scores, and selects candidate assignments. This continues until all activities have been assigned, or no more assignments are possible. ​

This is an example of a scheduled business rule that runs every hour, executing an action of the type "automatically schedule activities". Note that the queries in the BR variables are quite basic, and could be enhanced by joining other tables. In addition, several JavaScript functions are used in the action, to dynamically fill the various parameters.

Depending on the use case, the appropriate trigger event or trigger schedule needs to be defined. For example, the creation of an activity could be the trigger to automatically submit it to autoscheduling. An alternative example is to use a time schedule, according to which all new activities which were created in a certain time interval are collected and simultaneously auto-scheduled.

After the business rule has been triggered, the appropriate data regarding activities (also referred to as ‘Jobs’) and technicians needs to be collected by using variables. This means that the CoreSQL queries need to be tailored to your use case - for example:

• All open Activities having due dates <= today + 3 days AND priority ‘High’ AND Requirement ‘gas pumps’.
• All Persons having plannable = TRUE and having the Skill ‘gas pumps’.

In most cases, a number of preconditions must be met before autoscheduling can or should be executed. The Conditions section of the business rule trigger is used to define the prerequisites for the subsequent actions.

A very common set of conditions is to check the number of technicians and activities that were selected. Both amounts must be larger than 0 for autoscheduling to make sense.

In the business rule action for autoscheduling, the ID's of the activities and technicians need to be inserted as JSON arrays. This can be done with a JavaScript function. The behavior of the Autoscheduling Framework can be modulated using specific parameters.

In addition to the Jobs and Technicians, further parameters for Autoscheduling are needed or can optionally be set to modulate the autoscheduling input and output. These parameters include the following:

• Start and end date of the planning horizon (the target time window in which the optimizer tries to schedule the assignments).
• Optimization Policy to be used.
• Partitioning (optional, see next slide).
• Release Activities when/if successfully scheduled (y/n).

In order to improve throughput times for an autoscheduling run, partitioning can be used. ​

​A partition is a subset of the activities and technicians that were submitted by the business rule (or API call). The separation criterium is a skill (requirement) that technicians and activities have in common.​ ​The list of partitioning skills should therefore define distinct subsets of activities and technicians.​

​Which skills are used for partitioning depends on the specific business needs. Common examples include the following:​

• Skills and requirements representing regions​

• Skills and requirements representing organizational units​

• Skills and requirements representing technical expertise​.

The desired partitions, and the sequence of processing, are defined in the Partitioning Strategy Skills field. Preliminary checks ensure there are no conflicts during parallel scheduling of partitions.

As long as there’s no overlap between the subsets, the Autoscheduling Framework can process (schedule) the subsets simultaneously. In this way, the overall processing throughput time is reduced.​

​If, however, if several partitions share the same technicians or activities, the corresponding partitions are processed sequentially in the order as defined in the Partitioning Strategy Skills field.​

By allowing parallel scheduling of smaller datasets, partitioning reduces the overall throughput time for an autoscheduling task. At the same time, even in case of sequential processing of the smaller datasets, the system loads and processing times are reduced.

Instead of using partitioning within the autoscheduling task, you can also set up your business rule(s) to create separate autoscheduling tasks, each with different payloads of technicians and activities.

After a business rule or other client submits the autoscheduling task, the autoscheduling framework collect additional background data, like:​

• Pre-existing bookings for technicians
• WorkTime Patterns
• Skills

Subsequently, many different candidate assignments are generated. The validity of these candidate assignments are checked with certain rules, with invalid assignments being discarded. The remaining valid assignments are then scored based on certain objectives. The assignment with the highest score is assigned and the process is repeated for the remaining activities until all are assigned or no more assignments are possible. This process is governed by the Autoscheduling Policy.

An optimization policy combines a set of hard rules and soft objectives that together define which possible assignments are considered valid and optimal. An Optimization Policy consists of the following:

• General Settings: govern Candidate Assignment generation
• Rules: determine whether a possible assignment is considered at all
• Objectives: are scoring criteria, awarding points to possible assignments

FSM comes with several default Policies out-of-the-box. If these do not fit the business needs, it is also possible to create custom policies. This feature requires a corresponding license agreement.

A policy is composed of various rules and objectives. Most of building blocks take parameters that modulate their behavior. The rules and objectives can be combined using logical operators to achieve the desired effect.

Rules include for example:

• Respect Job Deadline
• Respect Technician Work Time Pattern
• ResourceHasOptionalSkills

Objectives include for example:

• Driving Time
• Optional Skills
• Rule-based

Optimization policies can be created, viewed, and changed in the policy designer. The policy designer can be found in the Foundational Services module. Features include the following:​

• Policies can be downloaded, uploaded, duplicated and changed
• Status management (draft / released status) and automatic versioning
• Modify general settings (responsible for the generation of candidate assignments) and parameters of
• Add or remove logical operators, rules and objectives using drag and drop
• Modify parameters of rules and objectives

This image shows an example of the objectives of a custom policy (left), and the available building blocks (right). ​The Rules and Objective sections each have a graphical representation of the individual elements (building blocks) and their relationships. The context menu for each element provides a brief explanation, including example use cases, as well as access to the relevant parameters of the element. The Policy Objectives can consist of a mix of rule-based objectives (which award points based on true/false evaluations) as well as 'normal' objectives (which award points based on some gliding scale, like driving time between 0 and a certain maximum).

The policy comes into play when scheduling is triggered, for example, by a business rule, by the best matching technician function, or the appointment booking API. The selected jobs and technicians are evaluated according to the applied policy. For each technician, the earliest possible valid candidate assignment for each activity is determined. These earliest valid assignment are then scored using the policy objectives.

The schedule is built in iterations using a greedy algorithm. This means that at every iteration, out of all the (earliest valid) job-technician combinations, only the one with the highest score is picked and assigned. This process is repeated for the remaining activities until either all jobs are assigned or no more technicians are available.

Autoscheduling, as well as Assisted Scheduling, requires very high data quality. Missing or incorrect data are very likely to lead to errors which may go unnoticed until technicians are confronted with suboptimal routes. Other consequences could include the following:

• Activities being assigned to technicians who don't have the necessary skills
• Activities being assigned to technicians who are too far away
• Activities not being assigned at all
• And so on

To ensure the proper functioning of autoscheduling and assisted scheduling, activities must have the following properties maintained correctly and completely:

• Skill requirements
• Earliest start date, duration, and due date
• Addresses with Geo-Location (this is required by the Framework, even if the Policy doesn't consider distance or driving times)

In the same way, person (technicians) must have the following data maintained correctly and completely:

• Skill qualifications
• Home- or Work address with Geo-location
• A valid and non-overlapping WorkTimePattern

For persons, live geolocations are optional. Additional information related to the technician's availability should also be maintained, like bank holidays and other time slots in which they are not available. This could include private holidays/time-off or exclusive reservations.

Limitations

Driving Time Calculation

The service only calculates car driving times. There is no functionality to consider any other ways of traveling, such as using public transportation, ferries, or aeroplanes.

The geocoordinates of the addresses are the input for the calculation, therefore the system only considers addresses with geocoordinates for the scheduling.

Limited Partition Size

Single scheduling tasks are limited in terms of activities, technicians, and planning horizon days. It is strongly recommended to stay within the following limits:

• 3000 jobs (activities)
• 30 technicians
• 30 days planning horizon (difference between scheduling horizon start and end dates)

The above limits are approximate and can vary based on factors such as the number of pre-assigned activities (bookings). For example, scheduling 3000 activities x 30 technicians x 30 days in a single task may not be supported with an excessive number of bookings (pre-assigned activities). However, these limits can sometimes be exceeded with efficient policies that pre-filter undesired assignments and have fewer existing bookings, allowing for task sizes like 2000 activities x 50 technicians x 5 days. The technical maximum number of technicians is 100.

In the case that customers have partitions with more activities but fewer technicians, the supported partition size can be calculated as follows: 3,000 x 30 = 90,000 points. This means that as long as the overall number of points (number of technicians multiplied by the number of activities) does not exceed the limit of 90,000 (per partition in an autoscheduling task), it should not affect the performance of the autoscheduler in a negative way.

Scheduling of partitions of larger sizes can lead to noticeable performance degradation.

To avoid failures and ensure performance:

• Design the business rules to submit only relevant activities and technicians
• Limit planning horizons
• Break up scheduling into smaller individual scheduling tasks, or use partitioning within scheduling tasks
• Keep policies simple
• Test new policies with real customer data and use cases

Whenever a scheduling task has been called and completed, a report is generated with the corresponding details. Reports are generated for almost all types of automatic- or assisted scheduling tasks and methods, whether from an integrated system (API call), a business rule, the planning widget, or a quick planning function. Exceptions are "Best Matching Technician" and "Appointment Booking API", for which no reports are generated.

A Report contains complex and detailed information, which is relevant to mainly technical consultants:

• Key figures
• Map with simplified routes for each day in the planning horizon
• Assignment scoring results, showing technicians’ scores for a given Job
• Error messages

Known limitations:

• Previously generated reports are automatically deleted after 30 days. You can download the reports and store them offline in case long-term access is required.
• The score log of a report is automatically truncated if a certain threshold (currently 25 megabytes) is reached.
• Opening large reports takes time, up to a minute. If you open multiple large reports in parallel, it takes longer to generate the reports and this can lead to errors.

Generating a report leads to an attachment of type HTML to get created and saved in DTO attachment.

To use the application you need to ensure that the users have access to the optimization reporting app.

1. Access the Administration application of SAP Field Service Management.
2. Navigate to User Groups on the account level and make sure that all user groups allowed to use auto-scheduling reports have access to the "optimization-reporting" OAUTH client.
3. Option 1: Set clients (OAuth2 API) to all by not selecting any particular client.

   Option 2: Add client optimization-reporting to the selection.

To open the application, navigate to Analytics and Reporting → Reports → Auto-Scheduling Reports.