Artificial Intelligence for Crowd In a Nutshell This page provides help and instructions on how to troubleshoot and configure the Autoscheduler / Artificial Intelligence (AI) part of the Crowd. Assuming the previous steps were completed successfully, it should now be possible to see the crowd widget on Planning and Dispatching app. How to enable the AI To enable AI settings and the necessary CROWD role in the account, the setting CoreSystems.CoresystemsFSM.Crowd.enabled must be set to true. This operation can be done in the Admin module AI settings In the Planning and Dispatching application (currently only in PREVIEW accounts), the Autoscheduler can be configured in the Settings -> AI settings option: As an alternative, the following link can be used: https://apps.coresystems.net/workforce-management/#/ai-settings (it may require changing the fragment ‘apps.’ to the cluster of your account) Configurable Constraints The Autoscheduler constraints are configurable from the Planning and Dispatching interface. The constraints have two types: HARD The constraint is necessary for a solution. A solutions is found if and only if it does not break the constraint. SOFT The autoscheduler will do a best effort to minimize the constraint, but solutions can be found, even if they break the constraint. The order of constraints is important. Constraints on top of the list will have more weight. Constraint Type Description Default TOTAL_WORK_TIME SOFT Total work time should be minimized. This is a direct function of the driving time, since the activities duration is fixed ENABLED OPTIONAL_SKILLS SOFT Optional skills should match, if possible DISABLED WORK_FRAGMENTATION SOFT The work should be as less fragmented as possible. For example, when there are 3 jobs and 3 resources, one resource should do all the jobs, whenever possible DISABLED MANDATORY_SKILL_WASTE SOFT Mandatory skill waste should be minimized. For example, if a job requires one skill, it should not be assigned to a resource with ten skills. More skilled resources should be spared for jobs which require more skills DISABLED LUNCH_BREAK HARD Mandatory lunch break. It accepts the start, end and duration, as parameters. For example, a 30 minute break from work has to be taken from 11 to 14:30 (in compliance with Swiss law) DISABLED MAX_DRIVING_TIME_MINUTES HARD Maximum time of driving allowed, for any technician travel. Includes driving to/from home. ENABLED, value = 12 hours Other Constraints The following constraints are built-in: Constraint Type Data trigger Description Blacklisted resources HARD The Job (CrowdAssignment DTO) has a non-empty array in the field “rejectedBy” For example, resource id = “R123” cannot be assigned to the job with rejectedBy = (“R123”, ““R456”). In the context of the Crowd, this happens after a technician rejects an activity, to prevent that she is offered the same activity again Maximum travel HARD The Resource (Person DTO) has a non-zero value in the field “maxDistanceRadiusMeters” Self-descriptive constraint. For example, a resource with maxDistanceRadiusMeters = 50000 and Home location in (47.502, 7.619) cannot do a job in (47.375, 8.534 ), which is more than 50 KMs away. The distance is measured in Euclidean Distance, a straight line from Point A to B as if the ‘Crowd flies’. If either the home location or the distance radius is null, the constraint will not be taken into consideration Reachability by driving HARD Both the job and the resource have coordinates (mandatory) For example, the resource at (52.1, 13.2) cannot drive to (47.1, 9.5) in less than 2 hours. The maximum driving time allowed between activities is 12 hours Mandatory Skills HARD The job has at least one mandatory requirement For example, resource with skills = (“AmazonFire”, “iOS”) cannot do the job with mandatory requirements = (“AmazonFire” ,”Linux”), but resource with skills = (“AmazonFire”, “iOS”, “Linux”) can do it Earliest plan SOFT With all the conditions being the same, the Autoscheduler will try to plan the activity as early as possible. Address of Technicians and Activities The address of the technician is taken from the Person of type ‘EMPLOYEE’, which is synchronized with the UnifiedPerson. The address taken is of type HOME. If this address is not present, the WORK address is taken. When no address of type HOME or WORK is present, the technician is not taken into consideration for autoscheduling. The activity address is taken from the Equipment, Business Partner or Service Call (in this order). Both addresses should be geocoded. When the address originates from the ERP it may take some time to geocode it in the cloud. Sometimes up to hours. Activity Duration In the WFM, the service call and activity do not have a field for storing the duration explicitely. The duration is the calculated difference between end and start time. In the example on the right there is an activity with a duration of one hour. The duration will never change, even after several planning and re-planing events. Real-time Location of Technician When real-time mode is enabled, the location of the technician is taken into consideration for the current moment. The driving time will be computed based on the current location of the technician. Prior to the use of this feature, the mobile auto-location must be activated. Settings There are two settings which influence the behaviour of real time location of technician. Enable Real-time Causes autoscheduler to use the real-time. Otherwise, the home or work location will be used. Real-time Update Threshold Determines how old the last location update can be in order to be taken into account for scheduling. If the threshold is configured to five minutes, a location update from ten minutes ago would not be taken into account, but the home address and the address of the technician’s currently assigned job will be used for scheduling calculations. Timeliness is calculated as follows: last update is after or equal to current moment of scheduling minus threshold in minutes. in the example above, the real-time is enabled and the latest location update will only be considered if it was less than one hour ago Driving time The driving time is computed using the road network–when in road netork mode– and considers the speed in of the particular road. The following profile is used: Road Speed KpH Speed MpH Motorway 90 56 Secondary 55 34 Tertiary 45 28 Residential 25 16 The driving times are assigned to jobs as follows: On first job of day, it is assumed technician drives from home (or work address, if home not available) From every subsequent job, the driving distance to the job (from previous job) is assigned to the job itself. These jobs will have null value in the drive from field The last job of the day will have the time to drive home (or work address, if home not available) If the road network mode is not enabled in the settings, a speed of 30 Km/h in straight line will be considered. All the times are in minutes. Autoscheduling Widget The Autoscheduling Widget will display on the right-hand side of the Dispatching Board application. Scheduling follows an asynchronous workflow, in which jobs are added to the queue for later dispatching. Jobs can be added by dragging and dropping them onto the Autoscheduling Widget, or through selecting them from the Activity List and clicking the Add to Queue option. Alternatively, a business rule can be created to automatically add activities to the queue (see FAQ below). Activities present in the queue will be scheduled when one of the following conditions is met: The countdown timer reaches zero The activities added into the queue for dispaching reaches the queue threshold The Schedule Now button is pressed Settings In the AI settings interface, the queue size threshold and timeout can be set in the AI settings screen. Some considerations: the larger the queue size, the better the optimization will likelly be to plan any activity immediately, the queue size may be set to 1. However, this may impact the quality of optimization Planning large amount of activities Although there is no limit in the quantity of activities in the queue, activities will be processed in batches of 100. The order of processing is based on the following criteria: Priority: activities with higer priority are processed first Due date: for activities with the priority, the ones with an earlier due date have precedence Troubleshooting and FAQ Q: Can we plan for internal technicians only? A: Yes, can be done in one of the following ways: Remove all the technicians from the service provider. This can be achieved by setting “plannable resource” to false in the Person. Create a skill that only the internal technicians have, and require it in the activity Q: Crowd is not finding technicians, but I know there is a technician living nearby with all the skills. A: A possible and common reason is the lack of address or it not being correctly saved due to the Person and UnifiedPerson syncronization bug. Do the following: Go to person (or Equipment/Business partner of activity) Remove the address Create again, make sure the coordinates appear Q: Is it possible to have all new activities go directly to the queue? A: Yes, please create the following Business Rule: Note: this business rule does not update search, which impairs the visibility of the process. The activity will not appear in the crowd queue widget. But it will be crowded nevertheless. Q: When I autoschedule activities, the result overlaps, like in the picture. A: Autoscheduling works with 1-minute granularity. However, the Planning and Dispatching application interface is, by default, configured to a 15-minute snap granularity to the planning board grid. To avoid overlaps, inside the WFM, navigate to ‘General settings’ -> ‘Activity settings’ and change the value of ‘Rounding minutes’ to 1. Q: Activity cannot be added to the queue. Drag and drop does not work, nor does selection from planning list. Why is this behaviuor happening? A: The autoscheduling only works with activities, not with service calls. Activity needs to be created beforehand.