Work activity coordination software (WACS) are used in different ways in the field of manufacturing, business processes, software production, and scientific domains.
In the manufacturing domain WACS are used mainly as schedulers, and sometimes as planners. In manufacturing it is usually the case that the resources needed to perform the activities are scarce: the use of machines, workers, materials, and so on, must be carefully scheduled in order to optimize some performance goals. In these domains, one assumes that WACS can control when an actor (people and machines) will start an activity, and usually when it will end it. And coordination is mainly across workcases: one must decide which activities of which workcases should be executed next, in order to complete production in least time, or with the least cost, or with the least violations on contractual deadlines, and so on.
A less common application of WACS in manufacturing domain is as a planner. The WACS knows each activity that can be performed, their preconditions and postconditions, and thus given a new situation, and the goals to be achieved, the WACS can compute a plan to achieve the goals for that workcase.
In the workflow literature, in business domain, it is usually assumed that the work will not be performed in a resource poor situation. That is, one usually assumes that there will be enough actors, or they will have enough time to complete all activities attributed to them. Furthermore, in workflow domain, one usually does not have control over which activity the actors will execute. The standard workflow model is to assign an activity to a actor (office worker); the activity is then placed in the the actor's work list, who is free to choose which activities in his work list he will execute next. In this case, we will say that the WACS is performing a dispatcher function: for each workcase it figure out which activity must be done next, and who will perform it, and dispatches the activity to the chosen actor. The coordination is mainly intra-workcase, for example waiting for two activities to finish before activating another one.
In the software development domain, the usual assumption is that the resources are not enough to perform all activities for all workcases. Again, in this domain, the problem is deciding which activity of which workcase will be performed next, mainly as inter-workcase coordination. But different than the manufacturing domain, one usually does not have information enough to perform an automatic scheduling of activities in order to optimize some performance function. The WACS is used as a help on the scheduling decision, it may just list all activities that are enabled and must be performed some time in the future, or it may be a analytic tool that will compute the consequences of a particular scheduling decision, figuring out the delay in delivering some products, and so on. In these case the WACS work as a helper listing all activities (across all workcases) that are enabled and must be scheduled. Or it may also work as a simulator, computing the consequences of a particular schedule decision.
The use of WACS is less common in scientific domains. When WACS are used, it is common that the process models are just policies, or rules that must be checked during or after the process is thought to be complete. For example one of such rules may state that all statistical correlation activity must be followed by a significance test activity. The WACS is used as a reminded to the scientist that unfinished activities still need to be performed, or to verify that all planned activities were indeed performed. In this case, the WACS is used as a helper (reminder) or as a verifier.
Another possible use of a WACS, in all domains above, is as a replanner. For example, let us suppose that it was decided that some nonstandard activity must be performed for this case, either because the process model is not very specific, or because it was realized that this workcase was exceptional in some respect. The WACS as a replanner may help the users to plan a set of preparing activities, and cleanup activities before and after the planned non-standard activity, so that the resulting case does not violate the policies, and rules. As a simple example, let us suppose that an organization has the policy that meetings with a customer must be preceded by a call for that meeting at least 3 days before, and the policy that out-of-state trips must be informed 4 days in advance. If a software development team realizes that they need a meeting with an out of state customer, to refine some specification, the WACS may inform them that they can only schedule the meeting for 4 days in the future, and that they must inform their superiors about the trip immediately and before tomorrow they must have the call for the meeting ready.
In the next section we will describe a logic representation of process models, using a temporal logic. With the logical representation a more flexible understanding of what it means for a case to follow a process model, and by defining a stronger logic, and using the same process model formulas, it is possible to model some of the modes of use of WACS described above.