2.2 Business Process Management and Workflow
2.2.4 Business Process and Workflow Modelling
2.2.4.1 Workflow Management Concepts and Perspec-
The WfMS is responsible for joining different workflow perspectives to enable the business process that run on top. When talking about workflow modelling, there are different perspectives that can be looked at, all of which form a crucial part of the modelling process. These perspectives are given by Van der Aalst (2004) as:
1. Control flow perspective, which deals with the process definitions and task order;
2. Resource perspective, which gives an organisational view of the structure and roles;
3. Data perspective, dealing with the information generated within the pro- cess;
4. Task perspective, which is indicative of the function in the process i.e. the operations;
5. Operational perspective, deals with the application and actions.
To understand the discussions that follow, some concept regarding workflow need to be discussed. The following concepts are described originally and in more detail in Van der Aalst and Van Hee (2004).
• Cases: From an organisation point of view, a WfMS deals with cases. This case refers to the process that deals with a desired output or prod- uct. In other words, the process and workflow of dealing with a Condition Monitoring event would more commonly be referred to as a case. Cases can also belong to the same type to such an extent where they follow the same basic route but differ in small details. This makes it easier design new processes for additional cases as templates already exist. Van der Aalst and Van Hee (2004) also states that between the start and comple- tion of a specific case, three attributes exist to describe the current state. First, there are the values for the different attributes referring to that case, second there are the conditions relating to that case and thirdly, the case’s contents.
• Task: When breaking down a process to its most fundamental form, it can be seen that it is held together by individual tasks or activities. These tasks refer to the intangible aspect of work. It refers to the thing that a role player needs to finish in order to progress further along the process. Each task needs to be completed in full in order to complete a process. Looking at the progress of a process, a task has boolean prop- erties in the sense that it can only be finished or not.
• Process: Van der Aalst and Van Hee (2004) refers to a process as “a pro- cedure for a particular case type”. In this sense, a process is a sequence
of tasks and activities that is applied to accomplish the execution of a case. This inherently mean that different cases can use the same pro- cess, either the case refers to a standard process that applies exactly or different cases can refer back to a template which forms the basis for the case but is merely adjusted for very specific attributes. As the process builds upon tasks, a condition attribute is added to refer to the order in which different tasks are performed.
• Routing: Within a process filled with tasks, there is a certain path that needs to be followed in order to be able to go from the start of the pro- cess to the outcome. Routing refers to this path or branch that lays out the sequential nature of the process. In the simplest form, the routing can exist merely as a single line that goes from task to the next and so on until the process is completed. In most cases however, there are branches within the process that split from on task and then connect to two simultaneous tasks which needs to be completed before moving on. In this case, the routing is referred to as parallel routing.
• Triggering Events: Trigger events exist as the set off point for any pro- cess. Trigger events are the events that calls in the need for a case to be satisfied and thus enables the process to start. Either a person or an automated system can perform the triggering. In essence, there are three types of triggering events. First, a person can trigger an event as part of an initiative to accomplish an outcome. Secondly, external or en- vironmental events can enable a trigger as a reaction, and then thirdly, a trigger can have a time attribute and therefore triggered as part of a routine.
Van der Aalst (2004) separates the kinds of workflows into three dimensions. These dimensions encompass the control-flow dimension, the resource dimen- sion and the case dimension. The first dimension, control-flow, handles the type, placement and layout properties of the tasks. This would entail whether the tasks are conditional, parallel, sequential or iterative. The second dimen- sion, resources, covers the appointing of resources (personnel, physical asset) to certain tasks for execution. This dimension goes on to appoint the resource
class or role from an organisational entity. The case dimension is attributed towards the different cases that are specified to be executed by a specific pro- cess and resource. In general, workflows are processes that were executed to satisfy a case. Van der Aalst (2004) refers to these processes more formally as case-driven processes.