"BPMN by Example" - Un ejemplo complejo de BPMN 2.0 - E-MailVoting

Vuelvo a las andadas después de un corto tiempo por mucho trabajo. Entrando en materia!!!....

En este post se describe un ejemplo de un proceso de negocio modelado con BPMN que fue presentado en la especificación BPMN 1.0, pero se ha actualizado a la BPMN 2.0.

E-MailVotingExample

El proceso que se describe es el proceso que se utiliza actualmente para desarrollar la notación BPMN. Es un proceso para resolver temas de discusión o casos a través del voto realizado por correo electrónico. Este proceso es pequeño, pero bastante complejo y proporciona ejemplos de muchas de las características de BPMN 2.0, lo cual puede ayudarle a ilustrar procesos de negocios sencillos y poco comunes y aún así ser comprensibles. En las siguientes secciones aislaremos los segmentos del proceso colocando en relieve sus características principales.

El proceso está modelado sobre la perspectiva de un "Administrador de Listas de Problemas y Discusiones". A partir de ese punto de vista, los miembros del grupo de trabajo "Votantes" son considerados como participantes externos, los cuales se comunicarán con el proceso mediante mensajes (ver flujos de mensajes hacia el pool de miembros).

El Administrador revisa continuamente la lista y determina si existe algún problema. Si existe un problema,  este pasara el problema por un ciclo de discusión y votación. A continuación, una decisión debe ser tomada: si no hay problemas en la listas, el proceso termina para la semana; para luego ser retomado la semana siguiente.

Si hay problemas en la listas, el proceso continuará con el ciclo de discusión. El subproceso "Ciclo de Discusión o Debate" es la primera actividad después de la decisión "Esta listo el problema?". Este subproceso tiene dos flujos de entrada, uno de los cuales se origina en una decisión posterior partiendo de un loop; este es uno de cuatro (4) loops complejos que existen en el proceso. El contenido del subproceso "Ciclo de Discusión o debate" y sus actividades se describen a continuación.

Primer Subproceso

El subproceso "Ciclo de Discusión o Debate" se inicia con una tarea del administrador de la listas de problemas enviando un correo electrónico al grupo de trabajo con un conjunto de casos que han sido abiertos para el debate a través de una lista de mensajes.

Esta tarea envía un mensaje a un participante externo (los miembros del grupo de trabajo), el cual se ve en el subproceso "Ciclo de Discusión o Debate" Sub-Proceso. Básicamente, el grupo de trabajo discutirá los temas durante una semana proponiendo soluciones a problemas adicionales. Después de la primera tarea, tres path o rutas paralelas se desarrollan las cuales son sincronizadas luego por un gateway paralelo. Esto se muestra en la secuencia de flujos salientes de la actividad "Anunciar Tema de Discusion".

El camino paralelo superior de la figura se inicia con una tarea de larga duración “long-running Task”, "Moderar tema de discusión", que tiene un evento temporizador intermedio. Esta tarea en realidad nunca se completará con normalidad en este modelo, pero se verá interrumpida por el evento de temporizador intermedio “Timer Intermediate Event”.

El path medio paralelo contiene un evento intermedio y una tarea. Un evento temporizador intermedio utilizados en la mitad del path (no unidos a la frontera de una actividad) causará una demora o delay en el proceso. Este retraso se establece en 6 días. La actividad "Envio alerta de fin de plazo de discusion"seguirá enviando un mensaje a un miembro.

El path paralelo de la parte inferior contiene más de un objeto, en primer lugar esta un tarea donde el "Administrador de Listas de Problemas y Discusiones" chequea el calendario para ver si hay una conferencia telefónica esa semana. La salida de la tarea será una actualización de la variable "ConCall" (no visto), la cual podrá ser verdadera o falsa. Después de la tarea, se encuentra un Gateway exclusivo con dos puertas (“Gates”). El flujo por defecto "default" se conecta directamente con un Gateway Exclusivo. Un Gateway  exclusivo se utiliza en esta situación porque el siguiente objeto es un joining Parallel Gateway o gateway paralela de unión que se utiliza para sincronizar los tres (3) caminos o paths paralelos. Si la puerta de enlace (“merging Gateway”) no fuera utilizada y ambos sequencias de flujo conectadas al gataway paralelo, el proceso habría sido atrapado en la puerta de enlace paralelo y se tendría que esperar por un testigo (“Token”), es decir el arribo de cada una las secuencia de flujo de entrada (“incoming Sequence Flow”).

El flujo de secuencia “si” tiene una condición que comprueba el valor de la variable "ConCall" (establecida en la tarea anterior) para ver si se realizara una conferencia telefónica durante la semana. Si es así, el evento temporizador intermedio (“Timer Intermediate Event”) indica retraso, ya que todas las llamadas de conferencia del grupo de trabajo comenzará a las 9 am de jueves. La tarea para moderar la conferencia telefónica mostratara un retraso, la cual es seguida por una puerta de enlace “merging Gateway”.

Esta puerta de enlace espera por los tres paths para completar, antes que el proceso continue con la siguiente tarea, "Evaluar progreso de la discusión". El Administrador de Listas de Problemas y Discusiones examinará el estado de los temas y las discusiones durante la última semana y decidirá si las discusiones están finalizas. La variable "DiscussionOver" (no vista) se establece en TRUE o FALSE, dependiendo de esta evaluación. Si la variable se establece en FALSE, entonces todo el sub-proceso se repetirá, ya que se ha establecido un bucle y la condición del bucle será establecida por la variable "DiscussionOver".

El segundo sub-proceso

El sub-proceso "recopilar votos" es precedido por una tarea ejecutada por el gestor de listas de casos que envía un correo electrónico anunciando al grupo de trabajo y a los miembros votantes que existen temas para iniciar un proceso de votación. Desde esta tarea se envía un mensaje a un participante externo (los miembros del grupo de trabajo), un flujo de mensajes. Esta tarea es también un objetivo para uno de los lazos complejos “complex loops” en el proceso.

El sub-proceso "recopilar votos / Collect Votes " sigue la tarea, y es también un objetivo de una de las secuencia de flujo de bucle “looping Sequence Flow”. Este sub-proceso es básicamente un conjunto de tres (3) path paralelos que se extienden desde el principio hasta el final de Sub-Proceso. Además, hay un evento en el el sub-proceso de no interrupción que se utiliza para recibir los votos de los miembros votantes según van realizándose.

La primera rama del “fork leads” establecer una decisión que determina si se realizara o no una conferencia telefónica la cual tendrá lugar durante la próxima semana, después de que el calendario de Grupo de Trabajo se haya comprobado y establecido. Básicamente, si se hizo un llamada la semana pasada, entonces no habrá una llamada esa semana, y viceversa. Si no hay ninguna llamada, entonces un evento intermedio temporizador se establece para esperar hasta el próximo lunes, la ruta vuelve indefinidamente “path loops back”.La variable que es utilizada en  el Proceso "Ciclo de Discusión " será utilizada de nuevo.

Las segunda y tercera rama trabaja del mismo modo que las actividades similares en el subproceso "Ciclo de Discusión ", excepto que tendrá una duración de dos semanas. Sin embargo, dado que las ramas llevan a un evento final en lugar de una puerta de enlace paralela, un gateway exclusivo “merging Exclusive Gateway” no es necesario (la sincronización necesaria se llevará a cabo por el evento final).

El evento en el Sub-Proceso aceptara votos de los miembros durante las dos semanas que el sub-proceso"recoger votos / Collect Votes" sea ejecutado. La política del grupo de trabajo es que los miembros votantes pueden votar más de una vez sobre un tema, es decir, que pueden cambiar de opinión tantas veces como quieran a lo largo de las dos semanas. El evento de inicio del mensaje activa el funcionamiento del event Sub-Proceso. Es del tipo no-interrupción dado que votos múltiples pueden recogerse durante las dos semanas. Como parte de este, un flujo de mensajes entrantes va desde el pool "Miembros" al evento de inicio "Recibir voto". En el evento del sub-proceso dos tareas se desarrollan; en primer lugar, una tarea que prepara todos los resultados de la votación, y luego de una tarea que enviará los resultados a los miembros votantes.

El fin del proceso

La última sección del proceso incluye un complejo conjunto de decisiones y bucles. En primer lugar un conjunto de tareas preparará el resultado de la votación, enviándolas por correo electrónico a los miembros votantes, y publicados posteriormente en un sitio web. La primera decisión, "han votado suficientes miembros?", es necesaria ya que las dos terceras partes de los miembros votantes están obligados a aprobar cualquier solución a un problema. 

Si menos de dos tercios de los miembros han emitido votos, que sucede a veces, los problemas no se pueden resolver. La Decisión es seguida por otra decisión de dos alternativas. La alternativa "No" es seguida por la decisión. Si un miembro votante no realiza al menos un voto, se les advierte. Si se pierde en una segunda votación este pierde su condición de miembro de votación y los porcentajes de votación se vuelva a calcular a través de una tarea "Reducir el número de miembros con voto y Recalcular voto". 

Si todavía no se han advertido, a continuación, se envía una advertencia y el ciclo se repite nuevamente. Si todos los problemas se resuelven, entonces el proceso se lleva a cabo. Si no, entonces otra decisión es requerida. La votación se desarrolla en dos oportunidades antes de que se remonte a un nuevo ciclo de discusión. 

La primera vez se vera una reducción del número de soluciones a las dos más populares sobre la base de los votos (más si hay empates). Algunos miembros tendrán que cambiar su voto sólo porque su solución seleccionada no es válida. Estas dos actividades se encuentran en un proceso sin evento de inicio y fin utilizándose para crear un simple conjunto de actividades paralelas. Informalmente, esto se llama una "caja paralela". 

Para situaciones simples, se puede utilizar un conjunto de actividades paralelas sin el desorden extra de una gran cantidad de flujos de secuencia. En realidad, estas dos tareas no se puede hacer en paralelo, pero se utilizan en el modelo para poner de relieve el uso opcional de los eventos de inicio y finalización. Después de la caja paralela, va de nuevo al subproceso  "recoger votos". Si ya han pasado dos ciclos de votación, entonces el flujo del proceso retorna al subproceso "ciclo de decisión".

El proceso:

Saludos!!!