Cadena de procesos impulsada por eventos

La cadena de procesos impulsada por eventos ( EPC ) es un lenguaje de modelado gráfico para representar los procesos de negocio de una organización en el modelado de procesos de negocio / representación de la organización de procesos (flujos de trabajo y pasos de trabajo) en el mapeo de negocios . Fue desarrollada en 1992 por Gerhard Keller, Markus Nüttgens y August-Wilhelm Scheer en la Universidad de Saarland en Saarbrücken como parte de un proyecto de investigación con SAP SE para la descripción semiformal de procesos de negocio. ^{[ 1 ]} El método fue desarrollado como parte de la Arquitectura de Sistemas de Información Integrados (ARIS) para el modelado orientado a vistas de procesos de negocio y es un elemento esencial del concepto ARIS . ^{[ 2 ]}

Las empresas utilizan diagramas de cadena de procesos basados ​​en eventos para organizar los flujos de trabajo de los procesos de negocio , originalmente en conjunto con el modelado de SAP R/3 , pero ahora de forma más generalizada. Muchas empresas lo utilizan para modelar, analizar y rediseñar procesos de negocio. El método de cadena de procesos basado en eventos se desarrolló dentro del marco de la Arquitectura de Sistemas de Información Integrados (ARIS). Como tal, constituye la técnica central para el modelado en ARIS, que sirve para vincular las diferentes vistas en la denominada vista de control. Citando una publicación de 2006 sobre cadenas de procesos basadas en eventos: ^{[ 3 ]}

Una cadena de procesos orientada a eventos (EPC) es un grafo ordenado de eventos y funciones. Proporciona diversos conectores que permiten la ejecución alternativa y paralela de procesos. Además, se define mediante el uso de operadores lógicos como OR, AND y XOR. Una de las principales ventajas de la EPC es su simplicidad y notación fácil de entender, lo que la convierte en una técnica ampliamente aceptada para representar procesos de negocio.

La afirmación de que las cadenas de procesos controladas por eventos son grafos ordenados también se encuentra en otros grafos dirigidos para los que no se proporciona un ordenamiento explícito de los nodos. En realidad, no parecen existir restricciones sobre la posible estructura de las EPC, pero las estructuras no triviales que implican paralelismo tienen una semántica de ejecución mal definida; en este sentido, se asemejan a los diagramas de actividad UML .

Several scientific articles are devoted to providing well-defined execution semantics for general event-driven process chains.^[4][5] One particular issue is that EPCs require non-local semantics,^[6] i.e., the execution behavior of a particular node within an EPC may depend on the state of other parts of the EPC, arbitrarily far away.

These elements are used in event-driven process chain diagrams:

Event

Events are passive elements in event-driven process chains. They describe under what circumstances a function or a process works or which state a function or a process results in. Examples of events are "requirement captured", "material in stock", etc. In the EPC graph an event is represented as hexagon. In general, an EPC diagram must start with an event and end with an event.

Function

Functions are active elements in an EPC. They model the tasks or activities within the company. Functions describe transformations from an initial state to a resulting state. If different resulting states can occur, the selection of the respective resulting state can be modeled explicitly as a decision function using logical connectors. Functions can be refined into another EPC. In this case it is called a hierarchical function. Examples of functions are "capture requirement", "check material in stock", etc. In the event-driven process chain graph a function is represented as rounded rectangle.

Process owner

Process owner is responsible for a function (i.e. a booking clerk is responsible for booking journeys). The process owner is usually part of an organization unit (i.e. a booking clerk belongs to the booking department). It is represented as a square with a vertical line.

Organization unit

Organization units determine which organization within the structure of an enterprise is responsible for a specific function. Examples are "sales department", "procurement department", etc. It is represented as an ellipse with a vertical line.

Information, material, or resource object

In the event-driven process chain, the information, material, or resource objects portray objects in the real world, for example business objects, entities, etc., which can be input data serving as the basis for a function, or output data produced by a function. Examples are "material", "order", etc. In the EPC graph such an object is represented as rectangle.

Logical connector

In the event-driven process chain the logical relationships between elements in the control flow, that is, events and functions are described by logical connectors. With the help of logical connectors it is possible to split the control flow from one flow to two or more flows and to synchronize the control flow from two or more flows to one flow.

Logical relationships

There are three kinds of logical relationships defined in event-driven process chains:

• Branch/Merge: Branch and merge correspond to making decision of which path to choose among several control flows. A branch may have one incoming control flow and two or more outgoing control flows. When the condition is fulfilled, a branch activates exactly only one of the outgoing control flows and deactivates the others. The counterpart of a branch is a merge. A merge may have two or more incoming flows and one outgoing control flow. A merge synchronizes an activated and the deactivated alternatives. The control will then be passed to the next element after the merge. A branch in the EPC is represented by an opening XOR, whereas a merge is represented as a closing XOR connectors.

• Fork/Join : Fork and join correspond to activating all paths in the control flow concurrently. A fork may have one incoming control flow and two or more outgoing control flows. When the condition is fulfilled, a fork activates all of the outgoing control flows in parallel. A join may have two or more incoming control flows and one outgoing control flow. A join synchronizes all activated incoming control flows. In the Event-driven Process Chain diagram how the concurrency achieved is not a matter. In reality the concurrency can be achieved by true parallelism or by virtual concurrency achieved by interleaving. A fork in the EPC is represented by an opening 'AND', whereas a join is represented as a closing 'AND' connectors.
• OR : An 'OR' relationship corresponds to activating one or more paths among control flows. An opening 'OR' connector may have one incoming control flow and two or more outgoing control flows. When the condition is fulfilled, an opening 'OR' connector activates one or more control flows and deactivates the rest of them. The counterpart of this is the closing 'OR' connector. When at least one of the incoming control flows is activated, the closing 'OR' connector will pass the control to the next element after it.

Control flow

A control flow connects events with functions, process paths, or logical connectors creating chronological sequence and logical interdependencies between them. A control flow is represented as a dashed arrow.

Information flow

Information flows show the connection between functions and input or output data, upon which the function reads changes or writes.

Organization unit assignment

Organization unit assignments show the connection between an organization unit and the function it is responsible for.

Process path

Las rutas de proceso sirven como ayuda para la navegación en el diagrama EPC. Muestran la conexión desde o hacia otros procesos. La ruta de proceso se representa como un símbolo compuesto formado por un símbolo de función superpuesto a un símbolo de evento. Para utilizar el símbolo de ruta de proceso en un diagrama de cadena de procesos impulsado por eventos, se conecta un símbolo al símbolo de ruta de proceso, lo que indica que el proceso diagramado incorpora la totalidad de un segundo proceso que, para simplificar el diagrama, se representa con un solo símbolo.

Como se muestra en el ejemplo, la recepción de un pedido de cliente es el evento inicial que genera una captura de requerimiento dentro de la empresa. Para especificar esta función, el departamento de ventas es responsable del marketing, la moneda, etc. Como resultado, el evento "captura de requerimiento" da lugar a una nueva función: verificar el material en stock para fabricar los productos.

Todos los datos de entrada y salida sobre el material permanecen en el repositorio de información. Tras verificar el material, pueden ocurrir dos eventos: si hay material en stock o no. Si hay material en stock, se toma del stock; si no, se solicita a los proveedores. Dado que ambas situaciones no pueden ocurrir simultáneamente, la operación XOR es el conector adecuado para vincularlas.

Si bien un proceso real puede incluir varias etapas hasta su finalización, las actividades principales se mantienen similares. Un evento desencadena una función, y una función conduce a un evento. Asimismo, un evento puede implicar uno o más procesos para su cumplimiento, pero cada proceso es único para un evento; lo mismo ocurre con el proceso y su ruta.

En cuanto a la función, sus datos pueden estar incluidos en uno o más recursos de información, mientras que la unidad organizativa solo es responsable de una función específica.

• BPMN
• DRAGÓN
• Diagrama de flujo
• Red de Petri
• minería de procesos
• Carril de natación
• Flujo de trabajo
• Diagrama de cadena de eventos
• Diagrama de bloques de flujo funcional

• Cadenas de procesos basadas en eventos para mejores flujos