Ejemplo de BPMN 2 - "BPMN 2.0 by Example" - Interacciones

Proceso de compra de pizza sobre un modelo de colaboración

Este ejemplo muestra un modelo de colaboración que describe la interacción entre un cliente y una pizzería. En este proceso, el cliente y los trabajadores de la pizzería son calificados como participantes y se les ha asignado un pools a cada uno, usted podría ampliar las interacciones adicionando participantes como departamentos, equipos, sistemas e incluso trabajadores individuales de la pizzería. Es decisión del modelador incluir mayores detalles.

Si analizamos el siguiente diagrama, el proceso comienza mediante un evento de inicio que indica que el cliente tiene el estomago gruñendo, es decir tiene hambre. El cliente seleccionada un pizza y la ordena. Después de eso el cliente espera que su pizza este horneada  y embalada para posteriormente llevarla a su casa (“La familia le espera!!!”).

En el proceso existe un Gateway de evento que describe que el cliente puede recibir dos eventos que podrían suceder: le entregan su pizza o hay una tardanza de 60 minutos en la entrega. Después de 60 minutos el cliente molesto pregunta por su pizza llamando al empleado que lo atendió. En este escenario el empleado le indica que en breve le será entregada su pizza, y este vuelve a esperar 60 minutos más. Estas actividades se realizan así sucesivamente.

En este ejemplo, se puede observar objetos de información como la orden de pizza y objetos físicos como la pizza o el dinero, esto se puede hacer porque los objetos físicos actúan como objetos de información inherentes. Cuando la pizza llega a las manos de cliente esto se reconocerá como una llegada de un mensaje, por lo tanto sabemos que la pizza está disponible, que es exactamente el propósito de un evento intermedio de mensaje. Por su puesto este modelo no está destinado a ser ejecutado por un motor de procesos.

Ejemplo de BPMN 2 - "BPMN 2.0 by Example"

Este es el primer post de una serie de artículos donde describo ejemplos de BPMN 2.0 para impulsar la comprensión de sus nuevas características. Estos artículos corresponden a "BPMN 2.0 by Example" desarrollado por el Object Management Group, Inc. (OMG).

Este proceso "Compra de hardware" tiene como objeto describir las actividades que una empresa debe realizar antes de enviar la mercancía solicitada a un cliente. En este ejemplo, solo se utiliza un pool y diferentes lanes para describir las actividades involucradas en este proceso, no existe una comunicación directa entre personas; y se supone que se comunican de alguna forma. Si contáramos con un motor de procesos este sería el encargado de asignar las tareas a las personas. Si se requiere automatizar el proceso es necesario desarrollar un diagrama de colaboración, el cual veremos en próximos post.

El evento de inicio “listo para comprar”, indica que la preparación de la mercancía puede ser iniciada para responder a la solicitud de un cliente. Posteriormente, se describen dos actividades que pueden ser ejecutadas en paralelo: mientras el analista establece si el tipo de envió es normal o es una compra especial (los criterios necesarios no se definen en el proceso), el empleado del departamento puede ir empaquetando los artículos o la mercancía. Posteriormente, existe un Gateway exclusivo “modo de entrega”. Este Gateway es un buen ejemplo para explicar el uso recomendado de este artefacto. Este Gateway no es el responsable de  la decisión: Se trata de un envió especial o un envió normal?, en su lugar, esta decisión se lleva a cabo en la actividad anterior. La puerta de enlace sólo funciona como un router, que se basa en el resultado de la tarea anterior y solo ofrece caminos alternativos que pueden ser utilizados por el flujo del proceso. En resumen, una tarea representa una unidad de trabajo, mientras que una puerta de enlace se utiliza solo para encaminar el flujo. 

En una puerta de enlace solo una de las ramas puede ser recorrida. Si se requiere un envió especial, el analista ubica una compañía para el transporte, asigna un vehículo y prepara el papeleo, si por el contrario el envió es normal, este debe comprobar si es necesario la utilización de un seguro; en este caso el gerente de logística asigna un seguro. En cualquier caso es necesario llenar un formulario con el sello postal para el envió. Para este escenario un Gateway inclusivo puede ser utilizado ya que una o más ramas pueden ser recorridas por el flujo del proceso. En este caso una rama siempre se toma, mientras que la otra solo si el seguro es necesario, ambas actividades pueden ser ejecutadas en paralelo. Debido a esta paralelismo se requiere un Gateway para sincronizar detrás de las actividades “llenar etiqueta”, “asignar seguro”. En este escenario la puerta de enlace inclusiva siempre espera que se llene la etiqueta ("sello postal"). Si un seguro es adicional, la puerta de enlace debe esperar la asignación de un seguro. De igual forma se requiere un Gateway para sincronizar antes de la tarea crear paquete y llevar a la zona.

En este ejemplo, describe diversas condiciones que muestran como modelar actividades que pueden ser desarrolladas en paralelo,y la utilización de gateways.