Ejemplo de BPMN 2 - "BPMN 2.0 by Example" – Ejemplo de Colaboración Detallado

En este ejemplo podemos observar un diagrama de colaboración más completo que en el post anterior; por ejemplo se puede observar la conversación entre el gestor de cuenta y el cliente VIP para solventar su problema o la conversación entre un analista de segundo nivel de soporte y la fábrica de software para apertura un caso o ticket de una incidencia que se perfila como técnica o el establecimiento de un nuevo “Fix” que podría incluirse en el próximo release.

En este diagrama se puede observar que cada una de las tareas se ha establecido manual, por ende, no existen actividades que puedan ser ejecutadas en un motor de procesos. Este diagrama corresponde a un nivel que describe las actividades sin incorporar tareas automatizadas como la invocación de servicios, reglas de negocio o scripts, entre otros.

En el próximo post veremos cómo este diagrama puede describirse mediante un modelo de coreografía.

Ejemplo de BPMN 2 - "BPMN 2.0 by Example" - Colaboración

En este post quiero mostrarles las diferentes perspectivas que puede existir sobre un mismo proceso usando la notación grafica BPMN. En este ejemplo, se muestra un proceso simple de alto nivel para la gestión de incidencias. Más adelante en los próximos post perfeccionaremos este modelo al pasar de orquestación a la colaboración y coreografía.

El proceso anexo describe la gestión de incidentes manejado por una empresa que desarrolla software. Este proceso es disparado cuando un cliente solicita ayuda a su gestor de cuenta para resolver un problema en un producto. En primer lugar el gestor de cuenta trata de resolver la incidencia si es posible explicándole al cliente. Si el gestor de cuenta no puede resolver la incidencia, este lo asigna a un analista de soporte de primer nivel que solicitara apoyo a un analista de soporte de 2do nivel si este no lo puede resolver. El analista de soporte de segundo nivel debe averiguar si el cliente puede solucionar mediante una actualización (“fix”) el problema por su cuenta, si el analista no está seguro que esta solución puede solucionar la incidencia, este pedirá ayuda directamente a un desarrollador de software. En cualquiera de los casos el gestor de cuenta le explicara la solución al cliente.

Este diagrama es realmente una representación simple del proceso, es decir; un “camino feliz” donde se asume que siempre se encontrara una solución a la incidencia reportada por un cliente. Este modelo no incorpora detalles de colaboración entre los empleados involucrados y se abstrae de las tareas e información que son ejecutados por un motor de procesos. El diagrama es útil para obtener una comprensión básica de los flujos y tareas principales, pero no; si se requiere profundizar en los detalles del proceso.

Nota: Este proceso ha sido modelado utilizando Signavio hhttp://www.signavio.com, un editor de procesos que soporta la especificación BPMN 2.0.

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

Proceso de compra de productos

Este proceso se inicia cuando recibe una solicitud (mensaje) de orden de compra para un producto,  comprobándose posteriormente si el producto solicitado está disponible. Si el producto está disponible se envía al cliente junto con un acuerdo financiero, el cual esta descrito como un subproceso.

Si el articulo no está disponible, se invoca un subproceso; que por cierto esta bordeado con una línea más gruesa. Esta característica indica que el subproceso es externo y será invocado o llamado por el proceso actual. El subproceso tiene dos eventos asociados que pueden ocurrir o ser generados por una tarea o subproceso interno. Estos eventos pueden  interrumpir o no el proceso. En este ejemplo, el subproceso puede generar internamente un evento de escalamiento que indica que existe un retrasó en la procura de un artículo, o un evento de excepción que provoca la interrupción del proceso. En resumen:

1. Cuando se utiliza in evento de escalamiento este no interrumpe la ejecución del proceso.
2. Cuando se utiliza un evento disparador de excepción, la ejecución de la actividad actual es inmediatamente abortada.

Proceso mantenimiento de disponibilidad de productos

En este grafico podemos ver un proceso para el mantenimiento de disponibilidad de productos, el cual es desencadenado o iniciado por un evento de inicio condicional. Esto significa que el proceso crea una instancia en caso que una condición exista o sea verdadera, en este ejemplo, la condición existe cuando el nivel de stock o disponibilidad de un producto está por debajo de un valor mínimo aceptable.

Con el fin de aumentar el nivel de stock de un producto determinado es necesario utilizar el mismo proceso de “Procura de Producto”. Al igual que en el proceso anterior, este proceso genera un evento de excepción de error para eliminar el artículo del catálogo cuando no es posible su procura. En este proceso no existe la necesidad de manejar un evento de escalamiento "retraso en la entrega".

Subproceso de “Procura de Producto”

Realizando un zoom al subproceso “procura de producto” el cual es utilizado en los procesos de compra y mantenimiento de disponibilidad de productos; vemos que contiene un evento de inicio normal, lo que indica que este subproceso no es desencadenado por un evento externo. La primera tarea de este proceso es la realización de procura de un producto a un proveedor. Si el proveedor no tiene disponible el producto este puede lanzar una evento de excepción a ambos procesos. En caso que la entrega del producto por parte de proveedor dure mas de 2 días se produce un evento de escalamiento que indica que la entrega tendrá retrasos.

Al igual que un evento de error, el evento de escalamiento dispone de un EscalationCode que es necesario para establecer la relación entre el productor y consumidor del evento. Es importante recalcar que cuando se genere el evento de escalamiento el proceso sigue su ejecución a la espera de la entrega del producto por parte del proveedor.