## 4 Collecting Process Data  
Business processes usually involve multiple contributors, which perform different tasks. Therefore, designing a real-life process model is a complex activity and requires much communication between the process architect and its main participants. The idea proposed in this paper consists of providing an automated tool that gathers the required data in the simplest possible declarative form. In the first step, all the process participants need to determine which tasks are performed within their area of responsibility and provide the following information regarding each task:  
* data entities that are required or are optional for execution,
* data entities created after execution,
* maximum number of repetitions.  
One of the ways of providing the required input is a web-based form, which can be used to acquire data from the participants of the process. Its sample layout is presented in Figure 4. It is also possible to bypass the form itself and provide the input in a spreadsheet file.  
Figure 4: Screenshot of the prototype form for the data acquisition.  
Such a business process description may be prepared using spreadsheets. Let us analyze a case study example model of a supply process, which is realized by four participants: warehouse operator, accounts payable specialist, purchasing specialist and purchasing manager. Their roles and responsibilities are presented in Figure 5.  
Detailed task specifications performed by different roles are listed in Tables 1-4. Data entities that are optional for task execution are listed in parentheses. The general process specification based on inputs from different participants includes 12 tasks and 13 data entities (Table 5).  
In addition, the process designer must precisely define the initial state of the process in the form of a list of data entities that are present before its execution. Additional required information is the set of final states of the process, which covers the desired goal as mandatory information. Optionally, it may also include different error states, which may happen during execution of the process. In this case, the initial state of the process requires only a goods request data entity to be present. Since the goal of the analyzed business process is to provide requested goods, it has two possible goal states:  
* If requested goods are available in the warehouse, then there is no need for purchase order; then inventory checked is the only data entity required. All data related to purchase order processing should not exist.
* Otherwise, the expected goal is a completed purchase order, which corresponds to the order completed data entity.  
After gathering all the data entities and determining boundary states of the analyzed business process, its participants are able to indicate which data entities cannot exist before the task is executed. For example, if a purchasing specialist is performing the task create order, then the data entity order reviewed should not be present, as there was no order to be approved before. Correspondingly, an existing data entity can be removed as a result of an execution of a task. To illustrate this situation, the task issue payment can be shown as an example. If the payment is done, there are no more funds released for the order, and the release funds data entity should be deleted.  
The final step of the process data collection consists of merging the information from all the process participants into a single spreadsheet representation.