When workflows will not deliver – The case of contradicting work practice Shazia Sadiq, Maria Orlowska School of Information Technology and Electrical Engineering The University of Queensland Brisbane, Australia
[email protected];
[email protected] Wasim Sadiq, Karsten Schulz SAP Research Centre Brisbane, Australia
[email protected];
[email protected] Abstract A new class of problems has been identified for workflow management wherein this technology imposes an additional overhead on users which is not adequately compensated by the benefits gained. Multiple observations from real cases identify a contradiction between the preferred work practice and some fundamental principles behind workflow systems. The focus of this paper is primarily to motivate the problem, however, we will also provide deliberations on the impact of these advanced process requirements on existing technology solutions.
1. Introduction The role of IT in providing businesses a competitive edge has recently been the subject of much debate [Carr, 2003]. However, it has been argued that not the technology solutions but their utilization is what provides the competitive advantage [Smith and Finger, 2003]. Technologies supporting business process management (BPM) stand at the forefront of this vision as they provide businesses the ability to effectively utilize, control and monitor their resources. The need for process enforcement technologies is well established. Starting initially from document routing and office automation systems [Ellis and Nutt, 1980], [Mahling, 1995], they evolved into a mature technology as provided by workflow systems. Workflows Management Systems (WFMS) delivered effectively in the area of process enforcement, offering a clear separation of business process logic from component applications involved in process execution, thereby responding to the well-established need for application integration.
Witold Abramowicz (ed.), Business Information Systems, Proceedings of BIS 2005, Poznan, Poland
4
BUSINESS INFORMATION SYSTEMS – BIS 2005
In Figure 1, we show building blocks of process-enabled enterprise systems. Just as the DBMS provided a means of abstracting application logic from data logic, the WFMS provided a means of abstracting coordinative process logic from application logic. Clearly, every generation has provided additional functionality through supporting systems. Although, workflow technology has delivered a great deal of productivity improvements, it has been mainly for predefined static and repetitive business processes, that required basic level of coordination between human performers and some application components. More recently business process management (BPM) has been used as a broader term to reflect the fact that a business process may or may not involve human participants and may also cross organizational boundaries. There is currently a wide spread interest in academia and industry on business process management technologies, especially in light of emerging paradigms surrounding web services and their application in dynamic business process composition. There are a number of standards and initiatives in this regard generally focused on the problem of B2B process integration (see e.g. [BPEL4WS], [ebXML], [RosettaNet]). WFMS Process Logic Process Logic Process Logic Application Logic Data
Figure 1.
Application Logic DBMS Data
Application Logic DBMS Data
Process-Enabled Enterprise Systems
Typically the principles behind process-enabled systems include: • A clear separation of Process, Application, and Data aspects of enterprise systems with minimal overlap. • Status, instance, and context management are an intrinsic part of overall process management architecture. • Process Modeling is an integral and essential part of systems development and deployment lifecycle. • Business processes are primarily captured through modeling and business logic is primarily implemented through coding of application components. • Application components have minimal direct awareness of one another and also have minimal direct awareness of “where and how” they are being utilized in BPM layer. Witold Abramowicz (ed.), Business Information Systems, Proceedings of BIS 2005, Poznan, Poland
WHEN WORKFLOWS WILL NOT DELIVER – THE CASE OF CONTRADICTING WORK PRACTICE
5
•
BPM takes the primary responsibility to achieve business objectives through configuration, coordination, collaboration, and integration of application components. • Similar BPM principles are applied in achieving intra-application, application to application, system to system, as well as business to business integration One of the most widely cited criticism of workflow technology (and now BPM) is its limited ability to deal with dynamic changes and business exceptions. Although a number of smart proposals exist in research communities to deal with dynamically changing workflows [Reichert and Dadam, 1997], [Baresi et al., 1999], [Kradolfer and Geppert, 1999], [van der Aalst, 2002], very few commercial products provide this functionality to the desired level. Another point of critique for workflows is that workflow modeling languages provide limited modeling constructs due to which the process logic can not be appropriately mapped to the workflow model. This results in compromised process models and subsequently compromised process goals. Studies have been conducted to investigate language constructs and their expressibility [Kiepuszewski, 2002], [workflowpatterns.com]. However, extending workflow languages impacts on the underlying workflow engines. Research can also be found on overcoming the inflexibility of workflow specification languages without introducing extended constructs or impacting on the workflow engine [Sadiq et al., 2004]. In this paper, we will identify a new problem in workflow deployment. This problem is not due to dynamic changes, or language restrictions. Rather, it can be found in well-behaving, stable processes built from a sufficiently expressive language. The problem arises when there is a contradiction between the way the process can be modeled and the preferred work practice. It is important to note that we do not deal with the cultural impact of process enforcement technologies on individual work practice, but rather on the inability of current business process modeling approaches to deal with some very typical scenarios prevalent in current business environments. Our focus in this paper is to define the problem, as a complete solution will be beyond the scope. However, we will provide deliberations on the required technology support to deal with this problem. A motivating explanation of the problem is given in section. 3. The impact of providing the functionality to deal with such problems within existing workflow management systems is discussed in section 4.
2. Basic Terminology Workflows are typically characterized through process models, where individual cases within these processes will constitute instances of the workflow. Many modeling approaches have been proposed for process models, with graph based approach being the pre-dominant choice in both research and products. Figure 2 shows basic modeling constructs used in typical graph based languages. Witold Abramowicz (ed.), Business Information Systems, Proceedings of BIS 2005, Poznan, Poland
6
BUSINESS INFORMATION SYSTEMS – BIS 2005
T5
T3 Begin
T1
T2
Choice
Fork T4
Figure 2.
Merge T6 Synchronizer
Do
T7
While
T8
End
Workflow Modeling Constructs
Let a workflow process W be defined as W = where N: Finite Set of Nodes, F: Flow Relation F ⊆ N Χ N ∀ n ∈ N, NodeType: n → {Coordinator, Task} N = C ∪ T, C ∩ T = φ where C: Set of Coordinator Nodes, T: Set of Activity Nodes ∀ c ∈ C, CoordType: c → {Fork, Synchronize, Choice, Merge, Begin, End, Do, While}1 Task nodes represent single manual / automated activities or sub processes that must be performed to satisfy the underlying business process objectives. Coordinator nodes allow us to build control flow structures to manage the coordination requirements. Basic modelling structures supported through these coordinators include Sequence, Exclusive Or-Split (Choice), Exclusive Or-Join (Merge), And-Split (Fork), And-Join (Synchronizer), and explicit begin and end coordinators. A process model will have several activities. An activity t ∈ T is not a mere mode in the workflow graph, but has rich semantics which are defined through its properties, such as input and output data, temporal constraints, resources requirements etc. The specification of the properties of a given activity identifies the activity type. In the discussion below we use t to refer to the activity type as well as for activity identification An instance within the workflow graph represents a particular case of the process. An instance type represents a set of instances that follow the same execution path within the workflow. Typically, an instance of the process will have one instance of each activity type defined in the process model (zero in case the activity is not on the execution path chosen due to choice coordinators). Instances of the activities depict the execution of the workflow. Each activity instance is governed by a finite state machine that characterizes the behavior of the activity through its observable states (such as available, commenced, completed, terminated etc). This is a well established execution model in existing workflow systems, slight variants of which can be found in several research papers as well as in workflow standards [www.wfmc.org]. Figure 3 gives such a model, which is simplified in order to highlight only those observable states that we will refer to later in this paper. 1
Further detail on this language and the full semantics of the coordinators can be found in [www.dstc.edu.au/praxis/flowmake].
Witold Abramowicz (ed.), Business Information Systems, Proceedings of BIS 2005, Poznan, Poland
WHEN WORKFLOWS WILL NOT DELIVER – THE CASE OF CONTRADICTING WORK PRACTICE
7
Initial
Available
Commenced
Completed
Suspended
Figure 3.
Activity Execution Model
Let i be an instance for W. ∀ t ∈ N, we define ActivityState: (t, i) à {Initial, Available, Commenced, Completed, Suspened} Under this framework, the workflow control data can be summarized as: A process has many activities; A process has many instances; An activity has many instances, but (zero or) one instance in a given process instance.
3. Contradicting Work Practice The notion of an instance in workflow systems is simple and quite well defined and understood. However this notion can prove to be too restrictive in certain scenarios which can be found in many domains. In fact this restriction forces the process models to be constructed in a format, which will contradict the way work is actually practiced in the organization. We provide below two such scenarios. These have been identified in experience with workflow deployment from real workflow users:
3.1. Scenario 1: e-Learning Workflow driven e-Learning has proven to be quite successful [Sadiq et al., 2002], since it provides the dual advantage of flexibility of time for students, as well as instructor control on course flow and assessments to ensure the quality of learning outcomes. Consider for example the workflow given in Figure 4, which represents a simplified study plan for a university course. Note however, that an instructor/tutor marking the assessments will have to commence and complete the “Mark” activity to enter the marks for each individual student. Given the current state of art in work list handlers, this will prove to be a cumbersome task. A much preferred work practice would be to do this activity for a group of students with a single point of interaction with the work list handler. Begin
Create Student Enrolment
Study Activity
Figure 4.
Take Assessment
Mark
Close Enrolment
End
e-Learning Workflow
Witold Abramowicz (ed.), Business Information Systems, Proceedings of BIS 2005, Poznan, Poland
8
BUSINESS INFORMATION SYSTEMS – BIS 2005
This scenario identifies the need to provide a facility for user controlled grouping of a number of instances of the same activity. Figure 5 illustrates the problem. Here A1, A2, A3, identify instances of the activity “Take Assessment”, and “Mark”, identifies the preferred group of assessments for a particular marking session. A and B represent individual questions within each assessment. A1 A B
Mark 1 A1.A A2.A A3.A
A2 A B
Mark 2 A1.B A2.B A3.B
A3 A B
Figure 5.
Grouping of Activity Instances
3.2. Scenario 2: Order Processing Order processing is one of the most widely used processes for automation in workflow technology. Typically an order request by a customer initiates the process. This is followed by the creation of a purchase order by the merchant, sending of this order to the supplier, organizing the shipment of the goods, and so on until the receipt of the payment from the customer is made. Figure 6 gives a simplified version of a typical order processing scenario. Note however that even this simple workflow, is fraught with complexities. A merchant would typically receive several purchase orders from customers. This can even be a very large number depending on the scale of operation. From these large number of orders, can be extracted an even larger number of items that are being ordered. Typically, one order will have a number of items, each with a potentially different quantity. It is perfectly logical to expect that the merchant may want to organize its purchase orders not per customer, but per item, or per supplier, or per some criteria which is deemed to be effective for the business operations. Thus different items from one purchase request may be ungrouped into different purchase orders, and items from several purchase requests may be regrouped together into one purchase order. As such, the ungrouping and regrouping requirement is orthogonal to the notion of an instance as perceived in current workflow systems.
Witold Abramowicz (ed.), Business Information Systems, Proceedings of BIS 2005, Poznan, Poland
WHEN WORKFLOWS WILL NOT DELIVER – THE CASE OF CONTRADICTING WORK PRACTICE
Begin
Create Purchase Request
Create Purchase Order
Recieve Shipping Notice
Figure 6.
Recieve Goods
Send Invoice
Recieve Payment
9
End
Order Processing Workflow
This scenario identifies the need to provide a facility for automatic ungrouping of an instance of an activity into a set of activities but still preserving the original intension of the activity (by executing the created set of activities). And then later to also provide a facility for user controlled regrouping of a number of instances of an activity. In the figure below, PR, PO, SN and INV represent the multiple instances of the activities Create Purchase Request, Create Purchase Order, Receive Shipping Notice and Send Invoice respectively. A, B, C, D and E represent the order items which are given together with their respective quantities, and reflect the content associated with each of these activity instances. PO 1 A 50 B 30 PR 1 A 20 B 30 C 20
PR 2 A 30 D 10 E 15
PO 2 C 10 D 10
PO 3 C 10 E 15
SN 1 A 50 B 30 C 10
INV 1 A 50 B 30 C 10 D 10
SN 2 D 5
SN 3 D 5
INV 2 C 10 E 15
SN 4 C 10 E 15
Figure 7.
Ungrouping and Regrouping of Activity Instances
The fundamental difference identified by the discussion above is that current workflow systems provide the facility to specify control dependencies between different activities of the same instance of the same process model. However, the problem described above will require the facility to specify dependencies between activities of different instances, generally of the same process model, but perhaps even of different process models.
3.3. What is a Workflow Activity? The above discussion requires that the scope of a workflow activity be further analysed and its granularity defined in the context of its scope. Workflow modelling approaches have generally focused on the process level semantics, leaving activity specification somehow “outside the scope” of the workflow Witold Abramowicz (ed.), Business Information Systems, Proceedings of BIS 2005, Poznan, Poland
10
BUSINESS INFORMATION SYSTEMS – BIS 2005
model. However, some researchers have addressed the question of workflow activity types. [Jablonski, 1994] distinguishes between Prescriptive and Descriptive activities (workflows). Where, Prescriptive workflows are known a priori, i.e. at design time and hence can be explicitly represented in the workflow model, descriptive workflows are characterized by “knowing what to do, but not knowing exactly when and how to do it in detail”. [Bartheless and Wainer, 1995] categorizes activities in a number of ways. This includes structured and unstructured activities, which correspond to [Jablonski, 1994] prescriptive and descriptive activities. [Bartheless and Wainer, 1995] describes unstructured activities as those that demand elaborate creative work, and hence are not suitable for decomposing into sub-activities, and will be outside the direct supervision of the workflow system. However, the outputs of these activities are still incorporated back into the system and therefore contribute to the coordination and control of the overall process. [Bartheless and Wainer, 1995] also categorize workflow activities as internal and external activities, which more or less correspond to structured and unstructured. The difference is that external activities, in addition to being unstructured, are executed completely outside the control of the workflow system. Thus, the interaction of these activities with workflow (system managed) process has to be undertaken manually. The Workflow Management Coalition provides a classification of workflow activities on the basis of their granularity. They divide activities into Atomic (a single unit of work), Iterative (controlling activity for the repeated execution of a set of activities), Sub-flow or Sub-process (an activity which is a container for the execution of a separately specified process definition), Block (an alternative to sub-flow, representing an explosion of a higher level activity), and Null (a dummy activity that performs no processing). Activities have also been classified into primitive and complex [Kuo et al., 1996], elementary and composite [Liu and Pu, 1997]. An interesting approach is given in [Carter et al, 2004], which classifies activities at the execution level, and proposes the use of configurable state machines. Thus the machine for a given activity is given on the basis of its granularity. However, we do not find in the literature a clear distinction between activities which can be grouped/ungrouped, and activities which are in a sense indivisible. [Bartheless and Wainer, 1995] briefly mentions the difference between workcase (instance) based and batch activities. Another noteworthy reference is the discussion on patterns involving multiple instances [workflowpatterns.com], specifically pattern on multiple instances with a priori runtime knowledge is relevant in this regard. This is the case where multiple activity instances can be spawned at runtime and the process does not proceed until all are completed. This is similar to the case of ungrouping identified in the discussion of the scenarios above. However, the scenarios also identify the need to group these activity instances with activity instances created in other process instances.
Witold Abramowicz (ed.), Business Information Systems, Proceedings of BIS 2005, Poznan, Poland
WHEN WORKFLOWS WILL NOT DELIVER – THE CASE OF CONTRADICTING WORK PRACTICE
11
To provide a clear distinction of the activity types identified in the scenarios above, we would like to classify activities into: •
Atomic: An activity of type t is called an atomic activity if it cannot be expressed by a set of activities also of type t, but with different content. • Compound: An activity of type t is called a compound activity if it can be expressed (executed) by a set of atomic activities all of type t. Furthermore, an activity of type t can be compound in one instance and atomic in another. Accordingly, we introduce the function ActivityLevel defined on t and i as follows: ∀ t ∈ T, ActivityLevel: (t, i) → {Atomic, Compound} The notion of an atomic and compound activity takes inspiration from the atomicity of domains in the relational model. Whether the value of an attribute is atomic or not, is rather subjective and dependent on the context for which it is being used. For example, the address below is a valid atomic value. Address: 24 Smith Drive, Springfield QLD 4069 Australia However, for a post office, or white pages application, it may be considered non-atomic since it needs to be divided into Address (Number: 24, Street: Smith Drive, Town: Springfield, State: QLD, Code: 4069, Country: Australia) On similar grounds we introduce the notion of a normalized activity as: Normalized: A compound activity can be normalized by expressing it as a set of atomic activities, where the atomicity is defined in accordance with the context, and represents a level of specification, which cannot be further split within that context. The underlying assumption is that the process for the atomic activity is the same as that of the compound activity. For example, we can consider a purchase request, which will generally consist of one or more items, of given quantities. The data for a “Receive Purchase Request” activity can be viewed as: PR # 25647 Customer Name: John Smith Customer Contact: 24 Harris St, Redlands QLD 4908 Item
Qty
1. 8976
4
Vendor 67
2. 8954
23
98
3. 8975
5
67
Witold Abramowicz (ed.), Business Information Systems, Proceedings of BIS 2005, Poznan, Poland
12
BUSINESS INFORMATION SYSTEMS – BIS 2005
This content is considered unnormalized, and hence we classify “Receive Purchase Request” as a compound activity. This content can be normalized resulting in a set of “Receive Purchase Request” activities with atomic content. This atomicity is a subjective issue, and within the given context of a purchase request may be at the item level or even at the unit level. Thus the view at the item level will be: PR # 25647 Customer Name: John Smith Customer Contact: 24 Harris St, Redlands QLD 4908 Item
Qty
Vendor
1. 8976
4
67
PR # 25647 Customer Name: John Smith Customer Contact: 24 Harris St, Redlands QLD 4908 Item
Qty
Vendor
2. 8954
23
98
PR # 25647 Customer Name: John Smith Customer Contact: 24 Harris St, Redlands QLD 4908 Item
Qty
Vendor
1. 8976
4
67
Or at the unit level, as 4 Purchase Requests with Item 8976 of quantity 1, 23 Purchase Requests with Item 8954 of quantity 1, and so on. The classification of workflow activities into atomic and compound activities is a prelude to the possible support that can be afforded by current workflow systems for the scenarios described above. To provide any grouping/ungrouping functions, the workflow system needs to be able to distinguish between these two activity classes. In the following section, we will provide further elaboration of how, and to what extend current workflow systems can deal with this problem and what additional functionality must be provided.
4. Required Technology Support Current features of typical state-based workflow management systems do not provide the functionality to support the scenarios identified above. To manage the process requirements of such scenarios, we need to redefine the notion of a process instance. Traditionally, an activity will have a single execution within a Witold Abramowicz (ed.), Business Information Systems, Proceedings of BIS 2005, Poznan, Poland
WHEN WORKFLOWS WILL NOT DELIVER – THE CASE OF CONTRADICTING WORK PRACTICE
13
given process instance. However, in case of compound activities, their atomic counterparts can actually acquire a life of their own, and furthermore, they may be regrouped with collections from other process instances. Thus the notion of a process instance as understood in current WFMSs does not hold anymore. There is a need to manage activity instances at multiple levels e.g. approval function is applied at the purchase request level, but a cancellation function can be applied at the item level. This points towards a solution that provides the capability to work with multiple process views, that is, the capability to apply some functions to the atomic activity instances, and others to the compound level activity instances, depending on what the requirements warrant. We call these multiple views, shadow process instances (SPI). For a given process model, there can be multiple shadow process instances or SPIs, which will be created as ungrouping, and re/grouping of activity instances takes place. At any given time, the user may choose the appropriate SPI to work with, or it may be determined by the system. For example, an item within a purchase request, or all items within a shipment order, or all invoices for a given customer. Clearly, all views need to maintain a consistent state of progress for the process.
4.1. Extensions to the WFMS Functions In order to cater for the advanced process requirements identified above, extensions to a typical state-based WFMS will be required. These extensions are required to provide the two functions of group and ungroup. Simply put, the two functions can be described as: Group The group function is applied to a set of activity instances of a given activity type t, where ActivityLevel (t, i) = Atomic and ActivityState(t, i) = Available. and i: 1 .. n are instance numbers. The function generates an activity instance of the same activity type as the atomic activities that constitute it but with collated content, where ActivityLevel(t, k) = Compound and ActivityState(t, k) = Available, and k is the instance number in which the compound activity will be performed. Ungroup The ungroup function is applied to a single activity instance of a given type t, where ActivityLevel (t, k) = Compound and ActivityState (t, k) = Completed and k is the instance number in which the compound activity was performed. The function generates a set of activity instances of the same activity type as the compound activity but with normalized content, where ActivityLevel (t, i) = Atomic and ActivityState(t, i) = Completed and i: 1 .. n are instance numbers. Note that these functions deal with activity instances independent of the process instances, which is exactly the feature required. Clearly there is a need to Witold Abramowicz (ed.), Business Information Systems, Proceedings of BIS 2005, Poznan, Poland
14
BUSINESS INFORMATION SYSTEMS – BIS 2005
manage the activity signature as the activities get grouped or ungrouped. In fact, a number of components within the WFMS will be impacted in the provisioning of these functions. We have identified 3 areas of impact, namely the Work List Handler, the management of the Workflow Control Data, and Invoked Applications, and present below an account of the required extensions: The Work list Handler is the main front end component for providing the un/grouping functions. There are two issues in this regard. Firstly, when are these functions invoked, and secondly, what data is required to perform these functions. With regard to the invocation of these activities, there are two possibilities: The functions can be auto-invoked or user-invoked at designated activities within the process model. That is the functions are associated with designated activities, and can be enabled for auto-invoke. We propose that activity ungrouping take place when a designated (compound) activity reaches the Complete state, generally through an autoinvoke. This will result in the creation of multiple SPIs where the ungrouped activity is presented at an atomic level. The state of the compound and all its constituent atomic activities remains the same. It is important to note that once atomic activities are created, process control flow is based on the atomic activities only, that is, the corresponding compound activity does not engage in control flow any more. Activity re/grouping can take place when a designated activity is put into Available state, and the function can be auto/user-invoked. Clearly the group must maintain the constituent activity instance references. Completion of a re/grouped activity will trigger all constituent activity instances to be put into complete state. The default case of grouping is when all available activates of a given type are grouped. For example marking all available assessments. However, it is apparent that user controlled definition of the group will be sought. For example, Group all items of purchase requests from the same customer, Group all assessments completed on a given date, Group invoices prepared by a given performer. Thus there can be a variety of requirement for defining the criteria for grouping, such as activity state data, activity performer data, and clearly activity content. Providing the requisite data to these functions is essential since it defines the criterion for un/re/grouping. The ungrouping function can be automated to a large extent provided the criterion is known. For example, ungrouping the items of a purchase request, or ungrouping the units of the items of a purchase request. On similar grounds, re/grouping may be automated, although it makes better sense to have this function user controlled. However, whether automated, or user controlled, the need to have access to the activity related data is obvious. There are several questions in this regard. How do we present such multifaceted data, what tools (e.g. query, filter, order etc.) we can provide the user to enable effective definition of groups, what restrictions must be imposed on the composition of groups? Witold Abramowicz (ed.), Business Information Systems, Proceedings of BIS 2005, Poznan, Poland
WHEN WORKFLOWS WILL NOT DELIVER – THE CASE OF CONTRADICTING WORK PRACTICE
15
Where as the work list handler provides the front end for the invocation and specification of group/ungroup functions, clearly the specification has to be supported at the back end, primarily through the Workflow Control Data. Traditionally, the workflow control data has a schema similar to the one given in section 2, i.e. A process has many activities; A process has many instances; An activity has many instances, but (zero or) one instance in a given process instance. However, to provide for the advanced requirements presented above, this has to be extended, such that an activity can be tracked through the various grouping and ungrouping that is undertaken upon it. We propose to extend the workflow control data to incorporate the concept of a group. The extension is simple, but it will be demonstrated in the next section how this simple extension effectively maintains the activity signature. Thus as before: • A process has many activities • A process has many instances However, here: • An activity can have (zero or) many instances in a given process instance. Thus (process) instance id is no longer sufficient to identify an activity instance We further introduce the notion of a group instance which represents a dynamically defined group of activity instances. Thus: • An activity instance can belong to only one group instance, but a group instance can have multiple activity instances • A process instance can have multiple group instances and a group instance can belong to multiple process instances Lastly, the third mentionable aspect of impact in the functionality of the WFMS is the ability of the Invoked Applications to deal with content at atomic as well as group level. For example, the ability of an instructor to enter marks for multiple assessments/students within the same session. However, we do not elaborate on the underlying applications any further in this paper for two reasons: firstly this aspect is not part of the workflow management functions, and secondly the applications are already reflective of the desired work practice, and it is in fact the process management which is lacking to provide this ability.
4.2. Deploying the New Functions We illustrate in this section the execution of the workflow and utilization of the extended functionality as elaborated in the section above. Consider a simple example with three sequential activities, A, B and C. Let an Ungroup function be associated with Activity A, and Group and Ungroup functions be associated with both Activity B and C. Since we are dealing with multiple aspects of the activity, we introduce the following notation to illustrate the example. G P
A
S I
Where A: Activity Id/Type, P: Process Instance IDs, I: Activity Instance Id, G: Group Instance ID, S: State of an Activity, (C: Complete, A: Available)
Witold Abramowicz (ed.), Business Information Systems, Proceedings of BIS 2005, Poznan, Poland
16
BUSINESS INFORMATION SYSTEMS – BIS 2005 C
C
A 1
C
C
A 1
2
C
A 2 1
A
1
A 3 1
C A
4 1
C
C
C
A 5 1
A 6 1
7
8
C
A 2
C
A 9 2
C
A
A
10 2
11 2
12
1. Two instances of the process are created (with process instance Id 1 and 2), and consequently we have two instances of Activity A, with activity instance Id 1 and 8 respectively. We assume that the collated content associated with activity A within instance 1 consists of 6 atomic elements, and that with A in instance 2 consists of 4 atomic elements. On reaching the complete state, the ungroup function is auto-invoked, resulting in the generation of 6 ad 4 (atomic) activity instances respectively. C
C
A 1
A 3 1
A
B 2 1
C
7
A
6
A
2
11 2
2
12
A
B 7
C
A 10 A
B 2
C
A 9 2 A
B 5 1
C
A 2
A
B 4 1
C
A 6 1
A B
3 1
C
A 5 1
A
B 1 1
C A
4 1
A
B 1
C
A 2 1
A
B 8
B
2
9
2
10
2. According to process control flow, each atomic activity will schedule the next activity, i.e. B in this case. Note as before that the underlying assumption is that the process for the atomic activity is the same as that of the compound activity. A
A
B 1
A
B 1 1
B 2 1
1
A B
3 1
A
A
A
B 5 1
B 6
2
A
A
B 7 2
B
11
A B
8 2
2 A B {1,2} 12
B 1
A
B 4 1
9 2
3
10
A B
2
13
3. On reaching Available state, the group function can be (user) invoked, and grouping can be defined in accordance with application requirements. This is provided through the extended interface of the work list handler (see previous section for more detail). 1
C
2 C B {1,2} 12
B 1
11
3
C B
2
13
4. The group activities, reach Complete state 1
C
2 C B {1,2} 12
B 1
1
C 1 B
1
11
C 1 B
1 1
C 2 B
2 1
C 2 B
3 1
C 2 B
4 1
3
C
2
6
2
B 5 1
C B
2
C 3 B
C 3 B
7 2
13
C 3 B
8 2
C B
9 2
10
5. On reaching the complete state, the state of all atomic activities associated with the group activity is also simultaneously changed. The control data for these activities also records the group they belong to.
Figure 8.
Illustration of Workflow Execution using Un/Group Functions
Witold Abramowicz (ed.), Business Information Systems, Proceedings of BIS 2005, Poznan, Poland
WHEN WORKFLOWS WILL NOT DELIVER – THE CASE OF CONTRADICTING WORK PRACTICE
17
5. Conclusions Workflow solutions have mostly been the target of criticism due to their limited ability to cope with frequently changing business processes and often due to language restrictions. In this paper we have identified a new problem of workflow deployment, where the desired work practice cannot be supported by the functionality of typical workflow systems. The two scenarios presented demonstrate the problem and identify advanced process requirements which raise the need to re-think the notion of a process instance. The main aim of this paper was to identify and motivate this problem. We have, however, also provided deliberations on required technology support to provide for the new notion of a process instance. Our approach is based on a process being supported simultaneously by multiple shadow process instances. In order to provide this support, we foresee an impact, although small on the functionality of the Work List Handler, and a revised schema for the Workflow Control Data.
6. References 1. [van der Aalst, 2002] W. M. P. van der Aalst (2002) Exterminating the Dynamic Change Bug: A Concrete Approach to Support Workflow Change. Information Systems Frontiers, Vol. 3, No. 3, pages 297-317. 2001. 2. [Baresi et al., 1999] L. Baresi, F. Casati, S. Castano, M. G. Fugini, I. Mirbel, B. Pernici (1999) WIDE workflow development methodology. Proceedings of the international joint conference on Work activities coordination and collaboration. San Francisco, California, United States, 1999. Pages: 19 - 28 3. [Bartheless and Wainer, 1995] Paulo Bartheless, Jacques Wainer (1995) Workflow Systems: a few definitions, a few suggestions. Proceedings of the Conference on Organizational Computing Systems, Milpitas, CA. USA, Nov 1995. 4. [BPEL4WS] www-106.ibm.com/developerworks/library/ws-bpel/ 5. [Carr, 2003] Nicholas G. Carr (2003) IT doesn’t matter. Harvard Business Review. May 2003 6. [Carter et al, 2004] Belinda Carter, Joe Y.-C. Lin, Maria E. Orlowska (2004) Customizing Internal Activity Behaviour for Flexible Process Enforcement. The Fifteenth Australasian Database Conference Dunedin, New Zealand, Jan 18-22, 2004. 7. [ebXML] www.ebxml.org 8. [Ellis and Nutt, 1980] C. A. Ellis, G. J. Nutt (1980) Office Information Systems and Computer Science. In: ACM Computing Surveys, 12 -1, pp. 27-60. 9. [Jablonski, 1994] Stefan Jablonski (1994) MOBILE: A Modular Workflow Model and Architecture. Proceedings of 4th International Conference on Dynamic Modelling and Information Systems, Netherlands, 1994 10. [Kiepuszewski, 2002] B. Kiepuszewski. Expressiveness and Suitability of Languages for Control Flow Modelling in Workflows. PhD thesis, Queensland University of Technology, Brisbane, Australia, 2002.
Witold Abramowicz (ed.), Business Information Systems, Proceedings of BIS 2005, Poznan, Poland
18
BUSINESS INFORMATION SYSTEMS – BIS 2005
11. [Kradolfer and Geppert, 1999] Markus Kradolfer, Andreas Geppert (1999) Dynamic Workflow Schema Evolution based on Workflow Type Versioning and Workflow Migration. Proceedings of the Fourth IFCIS International Conference on Cooperative Information Systems (CoopIS99). Edinburgh, Scotland. Sep 2-4, 1999. 12. [Kuo et al., 1996] Dean Kuo, Michael Lawley, Chengfei Liu, Maria E Orlowska. (1996) A General Model for Nested Transactional Workflows. Proceedings of the International Workshop on Advanced Transaction Models and Architecture. Goa, India, August 1996 13. [Liu and Pu, 1997] Ling Liu, Calton Pu (1997) ActivityFlow: Towards Incremental Specification and Flexible Coordination of Workflow Activities. David W. Embley, Robert C. Goldstein, Editors, Proceedings og the 16th International Conference on Conceptual Modelling (ER 97), Los Angeles, USA. Springer Verlag LNCS 1331. Nov 1997. 14. [Mahling, 1995] D. E. Mahling, N. Craven, W. B. Croft (1995) From Office Automation to Intelligent Workflow Systems. In: IEEE Expert, 10 June 1995, pp. 41-47. 15. [Reichert and Dadam, 1997] Manfred Reichert, Peter Dadam (1997) ADEPTflex Supporting Dynamic Changes of Workflow without loosing control. Journal of Intelligent Information Systems (JIIS), Special Issue on Workflow and Process Management, 1997. 16. [RosettaNet] www.rosettanet.org 17. [Sadiq et al., 2004] Shazia Sadiq, Wasim Sadiq, Maria Orlowska (2004) A Framework for Constraint Specification and Validation in Flexible Workflows. Information Systems, Volume 30, Issue 5 , July 2005, Pages 349-378 18. [Sadiq et al., 2002] Shazia Sadiq, Wasim Sadiq, Maria Orlowska (2002) Workflow Driven e-Learning – Beyond Collaborative Environments. Networked Learning in a Global Environment. Challenges and Solutions for Virtual Education. Berlin, Germany. May 1 - 4, 2002 19. [Smith and Finger, 2003] Howard Smith, Peter Finger (2003) IT doesn’t matter – Business Process Do. August 2003. Meghan-Kiffer Press 2003. 20. [WFMC] www.wfmc.org 21. [workflowpatterns.com] www.workflowpatterns.com
Witold Abramowicz (ed.), Business Information Systems, Proceedings of BIS 2005, Poznan, Poland
