# Spreadsheets as Interoperability Solution for Business Process Representation
## 3 Spreadsheet Representation of a Business Process  
To clarify the understanding of what a business process is and how it can reflect the real-life workflows, [PERSON] et al. [28] identified common ingredients for business processes:  
* activities--units of work performed manually or as an automated service, an atomic activity that cannot be divided is called a task,
* events--circumstances that happen without measurable duration,
* decision points--situation when a decision is made which affects the execution of the process,
* actors--process participants, seen as people, organization or software systems,
* physical objects--equipment, materials or documents,
* immaterial objects--electronic data, people's knowledge,
* outcomes--final products or services, as well as negative outcomes e.g., refusals or error messages,
* customer--internal or external recipient of the outcome.  
Table 2 describes how the different process ingredients are represented in the mentioned notations. The summary was based on [29; 30; 31]. The results of the comparative analysis show that, within the selected languages, only BPMN and UML Activity Diagrams can satisfy the requirement to represent all common process ingredients. However, according to the detailed comparison of UML and BPMN [32], BPMN process models can cover a larger number of business cases, including not only the process itself, but also specifications of the analyzed system in terms of its requirements and implementation.  
Activities executed within a business process can be easily represented as an enumerated list in a tabular form. Such forms can be then saved as spreadsheet files. Taking into account the fact that spreadsheet editors are a popular means of storing and processing information in companies, they are also used for process modeling.  
In the proposed solution, a business process is represented by a spreadsheet table, where rows correspond to tasks (or phases). Columns contain properties of the selected phase. Task and condition names should start with a capital letter, while all instructions are written in lowercase. Following column types are used:  
* Order--the number of the corresponding phase (starting from one). If two or more tasks are performed in parallel or alternatively, we use letters to distinguish different branches, e.g., \"2b\", \"3a\" etc. If a phase follows a logical gateway, its naming pattern is: \(NxA\) where \(N\) is the natural  
Figure 1: An example of an equivalent model to the spreadsheet-based process description presented in Table 1 (based on [26]).  
number of the phase, \(x\) is a lowercase letter (a-z) representing the current branch and \(M\) is the natural number of the phase in this branch. If the branch contains only one activity, the letter \(M\) does not need to be included. In case when the process includes nested gateways, the names of its sub-phases are defined by extending the main phase number with the appropriate branch and sub-phase.
* Activity--name of the performed action or instruction. For example, if there is a need for a loop or skipping the phase, this field should be filled with a \"goto\" statement and number of the desired phase, e.g., \"goto 7\".
* Condition--a condition needed to perform the selected action. If the task executes every time this field should be left empty. In order to implement a XOR-gateway this field should be filled with an appropriate condition and the word \"else\" for the other task performed in the same phase. In order to implement an OR-gateway the fields mentioned before should be filled with two separate conditions. This column is also used when events are triggered under certain conditions, e.g., after a determined amount of time.
* Who--a department or person that executes the task. This field corresponds to a swimlane.
* Input--data objects required by the corresponding activity as its input.
* Output--data objects generated by the corresponding activity as its output.