ARCWAY Cockpit

Event-Driven Process Chains - Overview

Überblick

Event-driven process chains allow for the representation of business processes of an organization. In doing so a concise and intuitively understandable visualization of the process is emphasized in particular. An event-driven process chain basicallly consists of process steps and events. Process steps represent work steps and events represent states or events within the process. Event-driven process chains are bipartite graphs which means that only two plan elements of different type can be linked. Thus, for instance a link between two process steps is not possible. Process steps and events are linked by the control flow. Event-driven process steps in ARCWAY Cockpit contain only a small, optimized selection of syntax elements.

Plan Elements

Competency


Competencies present the parts that are involved in the contained process steps. Three types of competencies are available - Business Function, Organisational Unit and Application.

Process Step

Process steps are work steps.

Event

Events represent an event or a state in a process. Every process in an event-driven process chain diagram starts and ends always with an event.

Process

Processes are semantically the same as process steps. This can be recognized by the similarity of the two plan element symbols. The process, however, additionally indicates that it is refined in another plan. Thus, the process Article Production could be refined in another plan so that the process of producing the article is described in more detail there.
To create this refinement:

  1. Create a new event-driven process chain plan.
  2. Name the plan like the process to be described.
  3. As soon as you are in edit mode, drag the desired process from the repository onto your plan.
  4. Now, enlarge the obtained element to such an extent that you can place the entire refinement within the process.
  5. Model the refinement within the process.
  6. Now, you can navigate to the refinement from the original plan by clicking on the subelements of the process in the repository.

Storage

The storage element represents a passive component of the process chain. Processes can read information from or load information onto the storage. This allows for showing additional information about used data, supported systems or created files in the model.

AND-Splitter and AND-Connector

The AND-Splitter and AND-Connector templates indicate a parallelization in the process. This means that the process steps behind an AND-Splitter within the process chains can be executed simultaneously and independently of each other.
The AND-Connector is the opposite operation of the AND-Splitter and joins the parallel control flows again.
In the example on the left an event occurs that forces an organization to produce new articles. This means that material has to be purchased and a production plan has to be developed. Those process steps do not depend on each other und can be maintained at the same time. After those steps have been performed, both control flows will be synchronized again.
In a well-structured process plan it has to be minded that only pairs of AND-Splitter and AND-Connector occur together.

OR-Splitter and OR-Connector

The templates OR-Splitter and OR-Connector mark a case differentiation within the process. This means that the process steps behind an OR-Splitter within the process chains are alternatives. It has to be said that at least one of the options has to be selected. It is also possible, however, that several of these options are executed.
The OR-Connector is the opposite operation of the OR-Splitter and joins the alternative chains again. In the example on the left an organization has to react to an order. Thereby articles had been ordered, that are currently not available. The company has now the options to either produce new articles or purchasing articles from a third party supplier or performing both steps in order to be able to ship the order. After taking any action the control flows can be synchronized again and the order can be shipped.
Relating to the example in the diagram the decider could choose sausages or potato salad or sausages and potato salad.
With regard to the OR-Splitter it has to be considered that a case differentiation has to be preceded by a decision due to which the cases are selected. As a decision is always a process step it is not possible to place a case differentiation behind an event. Thus, a case differentiation can only follow a process step
It should be minded in a well-structured process plan that only pairs of OR-Splitter and OR-Connector occur together.

XOR-Splitter and XOR-Connector

The templates XOR-Splitter and XOR-Connector mark an exclusive case differentiation in the process. This means that the process steps behind a XOR-Splitter within the process chains are alternatives. In opposition to the OR-Splitter and OR-Connector, however, it is not possible that several of these options are executed. Thus, it is an exclusive or. The XOR-Connector is the opposite operation to the XOR-Splitter and joins the alternative chains again.
In the example on the left an organization checks the availability of any article that has been ordered. Thereby the article can either be available or not available. If the article is not available it has to be produced. After taking any action the control flows can be synchronized and the article can be shipped.
With regard to the XOR-Splitter it has to be considered that a case differentiation has always to be preceded by a decision due to which the case is selected. As a decision is always a process step it is not possible to place a case differentiation behind an event. Thus, a case differentiation can only follow a process step.
It should be minded in a well-structured process plan that only pairs of XOR-Splitter and XOR-Connector occur together.

Plan Element Relations

Containment

Containment A plan element that contains another element graphically is also considered to be its container in the repository.
This behavior is used in the example to display the competency for a process step. The "Customer Management" is responsible for the process step "Search Customer Data" in the example.

Causality

Causality A control flow creates causality relations between process steps, processes and events. The plan element that is anchored to the arrow succeeds the plan element that is anchored to the unmarked end of the control flow.
The process step "Search Customer Data" is the successor of the event "Customer likes to order sth." in the example.

Access

Access A control flow that connects a process step and a storage creates an access relation between those two plan elements. In this case the arrows of the control flow decide on the reading direction.
The storage "Order Item" is read by the process step "Collect Customer Order" in the example.

Related Topics:
Extended drawing support for event-driven process chains