© British Telecommunications plc 2001 The Reactive, Real-Time Management of Mobile Workforces Jon E. Spragg Scheduling Software Designer and Research Coordinator

© British Telecommunications plc 2001 Scheduling Mobile Workforces  a.p.solve -- A Short History è Involved in mobile workforce management since è Produced two major Work Management Systems which have evolved into the TASKFORCE products we currently market. è a.p.solve (100+ employees) is being ‘spun out’ via the British Telecom’s Brightstar business incubator initiative next year. è a.p.solve’s planning and scheduling products primarily support the management of mobile workers via Personal Digital Assistants and mobile telephony.

© British Telecommunications plc 2001 Workforce Management at BT  a.p.solve’s TASKFORCE products currently schedule BT’s workforce of Service Technicians.  25,000 field technicians perform 150,000 tasks every day across the United Kingdom.  A high quality service at low operational cost needs to be delivered.

© British Telecommunications plc 2001 Issues  Complexity of problem  Scale  The need for a totally automated, online, system.

© British Telecommunications plc 2001 Complexity  Ever changing workload with a 1 hour response time.  Complex mixture of tasks with different execution target times and priorities.  Wide range in the duration of tasks: 8 mins - several days.  Work duration is uncertain, subject to environmental disturbances and delays.  Work type and work skill imbalances (some geographical areas are seriously under resourced in certain skills).  Task inter-dependencies can be complex (coops, assists, pre- installation tasks)  Travel times between tasks are subject to change.

© British Telecommunications plc 2001 Scale  20,000+ technicians, mostly mobile  Several hundred thousand tasks to be scheduled and dispatched every day.  Distinct workforces and scheduling environments.

© British Telecommunications plc 2001 Automation  Automated data flow from order source systems to job dispatch.  Schedule revision must be automatic and robust.  On line Dispatcher must handle corrupted schedules.  The real-line monitoring of the location of mobile technicians and their expected completion times is important.

© British Telecommunications plc 2001 Impact of Personal Digital Assistants on Scheduling Practice.  Mobile phones, notebooks, laptops, the Internet,...has allowed a.p.solve to deliver scheduling solutions to mobile workers, and it has also forced us to rethink how we do scheduling. We are deeply interested in the latest technologies being explored by the scheduling community:  Dynamic scheduling  Real-time scheduling  On-line scheduling  Adaptive scheduling  Self-scheduling systems,  Reactive scheduling systems

© British Telecommunications plc 2001 The Limitations of Traditional Scheduling Theory and Practice  Assumed ‘static’ environments: è Obsession with optimisation under idealised assumptions of environmental stability.  Limited support for tool sets to maintain the feasibility and quality of a schedule over time.

© British Telecommunications plc 2001 Theme: the case for reactive scheduling  On-line Scheduling is Reactive Scheduling -- for the most part.  First call for papers for AIPS 2002 Workshop on ‘On-line Planning and Scheduling’ didn’t mention reactive scheduling in the topics of interest!!

© British Telecommunications plc 2001 When I first realised this -- a personal account.  Scheduling Progressive Bundle Lines in clothing manufacture è Flow Line Manufacture è Line Balance Algorithms

© British Telecommunications plc 2001 Flow line theory Work Station 4 Work Station 1 Work Station 2 Work Station 3 WIP M3 Op3 WIP M4 Op4 WIP M2 Op2 M5 Op5 M1 WIP Op1 SMV Sum (Perf op ) * 100 = pt

© British Telecommunications plc 2001 Algorithms for Solving Line Balancing  View it as a static optimisation problem: è Operations Research è Branch and Bound è Local Search  Genetic algorithms  Tabu search

© British Telecommunications plc 2001 Flow line reality

© British Telecommunications plc 2001 In the Real World!  Optimised balanced lines soon get out of balance!! è Machines breakdown è Operators begin working below average performance. è Managers decide that jobs that were high priority are no longer high priority and jobs that were low priority are now high priority, and … è New jobs need to be introduced onto an existing line with other jobs. è Operators go absent. è Quality controllers decide re-work is necessary.

© British Telecommunications plc 2001 … and there is little you can do about it!  Build robust schedules è Knowledge of the scheduling environment? è Probabilistic models? è Machine learning algorithms?  In a stochastic environment, such as human resource scheduling è Reactive scheduling

© British Telecommunications plc 2001 On-line, Reactive Scheduling  Maintain a schedule over time è Incremental è Reactive  Mixed initiative approach (DITOPS/OZONE model) è Automated Monitoring è Automated Analysis è Automated Revision è Automated Optimisation è Automated Execution

© British Telecommunications plc 2001 Automated On-line, Reactive Scheduling Agents Perform:  Identify processing bottlenecks  Exploit scheduling opportunities  Maintain schedule stability and existing process plans.  Refine solutions.  Repair constraint violations.  Summarise solution states for human controllers and software agents.  Dispatch scheduling tasks to field technicians with respect to current schedule state and customer demand.

© British Telecommunications plc 2001 Execution cycle Monitor Analysis Revision Optimise Execute

© British Telecommunications plc 2001 Automatic Monitoring  Via dedicated HHT and laptop è Cancelled jobs è New jobs è Delayed operations è Resource absenteeism è Re-visits è...

© British Telecommunications plc 2001 What can go wrong?  Inconsistency (constraint graph analysis) è Resource capacity è Temporal consistency  Quality (cost model) è Unacceptable cost of late jobs è Unacceptable cost of adding additional capacity (I.e. pulling in a technician from outside the area).

© British Telecommunications plc 2001 Automatic Analysis  Perturbation metrics (texture measurement) è Optimisation in a dynamic environment  Similar schedule metrics (identify neighbourhood and extend of a perturbation) è Support revision/repair algorithms è Support user’s ‘visualisation’ of schedule solutions.

© British Telecommunications plc 2001 Schedule revision metrics  Metrics that support schedule revision tools: è Contention/reliance measures (estimate aggregate demand for a resource) Demand Time

© British Telecommunications plc 2001 Automatic Conflict analysis è Conflict analysis  Conflict duration  Conflict size  Resource idle time  Local downstream slack  Protected lateness  Variance in lateness

© British Telecommunications plc 2001 Automatic Schedule Revision  Reallocation algorithm to support appointment reservations. è A customer requests a technician to attend his premises between 9am and 12am. è The system can’t find an available resource between these hours but can identify a sequence of reallocations to free a technician to attend the customer.

© British Telecommunications plc 2001 Automatic Optimisation  The time between the construction of a feasible schedule and its execution is used to improve the quality of the schedule è Stochastic search  Simulated Annealing.  We are currently researching techniques for exploring large neighbourhoods based on an ejection chain model.

© British Telecommunications plc 2001 Automatic Dispatcher  Rule based execution sub-system. è If Field Technician request work then the Dispatcher identifies a task for the technician to service. è This invariably results in the need to repair a damaged schedule  Schedule analysis will produce state summary reports that support schedule repair after an unscheduled activity execution. è Focal point è Neighbourhood of impact è Conflict duration è Conflict size

© British Telecommunications plc 2001 System Overview

Intelligent End-to-End Fieldforce Automation