So, how can you model the simple fact that the process consists of a discussion process followed by a voting process? If you strictly follow the BPMN specification, you cannot.
One possibility is to relax the BPMN rules a little bit for high-level diagrams and simply use the diagram from Figure 1. If you decide to do so, you should define in your modeling conventions at which points you relax the BPMN rules.
The other possibility is not to use BPMN for this purpose, but another notation or free-form diagram, as in Figure 3. Here, arrow symbols have been used which often can be found in value-chain diagrams or process landscapes.
3 Simplifying the Process Diagrams
A first attempt to make the two sub-process’s diagrams more readable is shown in Figure 4 and Figure 6. First of all, the data-objects and the message-flows have been removed. In order to understand what is going on in the process, these details are not required. They are only confusing. Since there are only two roles – the workgroup coordinator who carries out the process, and the voting members – it is rather clear from the activities’ descriptions which e-mails will be exchanged. Therefore, the message flows do not add valuable information for understanding the process. Nevertheless, a simplified diagram with message flow will be shown later on as an alternative representation.
The data objects, on the other hand, are more interesting. They represent the various documents and lists which are used and created in this process. The workgroup coordinator can seen from the original model which documents he requires for each activity, and where the resulting information is used. In the first step, however, it is easier to understand the sequence flow without the data flows. In a second step such additional information may be added to the model. A variant of the model with data flow will also be shown later on.
In the original diagram, the tasks
have been marked with icons as “user tasks” or “send tasks”. These
Icons have been removed for two reasons. The first reason is that the definitions of these task types in the BPMN specification are rather restricted: A user task is defined as “a typical ‘workflow’ task where a human performer performs the task with the assistance of a software application and is scheduled through a task list manager of some sort” [BPMSpec, p. 167]. Since this process is apparently not supported by a workflow management system, the tasks are not strictly user tasks. A send tasks, on the other hand, only has the purpose of assigning data to a message and sending that message – but nothing else [BPMNSpec, p. 163 and 444]. In this process, however, the tasks with envelope icons apparently require the workgroup coordinator to combine information from various lists with predefined text, before an e-mail is sent. Due to these additional steps, the tasks are not pure send tasks.
Of course, it would be possible to relax the strict task type definitions and simply use the icons for identifying tasks which consist mainly of user actions or which have the main objective of sending out a message.
The second and main reason for omitting the icons is that they do not provide much help for understanding the process. All of the activities involve the user, and the activities’ names or descriptions clearly indicate whether messages are sent.