This description is divided into the following sections:
360 Scheduling is a scalable optimization framework which conducts advanced mobile workforce scheduling.
The integration of 360 Scheduling with IFS Applications provides functionality for scheduling work orders to maintenance employees in order to:
Resources (employees) and activities (separate or route work orders) are sent from IFS Applications to the Scheduling Engine where they are scheduled. The scheduling is conducted based on the following:
Once scheduled, an allocation plan is returned to IFS Applications and the work order can be updated through any of the following methods:
Both inbound and outbound integration use XML messages that are sent and received via standard IFS Connect functionality.
Note: In 360 Scheduling, permission groups define which users are allowed to view a set of resources and activities. These permission groups are called object groups. In the integration, object groups have the equivalence of sites in IFS Applications. This means that in order for a 360 user to be able to view information like resources and activities belonging to a particular site, the user must be connected to the corresponding object group in 360 Scheduling. The object groups for activities and resources are transferred automatically from IFS Applications to 360 Scheduling, but object groups for the 360 users must be set up and granted to the 360 users manually from the 360 iSWB.
The following IFS Applications components must be installed in order to use the 360 integration:
Furthermore, the following solutions cannot be used together with the 360 integration at the same time by 360 scheduled sites:
In order for employees to be available in the Scheduling Engine, the following data must be defined:
Note that the employee's allocations, such as, absences, training allocations, project allocations, breaks and lunches will be transferred for scheduling to the Scheduling Engine.
The resource types which are used within a company must be defined. Each resource type can be set up with information on the start and end locations for a work shift, maximum travel hours and costs such as scheduling cost per hour and scheduling cost per overtime hour.
If an employee is to be scheduled by the Scheduling Engine, this employee must be set up as a scheduling resource and valid scheduling data must be entered for this resource. If scheduling data is not defined for a resource it will inherit the data from the connected resource type, for example, the start and end locations of a resource type's work shift and scheduling costs will be assigned to the resource. For the start and end locations the geo-coordinates of the map positions will also be transferred to the Scheduling Engine. The scheduling data for a resource can be changed at any time, but updates will only be transferred to the Scheduling Engine when the next main data load is sent, rather than by incremental updates.
Scheduling activity types should be defined. The following scheduling information can be defined per activity type:
Weight criteria and weighting values should be defined. Weight criteria can be set up for the priority of the work order and the criticality of the equipment object that is connected to the work order. Weight criteria can also be set up for service contract types and will have an effect on the work orders that are connected to service contracts. For each weight criteria you need to define the weighting values that will be used as an input for activity base value calculations.
Appointment values need to be defined and will be used to calculate the base value for activities that are managed as appointments. The base value for an appointment activity, e.g., work order, is calculated by multiplying the base value for the appointment by the activity duration and weightings.
Scheduling types should be set up with values, such as, the start and end proportions and curve shape, that will be used as an input when calculating SLAs (service level agreements in the Scheduling Engine. The SLA is used to calculate the urgency of an activity. Scheduling types are used when scheduling breaks and activities. Scheduling types when combined with the base value is used to determine the scheduling behavior of a break or an activity.
Datasets are used to transfer data to the Scheduling Engine. A dataset contains information on how data should be scheduled and the time horizon for the scheduling. There are two types of scheduling that can be carried out, that is, scheduling data dynamically or as static scheduling. Static scheduling is generally used for long term rough scheduling (e.g., the resource capacity for a year) where data over several weeks can be loaded into the DSE (Dynamic Scheduling Engine) and scheduled for analysis. This type of scheduling is beneficial, for instance, when you need to identify resource shortfalls and over capacity. Dynamic scheduling is used for the short term detail scheduling (anything from 2 to 5 days) and focuses on optimizing the utilization of resources. This type of scheduling provides the best schedule at all times and is continuously scheduled by the DSE to incorporate any event changes in the field of operation.
The time horizon for which the data should be transferred and scheduled is given in days. For instance, if the number of days is set to 5, the data that should be scheduled per company or site for the given time interval (5 days) will be transferred to and scheduled by the Scheduling Engine. Following is a list of the data transferred in an active dataset:
Default values for a work order can be entered on the dataset. If a work order is missing any of the required data, such as, the primary scheduling type or the activity type, the default values from the dataset will be assigned to the work order. It is possible to set the lowest status from which work orders in the dataset can be transferred for scheduling. The default values for HR activities should also be entered per dataset and will be used as an input when scheduling the relevant activities in the Scheduling Engine.
Broadcasts are used to tell the Scheduling Engine how and when a plan is to be returned to IFS Applications, and to manage the interface between the scheduling engines and IFS Applications. Broadcasts can be set up per allocation type. The allocation type indicates which type of data should be output based on its association with the DSE, SDS or iSWB (Internet Scheduling Work Bench). The connection between the broadcast and allocation type is made on the applicable dataset. The type of output generated based on the selected allocation type is further described in the Scheduling Work Order with 360 Scheduling section. The same broadcast can be used for both DSE and SDS broadcasts, whereas a separate broadcast is required for an iSWB broadcast.
For DSE broadcasts, how the plan is to be returned is determined by the broadcast type that is selected. If the broadcast is set up with the File broadcast type, the plan is returned and stored using FTP (File Transfer Protocol) services. If the Webservice broadcast type is selected, the plans will be returned using HTTP (Hyper Text Transfer Protocol) services. The parameters for each broadcast type must be entered when defining the broadcast.
Scheduled tasks are used to transfer datasets to 360 Scheduling. It is recommended to have two scheduled tasks set up per dataset, one to transfer all data and another to transfer changes. For more information on how to set up the scheduled tasks, refer to the activity Set up a Scheduled Task for Transferring Data to 360 Scheduling.
The following object properties are automatically loaded in to the application when the integration is installed. The parameter values can be changed according to your requirements.
For more information on the object properties related to 360 Scheduling please refer to List of Object Properties - Maintenance.
In order to schedule a work order, the work order must be set to the transfer status or a higher status (where the transfer status is set per dataset in Scheduling Dataset/WO Defaults). Before setting the work order to this status however you need to make sure that all information required by the Scheduling Engine is present in the work order.
Once the work orders transferred to the Scheduling Engine are scheduled, an allocation plan with the current scheduling status, resource assignment and activity start and finish dates is returned to IFS Applications. Depending on the allocation type associated with the dataset, the following will occur:
| Allocation Type | Description |
| DSE | If the work order is allocated by the DSE, the DSE will produce a plan. You can choose to assign or unassign directly on the work order. If the suggested plan does not meet the requirements, you can choose to wait for the next broadcast of the plan or manually schedule the plan in the 360 iSWB. It is also possible to manually assign or unassign a work order in the 360 iSWB. |
| SDS | If the work order is processed by the SDS, the SDS will propose to automatically assign (or unassign) work orders already allocated by the DSE based on the given rules. The work orders that are returned are automatically promoted to the Assigned status and the Executed By field on the work order is set to the suggested employee's ID or demoted to the Released status and the Executed By field is cleared (depending on the SDS decision). The rules for the SDS are set up in an XML file and referenced in broadcast parameters. |
| iSWB | If the work order is manually updated in the 360 iSWB, IFS Applications will be synchronized with the changes made to the data in the 360 iSWB, which is the web based user interface for 360 Scheduling. In the iSWB client, a work order can be assign/unassigned, allocated to an employee, fixed to an employee and the start date can be fixed. This is only used to manage exceptions, the DSE and SDS normally deal with allocation and assignments automatically. |
The work orders will be scheduled based on resource skills, cost of scheduling the resource, the preferred resource for the work, the location of the resource and activity, the importance (value) of the activity and the urgency (SLA) on the activity.
The work order can be planned in the Scheduling Engine until it is set to the Committed scheduling status or transferred to a mobile device, after which it will be removed from the Scheduling Engine and therefore can no longer be scheduled. Work orders which are in the Assigned status or a higher status without a value entered in the Executed By field will not be scheduled by the Scheduling Engine.
If the suggested plan is suitable, assign the work order to the employee allocated by the Scheduling Engine.
If the suggested plan does not meet the requirements, wait for the next broadcast of the plan or manually change the plan in the 360 iSWB. When the employee is assigned to the work order, the status of the work order is automatically set to Assigned. This includes work orders which are processed by the SDS.
If the Work Order Status option is used to directly set a work order to the Assigned status, the work order is considered manually scheduled and will not be scheduled by the Scheduling Engine. Furthermore, if an employee is not entered on the work order or if the employee specified is not set up as a scheduling resource, the work order will not be transferred to the Scheduling Engine.
If the employee who is assigned to the work order cannot carry out the activity, you can unassign the employee from the work order. When unassigned, the work order will be resent to the Scheduling Engine to be rescheduled, and a new employee may be suggested in the allocation plan that is returned to IFS Applications. If an employee is unavailable for work, this should be notified via the HR system/Time Management so that the Scheduling engine receives their absences automatically and will adjust the schedules accordingly.