Actions

Difference between revisions of "Towards EPC standardization"

From EPC Standard

Line 203: Line 203:
 
</div>
 
</div>
 
</div>
 
</div>
<vote type=1 />
 
 
[[Category:Platform Details]]
 
[[Category:Platform Details]]

Revision as of 17:45, 14 January 2021

The process of standard-making is fundamentally based on agreement and consensus of a domain community. This platfom provides a web-based, collaborative system specifically designed for the purpose of EPC standardization. It is openly accesible for everyone interested. The platform provides a community where domain experts and practitioners can come together and take an active part in developing a standard for the EPC language. For further information regarding the standardization process and additional details, please visit Collaborative Specification Engineering - How To.

The Event-Driven Process Chain

EPC example process.png

The event-driven process chain (EPC) has been one of the most dominant languages for business process modelling over the last decades and is well established in both research and practice.[1][2][3] The maturity of EPCs manifests itself in numerous scientific publications covering a wide range of language aspects. In addition, the EPC has proven its relevance in practice by being implemented in most common business process modelling tools.[4] However, in contrast to languages such as Business Process Model and Notation (BPMN), whose popularity has been significantly boosted by the existence of a defined standard[5] no systematic standardization effort for the EPC language has been made yet. Consequently, the absence of a standard hampers EPC usage and diffusion, especially due to difficulties in terms of interoperability, further development and overall acceptance.[6][7] Nowadays, most business process modelling languages have been standardized by respective institutions, for example the Object Management Group (OMG) or the International Organization for Standardization (ISO). The publication of those standards ensures international adherence to specified language components such as syntax, notation or exchange format. Although there have been attempts to provide detailed specifications for certain aspects of the EPCs language (e.g. [8][9]), an official standardization process guided by a standardization development organization (SDO) has not been initiated to date. In addition, due to the widespread nature of EPCs and extensive previous research in the field, there exists a multitude of contributions ranging from various syntactical or semantical propositions to multiple language extensions[10][11], ultimately resulting in a mosaic-like EPC landscape. Naturally, this situation renders standard-making a difficult challenge.

EPC Process Elements

This section gives an overview over the EPCs’ elements. Thereby already published literature about the EPC is recited. Therefore, the state of this chapter does not necessarily have to be coherent to the collaborative acquired state of this platform. The general elements of the EPC (speaking about the basis EPC, not the extended EPC) are the event, the function, and the three logical connectors AND, XOR and OR. Furthermore, the control flow arcs can be considered as a process element, too.

Event

The Event represents a current state in an EPC model and is both used as the starting and ending activity of an EPC model. Hence, every EPC model has at least one start and one end event.[12][13][14] Events are able to trigger functions (and are triggered by them). Therefore, the event and the function form an alternating entity, whose only exception is the abovementioned start and end event.[8][13][15] Furthermore, it is relevant to emphasize the non-existing decision-making power of an event. As it ‘only’ represents a current state, it is not able to decide about the further path of the model. Therefore, OR- and XOR-operators must not follow after an event.[13][14][16]

Function

The Function represents an action or a task in an EPC model. They can be therefore described as ‘current state changes’ or transformations from an initial state to a resulting state. Unlike events, they have decision-making power and are able to trigger all kind of operators.[8][13][15]

Operators

In order to represent possible splits and joins in the logical control flow, three types of connectors are used. These are the AND operator, the OR operator, and the XOR operator. Following the AND operator, every ensuing path has to be treaded. After an OR operator, either one, two, three… or all ensuing paths ‘’’can’’’ be treaded, while the XOR represents an exclusive decision (just one of the following paths can be treaded). Some literature demand that for the sake of semantics and pragmatics splitting paths need to be merged again by the same type of operator.[8][13][16]

EPC Quality

Aspects regarding the quality of EPC models can be distinguished in different categories. While there are general applicable quality recommendations like the seven process modelling guidelines [39], some quality frameworks like the 3QM or the SIQ Framework are concerning the categories ‘’syntax’’, ‘’semantic’’ and ‘’pragmatic’’. Following this structure, EPC quality criteria will be assigned to these categories on this platform. As Fellmann et al. already did such an assignment of EPC criteria[6], in the following their results will be presented in aggregate form.

Syntactical criteria

Semantic criteria

Pragmatic criteria

Exchanging and storing EPC models

Exchange formats in literature

EPC extensions

References