PROCESS STATE INFERENCE FOR SUPPORT OF KNOWLEDGE INTENSIVE WORK
John Noll
Computer Engineering Department Santa Clara University
500, El Camino Real, Santa Clara, CA-95053, USA.
email: [email protected]
Jigar Shah
Computer Engineering Department Santa Clara University
500, El Camino Real, Santa Clara, CA-95053, USA.
email: [email protected]
ABSTRACT
Different actors may do the same work in different ways, depending on their preferences and level of expertise. The nature and amount of process support required also varies with the knowledge level of the actors: novice actors may require guidance at each and every stage of the process, while experts like to have a free hand and need guidance only when in doubt.
We describe a descriptive enactment approach, whereby guidance is provided only when asked, rather than actively prescribing a list of actions at every stage of the process. The enactment mechanism also infers the state of the process by examining the state of products created or modified during the execution of the process; therefore, the actor does not have to notify the system of every action he does while performing the process, but the system can still keep track of process progress so that appropriate guidance can be provided when needed.
KEY WORDS
Software Engineering Applications, Cooperative Work Support, Workflow Modeling
1 Introduction
Traditional workflow support approaches are based on pre- defined, formal descriptions of work processes. Also, these approaches are based on the paradigm that the system has to guide actors through each and every stage of the process execution. Hence, the success of these systems has been limited to domains which have routine and highly repeti- tive processes [7].
Knowledge intensive work is different from routine work in that actors may perform knowledge intensive tasks in different ways, depending on their intuition, preferences, and expertise. For example, novice actors who are perform- ing the work for the first time may not have any knowledge about how to do the work. More experienced actors who have done the work before have some insight about how things should be done. Finally, there are experts, who know the process thoroughly and can readily improvise new solu- tions to problems. Due to this difference in their respective knowledge levels, different actors may do the same work
in different ways. Consequently, the amount and nature of guidance required while doing the work is different. Thus, a system for supporting knowledge intensive work must be flexible, in order to provide support workers with varying expertise.
In this paper, we describe a process support system which is more explanatory in nature than enforcing. Rather than prescribing a list of actions to be performed at each and every stage of the process, we adopt a reactive ap- proach, whereby the actor is provided with guidance only when he explicitly asks for it. The process support sys- tem is ‘descriptive’, in the sense that the actor does not even need to inform the system about the activities he has performed while executing a process. Rather, the process enactment engine infers the state of the process by exam- ining the state of products created or modified during the performance of the process’s tasks. Then, if and when an actor requires guidance as to what tasks should (or may) be performed next, the system can use the inferred state to determine the next action to be taken, according to the underlying process model.
To enable this, we use a product centric modeling ap- proach. A process specification lists tasks along with a nominal sequence in which these tasks could be performed.
Each task also has a specification of the pre-conditions and post-conditions for its performance, expressed in terms of the state of artifacts used and produced when the task is performed. Using this specification, the current state of the process can be inferred by observing the current state of the products in the environment. Then, when the actor asks for advice, the process support system uses this inferred state and the process specification to provide guidance on what to do next. Since there is no enforcement of the nominal flow of tasks specified in the process model, deviations can be easily supported.
2 Product Based Modeling
A critical feature to the approach presented in this paper is the ability to view a knowledge-intensive processes as a series of actions that use or consume some artifact and produce some artifact on completion.
We model processes using the PML Process Model-
ing Language [3]. PML provides familiar programming language constructs such as selection, branch, iteration, and sequence to model the recommended order in which actions should be performed.
The PML feature central to the approach in this paper is the ability to view the process as a series of actions that use or consume some artifact and when they are done, pro- duce some artifact. To capture this information, the spec- ification of an action in the process model may be accom- panied with predicates that specify the resources (products, artifacts) the action produces uses.
The requires predicate specifies the state of the re- sources which are required for the action to be done. As an example, consider,
requires { document }
The provides predicate, on the other hand, specifies the state of a product produced or modified as a side-effect of performing the action:
provides { document.spell_checked == "true" } Thus, a PML process model specifies the evolution of the products created during the execution of that process.
Hence, while enacting a process, at any given stage, by ob- serving the state of products, we can easily infer the state of process.
As an example, Figure 1 shows a PML model describ- ing a process a student might follow to submit homework via email or hardcopy.
To understand how PML enables flexible process sup- port, we will consider how two actors – one novice, one experienced – might perform this process. This process has several steps: first, create a PDF file from the home- work document; then, either submit the PDF file as a hard copy in person, or send it as an email attachment. Email submissions will be acknowledged by a message from the professor.
Consider a student who has never submitted home- work via email. This student might interact with a process guidance system at each and every stage of the process, as depicted in Figure 2, and depend on the system completely to guide him through the process. This novice actor informs the system of each and every action he performs while exe- cuting the process. The system is able to respond immedi- ately by suggesting the next course of action, by following the process control flow from the last action completed.
In contrast, a student that has submitted homework this way before is familiar with the process and may need little guidance. Consider Figure 3, which shows an ex- pert student interacting with a process support system while submitting his homework.
Since this student knows the process, he knows how to start, and hence does not need (or want) to interact with the system for guidance. He starts the job straightaway and creates a PDF file of his homework document. However, if, after creating the PDF file, he is not sure of how to proceed,
process SubmitHomework { action create_pdf_file {
requires { document } provides { pdf_file } script {
"Create a PDF formatted version of your document. }
}
selection {
action submit_hardcopy { requires { pdf_file } script {
"Print a copy of your document and turn it in at the beginning of class." }
}
sequence {
action submit_email { requires { pdf_file }
provides { ack_message } script {
"Create an email message with subject identifying the course and assignment to which this document applies. Attach the pdf_file to this message." }
}
action verify_ack { requires { ack_message } script {
"Examine the ack_message to be sure that the professor has received your homework file." }
} } } }
Figure 1. PML Model Process for Submitting Homework
5. Detect pdf file Now what?
4. I created a pdf file.
document.
Tell me what to do?
1. I want to Submit Homework novice
pdf file Environment 3. Create pdf file
2. Create a pdf file of your homework Process Support System
(a)
6. Decide whether to submit hard copy or submit by e mail
7. Submit hard copy
8. Submit the pdf file to your professor
Environment pdf file novice
Process Support System
(b)
pdf file
10. You are done ! Now what?
9. I submitted the pdf file
System
Environment
Process Support novice
(c)
Figure 2. Novice Interacting with a Process Support System
Process Support System
Environment pdf file 1. Create pdf file
3. Detect pdf file 2. What next?
4. Decide whether to submit hard copy or submit by e mail.
expert
Figure 3. Expert Interacting with a Process Support System
he could consult the system to ask for advice on what to do next. At this point, the system can detect that he has already created a PDF file; using this information, it can respond with the suggestion that he may perform any action that requires the PDF file, such as submit the homework by email or submit a hard copy.
The key observation from this scenario is that an ex- pert actor does not want advice at each and every stage of the process, but he may want advice when he is not sure of what to do next. The novice actor, on the other hand, requires assistance with each step.
3 Enactment Mechanism
A process model specifies the evolution of products during the performance of that process. Since the actor is not re- quired to inform the system about his activities, the enact- ment mechanism has to keep track of the process by mon- itoring the evolution of products specified in the process model. Since the process model also specifies a order in which the actions could be performed, the enactment en- gine should can use the process model to provide guidance to the actor, if asked to do so. Figure 4 shows the ar- chitecture of the enactment mechanism. In the following sections, we describe the components of this architecture.
