Business Independent Model of Mobile Workforce Management Volker Gruhn and Thomas Richter Chair of Applied Telematics / e-business, University of Leipzig Klostergasse 3, 04109 Leipzig, Germany {gruhn,richter}@ebus.informatik.uni-leipzig.de Abstract. In this work we introduce a general model for the description of mobile workforce environments. In the context of Business Process reengineering projects such models are necessary to predict the outcome of the optimization efforts. The model we propose is designed to be domain independent and can thus be utilized in BPR projects for any business domain incorporating mobile workforce systems. 1 Introduction Mobile business processes in workforce environments can be seen as processes, of which at least one activity takes place outside the organization s physical bounds [1, 2] and mobile workers are scheduled to perform such activities. If we consider mobile processes in network based industries (e.g. utilities, telecommunications) we can state that indeed selected mobile processes can be seen as a combination of mobile activities, taking place at different locations. These processes consist of more than one mobile activity. The following section introduces such a business process originating in the utility industry. Additionally time restrictions apply as e.g. down-times have to be minimized. In such mobile environments numerous business processes are executed in parallel by different workers / teams. Based on their respective qualifications and locations workers may perform not all but just a few activities of a process, possibly even alternatingly for two or more processes. Additionally complexity increases by the possibility of emergencies (processes with high priorities) during operation which demand the immediate re-scheduling of closeby, adequately skilled workers. Many organizations and enterprises with the according types of business processes are currently initiating or performing BPR projects of their mobile environment to introduce business process support with mobile workforce management systems [1]. Such projects usually include both the introduction of information systems to support the current processes and the examination of the whole process landscape which can lead to substantial process redefinition. The prediction of the outcome of process redefinition projects is (i) hard to achieve since many soft factors influence the costs of mobile processes and (ii) usually Corresponding author
of paramount importance for the approval of such projects by the management. Among the soft factors mentioned above are e. g. weather and traffic conditions, workforce scheduling methods, and the structuring of teams just to mention a few. Many BPR projects are performed by external consulting firms, specialized on either certain IT-systems or certain business domains. To gain reliable calculations of the expected outcome of BPR projects such firms can apply simulation models of the mobile environment in question. Preliminary research on this topic is e. g. performed by Netjes et al. [3] who introduce a Colored Petri Net based [4] model for the analysis of resource utilization and perform several examinations regarding the skill balancing and resource allocation order in banking processes. For the development of such simulation models we have designed a domain independent model of mobile workforce environments which will be presented in this article. The authors have demonstrated a simulation model for mobile environments utilizing this domain model [5, 6]. This simulation system is feasible to be utilized independently from the business domain. The remainder of this article is organized as follows. In the following section 2 we introduce the domain independent model. Related work is discussed throughout this section where appropriate. In the concluding section 4 we discuss possible applications of the model and motivate further research. 2 Process Model of Mobile Workforce Management To develop a business independent domain specific model of mobility and the execution of mobile work it is necessary to understand (i) the differences and commonalities of mobile business processes and (ii) the entities usually involved in such processes. Example Process In the following we will illustrate the processes in question with an example from the utility industry. Figure 1a shows a typical situation after a new power substation was erected and needs to be connected to the existing power network. This is achieved by the insertion of a sleeve (tee branch) at location L3 into the power line between the stations at locations L1 and L2. For the necessary work security concerns demand that the power line between Station @L1 L3 new Station Station @L2 Off @L1 Off @L2 Work @L3 On @L1 On @L2 (a) (b) Fig. 1: Power line extension situation and according process
stations at L1 and L2 has to be turned off before and turned on again after the insertion. Fig. 1b shows the resulting process as a UML Activity Diagram. Since it is desirable to minimise the downtime of the line different workers should perform tasks at different locations to avoid downtimes of the line due to travel effort. For our example this means that different workers may turn the stations on and off while a third team works at the site to perform the sleeve insertion. As a result actually independent processes become interdependent due to the fact that one worker can be involved in several different processes. In this way delays that occur at a certain site may cause massive delays at completely different sites and processes. Additional types of processes for nonmobile workforce problems are discussed by Russell et al. who introduce a series of 43 Workflow resource patterns in [7]. Entities Several different types of entities are involved with mobile workforce management. For the purpose of this work we will give a brief overview of the most important ones. For a broader and deeper insight we refer the reader to [5], [1], and [8]. Mobile work is performed by workers who are assigned with a current geographic location, skills, and a schedule. A group of co-operating workers is called a team. A geographic location is a position on the surface of the Earth. The schedule of a worker is an ordered list of tasks the worker has to perform. The period covered by a schedule can be any span of time and is not restricted to a day. The schedules of ground based long distance transportation, for instance, usually cover a week [9]. A task is an atomic unit of work to be performed assigned with a geographic location and a set of skills it demands. Workers or teams must have the adequate skills to be scheduled to perform a task. A task can be assigned with an asset which is a piece of equipment located at a geographic position. A process is an ordered set of activities defining how a business goal of a certain type can be achieved. Processes can be considered as templates for the operation of enterprises. A case instantiates a process. It is assigned with the concrete data for one execution of the process. In the same way tasks can be considered as instances of activities. Tasks are the work units of cases. Abstract Model Figure 2 gives an overview of the typical administrative parts of any mobile process. Preparation of a mobile task includes the gathering and bundling of necessary information and material. It is carried out a the organization s headquarter. An example for the preparation of the inspection of a power network is the print-out of the list of all assets to be inspected. Assignment of a mobile task to a worker appoints the worker to execute this task. To assign a worker to a task, the task s required qualifications must be in the set of the worker s skills. As traveling contributes considerably to the costs of mobile processes it is necessary to manage work lists containing a worker s activities for a given period of time in chronological order. The assignment of the task to the worker is performed manually or automatically and is carried
out at the organization s headquarter. The transfer to the worker may occur face-to-face or via wireless data communication. Performance of a mobile task includes the transfer of the worker to the site of work, the actual work, and the gathering of work-related information by the worker on-site. It is mainly carried out at the task s location. Completion of a mobile task includes the analysis of the work results, the accounting, the updating of technical data, and the planning of further measures if necessary. It is typically executed at the headquarter. The steps considered in this work are the assignment and the performance of the mobile task which are the process steps that are influenced by the properties of mobility (see Fig. 2). Preparation Assignment Performance Completion optional Fig. 2: Abstract mobile process Assignment of Mobile Work The primary goal of the assignment of mobile work is the minimization of the total process costs of the organization. The resulting secondary goals of the work assignment are the execution of the cases with the highest priority, the reduction of travel effort, and the avoidance of workers idle times. The general assignment activities are depicted in Figure 3. The assignment can either be performed manually by a dispatcher or automatically by a workforce management system based on preset priorities, expected travel times, and interdependencies of the cases and tasks. At the beginning of a working day for every case its tasks are inserted into the schedules of adequate workers. The next case is selected and inserted into the still incomplete schedules until all schedules are complete. A schedule is considered complete if it contains activities work for a whole working day e. g. expected working and travel times sum up to eight or nine hours. Algorithms for the solving of the respective mobile workforce scheduling problem are presented and discussed in [6]. If mobility is omitted from the problem domain the resulting can be interpreted as resource-scheduling and resource distribution in business process management. The foundations of resource scheduling research date back to the 1950ies and are summarized in [10]. Ursu et al. [11] present a distributed solution for workforce allocation based on independent agents. The workforce allocation is achieved by negotiation between agents utilizing a specialized communication protocol. In-depth Petri net based modeling and analysis of work distribution mechanisms of the Workflow Management Systems Staffware, FileNet, and FLOWer is presented in [12]. Further research by Pesic and van der Aalst focuses on the development of a reference model for work distribution in Workflow Management Systems [13]. They focus on the general lifecycle of work items and introduce a CPN based approach for the distribution of work items to resources at runtime. Though most of the work depicted above had creative influence on our work none covers the properties of mobile process
environments. Resource allocation in mobile process environments has been in the focus of the following work. An automated resource management system (ARMS) for British Telecom is introduced in [14]. The system is intended for forecasting and analysis of resource demands and executes the dispatching of jobs to resources but does not handle precedence relations of chained tasks and process durations. Sort Cases Select Case Insert Tasks into Schedules [all schedules complete] [incomplete schedules] Fig. 3: Assignment of a mobile task Performance of Mobile Work Independently from the business objectives the performance of a mobile business process also follows a general scheme. For each task of a process the steps depicted in Figure 4 have to be executed. Traveling is the transfer of the worker responsible for the execution of a task to the location of that task. It can start at the operational base of this worker (for the first task of the day) or at the location of another task that has been accomplished by the worker before. In this work traveling towards a task s location is considered to belong to that task. Waiting may be necessary after the location of the task has been reached by the worker and either the time window of the task has not been reached yet or a preceding task of the case has not been finished yet. In the example of Fig. 1b Work@L3 must not start until Off@L1 and Off@L2 are finished. Execution of a task is the actual accomplishment of the business objective of this part of the process. The execution of tasks is considered as an economically weighted period of time which blocks a worker at a certain location with certain costs. Finalization of a task includes the gathering of data describing the work results. This includes business data as e. g. the nature and amount of material consumed and administrative data as consumed time. Further discussion of organizational aspects of resource management is e. g. accomplished in [15]. Travel to task s location Wait for end of preceding tasks Execute the task Finalize the task Fig.4: Execution of a mobile task 3 State Models of Entities Resulting from the characterization of abstract mobile processes as in Figure 2 and the assignment and performance of mobile tasks as in the Figures 3 and 4 state models for workers, tasks, and processes can be given.
Mobile Workers Figure 5 shows a UML state diagram of the states a worker can adopt. It corresponds to a typical working day of a mobile worker. When the worker starts the working day in the state Ready the schedule of a worker is already created and assigned. Considering a typical daily routine the worker enters the state Traveling as soon as he drives to the site of the first task of his schedule. After reaching the working site the worker enters the state Waiting if the task is preceded by another task of the respective case and this other task has not been finished yet. Note that a preceding task can only block another task if they are assigned to different workers. For the example process in Figure 1b the blocked task could for instance be Work @L2 while the blocking task could be Off @L1. If waiting is over or not necessary the worker starts to work on the Connected break return drive to task Ready Traveling [worklist empty] finish or [worklist not empty or n] arrive Not Ready [not blocked] [blocked] return break break return timeout Disconnected Working unblock Waiting return break Fig.5: State of a mobile worker with WFM-support task and enters the state Working. If the schedule of the worker is empty after finishing the execution of the task the worker returns to state Ready and then finishes his working day via the state Not Ready. Otherwise the worker starts to travel to the next task by entering the state Traveling again. If emergency situations occur in the service area workers may be n from their current tasks. In such a situation a new task is added to the top of the worker s schedule and the worker interrupts his current activity to travel to the location of the newly added task. This is depicted in Figure 5 by the edges from the states Traveling, Waiting, and Working, by the drive to task edge from the state Ready, and by the return edge from the state Not Ready. From every state the worker can enter the state Not Ready via the break edges. This state may indicate a lunch break, or a traffic accident, for instance. Note that the
nature of mobile work demands that a state change from the state Not Ready is only possible back to the preceding state of the worker. All states of Figure 5 discussed above are substates of the superstate Connected. The state Connected is necessary because the states are declared with no respect to the knowledge the headquarter of the organization might have about a worker s state. Since the mobile workers operate in the field with unpredictable data or phone connections the current state of a worker may be unknown to the headquarter at any time during operation. The model introduced in this work assumes that every state change of a worker is reported to the headquarter via data communication. As soon as a timeout occurs the headquarter s state of a worker changes to Disconnected while the worker still has local knowledge about his real state. During a disconnected period a worker can not be reached by the headquarter implicating that the worker can not be rescheduled to cases with higher importance than his current schedule. Whenever an update is received by the headquarter the state changes back to the appropriate one. Mobile Tasks In conjunction with the state model of mobile workers Figure 6 shows the UML state diagram of mobile tasks. As soon as a case is chosen assign Created Assigned Task Active drive arrive Engaged [blocked] unblock finish Blocked Execution to task n [not blocked] drive to task n timeout finished Unknown Finished timeout Fig.6: State of a task for execution its tasks are created alongside. With its creation a task enters the state Created. With the assignment to a worker it enters the state Assigned. From there the task can either be n and return to the state Created or the worker starts to travel and the task enters the state Task Active. The state Task Active aggregates the states Engaged, Blocked, and Execution. As soon as the worker drives to the site of the task the task s state implicitly changes to Engaged. After the worker arrives at the site the execution of the task can either be blocked by a preceding task or not. In the blocking case the task enters the state Blocked and the state Execution otherwise. This complies with the worker entering either Waiting or Working, triggered by the same events. As soon as the task becomes unblocked it enters the state Execution and the work is performed. After finishing the work the task changes to the state Finished.
During all of the states aggregated by Task Active the task can be n from the worker and in turn re-enter the state Created. This implies that the worker immediately stops to travel, wait, or work and starts the next task in his schedule. A al is not possible after the task was finished. Instead the whole case must be considered at a higher level of process control. This situation will be discussed later. As for the state of a worker also the state of a task may be uncertain to the headquarter controlling the mobile operations due to the loss of data or phone connections. In addition to the task s state model discussed above a state Unkown is introduced indicating that the headquarter can not determine the current state of that task due to a connection timeout. Whenever the task is either in state Assigned or Task Active and the data connection to the worker is lost the headquarter assumes the task to be in state Unknown. Whenever an update from that worker is received the headquarter s state model can be updated to the appropriate state. It is assumed that during a task being in the state Unknown this task might not be n from the worker to avoid unpredictable states of the whole case. Mobile Cases This leads to the state model for a case, depicted in Figure 7. As already stated above the tasks of a case are created alongside with the creation of the case itself. Since the state models of the two are quite similar the change of state of a task usually triggers a change of state of the appropriate case. With its creation a case enters the state Created. With the assignment of the first task to a worker the case changes to the state Partly Assigned and with the assignment of the last unassigned task it changes to the state Assigned. If the case has just one task the state changes directly from Created to Assigned. Whenever a task is n from a worker as long as no worker started to work on one of the tasks of the case, the states change according to the assignment of tasks. If the case is in state Partly Assigned and tasks are n or assigned the case remains in the state Partly Assigned see the looped edge of the state in Figure 7. After the assignment of the tasks the workers may start timeout Created Partly Assigned Assigned Unknown Case Active drive finish 1st task finish last task Engaged Partly Finished to task n assign 1st task only task last task assign only task only task assign task task drive to task assign last task task finished last task timeout Finished receive update or timeout drive to task task finish task Fig.7: State of a case
to drive to the locations of their respective current tasks. Since the processes considered here demand the completion of all activities all tasks must be assigned to workers. Thus the assignment of work takes place and is completed before the actual working day starts and thus no worker can start to drive before all schedules are complete. As soon as an arbitrary task of this case changes state to Engaged) the case changes state to Engaged accordingly. The case remains in the state Engaged until either the first task of the case is finished or all tasks of this case have been n. After the first task is finished the case changes state to Partly Finished. It is assumed that a case may or may not corresponding to the organization s policy be n after one of its tasks is finished. Thus the finishing of the first task of the case causes a change in the case s state. Note that Figure 7 depicts an organization where cases must be finished after their first task is finished. If the last engaged task has been n the state Case Active is left and the case re-enters the state Created demanding a completely new assignment turn. As soon as the last task has been finished, the case changes state to Finished. For the cases the same rules about the headquarter s knowledge of the case s state apply as for tasks and workers. Thus the stateunknown which is added. The meaning of the stateunknown is similar to the according state for tasks (see Figure 6). Whenever a case is in one of the states Assigned or Case Active and the connection to an arbitrary worker involved in this case times out the case changes state to Unknown. Additional timeouts and / or received updates keep the case remaining in the state Unknown until the states of all workers are known again i. e. updates were received. The state of the case is then determined with respect to the according update messages. 4 Conclusion The model introduced here was developed during a scientific consulting project performed for a German power and gas supply serving 500.000 customers and covering an area of 7000 km 2. The model covers both the static and dynamic properties of mobile workforce management systems and the uncertainty of data and phone connections. The model is independent from the business domain of dedicated organizations but represents the common attributes of centrally controlled mobile work in general. It further accounts not just for single mobile tasks but for processes that consist of an arbitrary number of mobile and nonmobile activities. Our model can be utilized for the requirements analysis of mobile workforce management systems, for the development of BPR simulations, or for the maintenance of a consistent nomenclature throughout any organization performing or dealing with the appropriate processes. Further development of our model will cover different types of costs occurring in the mobile context (e. g. travel, waiting, equipment dowtimes). We will develop the model further collaterally with our simulation system for mobile organizations [5].
Acknowledgment The Chair of Applied Telematics/e-Business at the University of Leipzig is endowed by Deutsche Telekom AG. References 1. Gruhn, V., Köhler, A., Klawes, R.: Modeling and analysis of mobile business processes. Jounal of Enterprise Information Management 20(6) (2007) 657 2. Luff, P., Heath, C.: Mobility in collaboration. In: Proceedings of the 1998 ACM Conference on Computer supported cooperative work, ACM Press, New York, USA (1998) 305 314 3. Netjes, M., van der Aalst, W.M.P., Reijers, H.A.: Analysis of resource-constrained processes with Colored Petri Nets. In: Sixth Workshop and Tutorial on Practical Use of Coloured Petri Nets and the CPN Tools. (2005) 4. Jensen, K.: Coloured Petri nets (2nd ed.): basic concepts, analysis methods and practical use volume 1. Springer-Verlag, London, UK (1996) 5. Gruhn, V., Richter, T.: A General Model of Mobile Environments: Simulation Support for Strategic Management Decisions. In: Proceedings of the 2nd International Workshop on Personalization in Grid and Service Computing (PGSC 08). (2008) 6. Goel, A., Gruhn, V., Richter, T.: Mobile Workforce Scheduling Problem with Multitask-Processes. In: Lecture Notes in Business Information Processing. Volume 43. Springer Verlag (2010) 7. Russell, N., van der Aalst, W.M.P., ter Hofstede, A.H.M., Edmond, D.: Workflow Resource Patterns. In Pastor, O., Falcao e Cunha, J., eds.: Proceedings of the 17th Conference on Advanced Information Systems Engineering (CAiSE 05). Volume 3520 of Lecture Notes in Computer Science. Springer-Verlag (2005) 216 232 8. Gruhn, V., Köhler, A.: A Modeling and Analysis Approach for Mobile Information Systems. In: The First International Workshop on Mobility, Collaborative Working, and Emerging Applications (MobCops 2006). (2006) 9. Goel, A.: Fleet Telematics: Real-time management and planning of commercial vehicle operations. Springer Verlag (2007) 10. Kolisch, R.: Serial and parallel resource-constrained project scheduling methods revisited: Theory and computation. European Journal of Operational Research 90(2) (1996) 320 333 11. Ursu, M.F.: Distributed resource allocation via local choices: A case study of workforce allocation. International Journal of Knowledge-Based and Intelligent Engineering Systems 9(4) (2005) 293 301 12. Pesic, M., van der Aalst, W.M.P.: Modelling work distribution mechanisms using Colored Petri Nets. International Journal on Software Tools for Technology Transfer (STTT) 9(3) (2007) 327 352 13. Pesic, M., van der Aalst, W.M.P.: Towards a Reference Model for Work Distribution in Workflow Management Systems. Business Process Reference Models 14. Voudouris, C., Owusu, G.K., Dorne, R.J.H., Ladde, C., Virginas, B.: ARMS: An automated resource management system for British Telecommunications plc. European Journal of Operational Research 171(3) (2006) 951 961 15. Zur Muehlen, M.: Organizational Management in Workflow Applications - Issues and Perspectives. Information Technology and Management 5(3) (2004) 271 291