"BPMN 2.0 by Example" – Flujo de Control gestionado por Humanos vs Sistemas

Flujo de Control gestionado por humanos vs por sistemas

En concordancia con el post anterior, si realizáramos un proyecto de automatización de procesos para la gestión de incidencias; tendríamos que identificar en primer lugar que partes del proceso podrían ser automatizadas dentro de un motor de procesos y que otras son actividades humanas.

En este escenario decidimos que el gestor de cuenta de un cliente no debe ser molestado con formularios web o listas de tareas, sólo debe enviar un correo electrónico si quiere informar o reportar un problema y recibir un correo electrónico cuando haya terminado el proceso de atención.

La misma idea se aplica para el proveedor de software: Se asumen que el agente de segundo nivel de soporte se encuentra en el mismo espacio físico que los desarrolladores. Tal vez es más eficiente si el agente de soporte sólo se acerca a los desarrolladores y conversa sobre el tema, en lugar de jugar un tiempo de ping-pong para la asignación de tareas. Por lo tanto, queremos mantener esta parte del proceso de gestión de incidencias de forma manual, así: no existirá un motor de procesos para la colaboración entre el  segundo nivel de soporte y los desarrolladores de software.

Pero queremos que la asignación de tickets para el 1er y 2do nivel de soporte se realice mediante un sistema de gestión de tickets, que tomara el papel o rol del motor de procesos y por lo tanto es modelado en un pool. 

Este sistema de gestión de tickets puede recibir y analizar correos electrónicos enviados por el gestor de cuentas y abrir un ticket para este. Si el agente de primer nivel de soporte decide que este es un caso de 2 º nivel, lo hace documentando su decisión y completando la tarea asignada "Documentar resultado de incidencia". El sistema de gestión de tickets posteriormente enruta la entrada al agente segundo nivel de soporte. Cuando el agente ha terminado, este puede establecer que el error se solucionara en el siguiente lanzamiento de software (software release). 

A continuación, el sistema de "trouble ticket" invoca un servicio en el sistema de gestión de productos “product backlog system”, para adicionar una nueva característica, necesaria para corregir el error identificado.

La entrada no tendrá que ser insertada manualmente. Al final, el sistema de gestión de tickets enviará un correo electrónico al gestor de cuentas, que contiene los resultados de la gestión de incidentes, y cierra el ticket. El gestor de cuentas podrá explicar la solución al cliente basado en la información del ticket.

Por supuesto, esta manera de modelar los flujos de procesos dirigidos por acciones humanas o sistemas en un diagrama es sólo un ejemplo sobre el uso de modelos y enfoques basados en diagramas de colaboración.

Para finalizar, es importante entender que podemos modelar nuestros procesos con tareas manuales o automatizadas. Esto nos da la oportunidad de hablar con los analistas de negocio o gerente de TI sin sobrecargar los procesos con detalles técnicos; muchas veces demasiado complejos e imprecisos.

Ejemplo de BPMN 2 - "BPMN 2.0 by Example" – Ejemplo de Coreografía

Como vimos en el post anterior, un modelo de colaboración nos permite resumir la comunicación a través de la frontera de un participante. En este post abordamos un nuevo tipo de diagrama llamado Coreografía.

En este tipo de diagrama, solo se describen las comunicaciones entre los participantes del proceso (“Quien con Quien y Que”), ocultando todas las actividades internas. La comunicación es descrita mediante un conjunto de intercambios de mensajes los cuales están relacionados lógicamente y están vinculados a través de grupos de enlaces-conversación.

La coreografía representa la interacción entre dos participantes del proceso, distinguiéndose si un participante está iniciando la comunicación (parte activa) o si la está recibiendo (parte pasiva). El participante que inicia se especifica por encima o por debajo de la tarea, la tarea en blanco es quien la inicia y la gris quien recibe.

El ejemplo anexo, es una representación del proceso del post anterior basado en coreografía.

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.

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.