BPMN2 y las lineas de estado

Cuando modelamos procesos aveces es difícil establecer las etapas o fases que el proceso debe contener para describir y especificar un procesos; recordemos que los procesos deben ser modelados para evitar falta de interpretación, presencia de ambigüedades y mala comprensión. Una técnica útil para desarrollar una buena técnica de modelado es pensar en estados. Déjenme explicarles.

Cuando vamos a modelar un proceso, este tiene asociados productos o servicios intrínsecamente, sobre esta premisa utilizamos una técnica donde identificamos la linea de estados o fases por la cual pasa un producto y servicio,  antes de proceder a modelar. Las ventajas sobre esta aproximación son evidentes, dado que se mejora la alineación y vinculación de los procesos con sus productos asociados.

Si tenemos un documento o producto que pasa por diferentes estados, una opción es describir en primera instancia los estados; por ejemplo, un documento puede pasar por un estado de transcripción inicial, necesita ser revisado por un abogado, rechazado por un abogado, aprobado, registrado, entre otros; estos estados pueden ser perfectamente mapeados o vinculados a un participante dentro del proceso, con lo cual nuestro proceso tendrá mayor coherencia.

En el siguiente diagrama puede observarse la linea de estado identificada para un proceso y su proceso asociado.

bpmn2_linea_estado

Entre las recomendaciones:

1. Identifique los productos y servicios que serán generados por el proceso transversal.
2. Describa la linea de estado asociado a los productos y servicios.
3. Vincule cada estado con un participante dentro de su proceso.
4. Proceda a modelar.

Saludos;

Modelado de Procesos Nivel 2 con BPMN 2.0 - Gestión de Vacante

proceso_vacante_nivel2

En el posts anterior describimos un macroproceso denominado "Gestión de Vacante", que tenia como objeto mostrar los conceptos relacionados a los niveles de procesos conocidos como Nivel 1,2 y 3. En este post, podemos ver un proceso modelado bajo nivel 2; donde comenzamos a incluirse variantes y condiciones en el procesos. En el diagrama podemos observar la utilización de gateways de tipo de eventos para describir eventos que un participante debe esperar como condición para seguir su flujo de proceso.

Este proceso es iniciado mediante la ocurrencia de un evento denominado "ausencia de una vacante o puesto de trabajo en una unidad de la organización". Cuando se dispara el proceso, se publica de forma automática la vacante en facebook, linkedin y twitter; posteriormente las personas interesadas en ocupar el puesto de trabajo presentan su postulacion al cargo o vacante. Estas postulaciones son recibidas por la Unidad de Recursos Humanos, quien comprueba los requisitos de los postulantes, los seleccionan y luego se finaliza el proceso cuando el postulante firma su contrato.

Una vez que el departamento que requiere la contratación reporta la existencia de una vacante este puede esperar por la ocurrencia de dos eventos, el primero que Recursos Humanos este de acuerdo para proceder a elaborar una descripción del trabajo mas detallada o que se presente una solicitud para re-evaluar o aclarar la solicitud de contratación.  De igual forma, para finalizar la unidad de recursos humanos puede esperar por la ocurrencia de dos eventos, el primero una solicitud de corrección y la segunda una liberación de vacante.

Lo importante, es que podemos observar una clara diferencia entre el proceso modelado bajo nivel 1 (Una perspectiva estratégica) y le nivel 2 con un nivel mayor de profundidad.

Saludos;

Modelado de Procesos Nivel 1 con BPMN 2.0 - Gestión de Vacante

En los próximos posts abordaremos un macroproceso denominado "Gestión de Vacante", que tiene como objeto mostrar los conceptos relacionados a los niveles de procesos.

Cuando vamos a iniciar la actividad de descripción de un proceso, debemos comenzar con un modelo basado en una perspectiva estratégica, conocida como nivel 1. En este nivel, se describen los participantes, procesos y actividades generales desde el punto de vista analítico; es decir la historia general del proceso a grandes rasgos; este no debe  incluir variantes, errores o condiciones que describan un mayor nivel de profundidad. Este proceso es dirigido generalmente a gerentes, analistas o dueños de procesos para identificar los recursos asociados a un procesos especifico y la asignación de responsabilidades (tareas) a participantes; de igual forma se pueden incluir indicadores claves de desempeño y especificar sus características.

Este proceso representa el nivel 1 del macroproceso "Gestión de Vacante". Este proceso es iniciado mediante la ocurrencia de un evento denominado "ausencia de una vacante o puesto de trabajo en una unidad de la organización". Cuando se dispara el proceso, se publica de forma automática la vacante en facebook, linkedin y twitter; posteriormente las personas interesadas en ocupar el puesto de trabajo presentan su postulacion al cargo o vacante. Estas postulaciones son recibidas por la Unidad de Recursos Humanos, quien comprueba los requisitos de los postulantes, los seleccionan y luego se finaliza el proceso cuando el postulante firma su contrato.

Si pueden observar se podrían incluir mas detalle y condiciones, sin embargo en esencia un proceso de nivel 1, corresponde a la "historia feliz", la visión general. Como se describen actividades de forma general se utilizan subprocesos que posteriormente pueden ser detallados.

proceso_vacante_nivel1

Recomendaciones para modelar procesos mediante BPMN 2.0

Según Charles Box, autoridad en gestión de procesos afirma que: “Todos los modelos son erróneos, algunos son útiles”, lo cual describe en síntesis, la difícil situación en la que se encuentran los modeladores cuando describen los procesos en su organización. Generalmente las organizaciones asumen que siempre existe un modelo de proceso perfecto, sin embargo rara vez existe un único modelo correcto, en cambio; sí existen modelos de procesos inválidos. 

Sobre este análisis, comparto algunas recomendaciones que debemos tomar en cuenta cuando modelemos procesos de negoocio.

Recomendaciones para modelar procesos

1. Sustente las decisiones sobre que incluir y que no; en el modelo de proceso.
2. Modele el proceso con un nivel de profundidad y precisión adecuado.
3. Excluya los elementos que no aportan valor en la interpretación del proceso.
4. Modele el proceso pensado en la audiencia que lo va a interpretar.
5. Ningún modelo puede representar el todo de un proceso, represente selectivamente los aspectos más importantes del proceso.
6. El modelo de proceso debe ser exacto, describa el estado actual del negocio y no una noción parcial o errónea del mismo.
7. El modelo de proceso debe ser lo más simple y completo posible.
8. El proceso debe ser comprensible; se debe comprender y encontrar sentido al mismo.
9. Todos modelo de proceso en algunos aspectos son imprecisos, irrelevantes, erróneos y sensibles al paso del tiempo; por ende, deben ser mejorados de forma continua para mejorar su comprensión y valor.

Por lo antes expuesto, se puede afirmar que todos los modelos deben ser útiles, ese es su propósito, ellos deben representan selectivamente algunos elementos del mundo real.

prc_egreso

Redundancia en el modelado de procesos BPMN 2.0 - Mejor Practica

Desde hace algún tiempo he estado desarrollando actividades relacionadas con el modelado de procesos, específicamente identificando mejores practicas para garantizar el uso adecuado de la sintaxis y semántica de la notación gráfica BPMN 2.0 utilizada en modelos de procesos, evitando la pérdida de beneficios de estandarización, existencia de ambigüedades y malinterpretación de los procesos. En mi andar en esta área he podido revisar proyectos en diversos estados; identificando practicas, métodos y patrones de interés. En los próximos post estaré compartiendo con la comunidad patrones y mejores practicas en el uso de la notación gráfica.

Para comenzar con este nuevo ciclo, voy a conversar sobre la "redundancia" que generalmente se puede apreciar en muchos procesos modelados. Como siempre primero un ejemplo:

En el siguiente diagrama tenemos un un proceso donde un cliente registra una solicitud, la  envía a la unidad A para que sea evaluada: posteriormente la unidad A recibe la solicitud, la evalúa, luego le envía una notificación al cliente; este confirma la solicitud y se finaliza el proceso. Este proceso es bien explicito, sin embargo las actividades : "enviar solicitud", "recibir solicitud", "enviar notificación" y "recibir notificación" son redundantes explicitamente, dado que el intercambio de mensajes en ambos participantes ya representan el envió de algo y su posterior recepción; es decir este proceso podría ser representado en menos pasos o actividades; sin embargo no general malinterpretacion o ambigüedad, solo redundancia.

Este proceso podría ser modelado mediante el siguiente diagrama:

Este proceso podría describirse de la siguiente forma: El cliente registra una solicitud, posteriormente envía la solicitud a la unidad A, luego la unidad A recibe la solicitud y procede a evaluarla, posteriormente la unidad A elabora la notificación y la envía al cliente quien la recibe y la confirma.

Basado en esta descripción. ya el objeto de conexión o flujo "Mensaje" de forma explicita indica el envió y recepción de un mensaje, por ende es recomendable no describir en los procesos ambas actividades continuamente; una practica común y regular que he podido constatar; recuerden que este proceso puede ser interpretado por el modelador y el lector de forma coherente y sencilla.

Saludos;

Compensación en BPMN 2.0

Uno de los aspectos menos tratados cuando automatizamos procesos son las estrategias que podemos desarrollar cuando se presentan fallas durante la invocación de servicios o el manejo de transacciones. En los próximos post, describiré las estrategias y acciones que podemos desarrollar para gestionar estos aspectos. Hoy hablaremos sobre la compensación.

En BPMN 2.0 un evento de compensación se describe como la acción a una falla parcial de operación, la cual puede ser vinculada a una actividad que compense mediante una alternativa de solución a la falla. En el siguiente diagrama veremos un ejemplo para facilitar la comprensión de este concepto.

compensacion

Compensación

En este diagrama, se describe el proceso de empaquetado de un cereal marca ACME. La máquina seleccione un paquete de cereal, luego inserta una bolsa dentro del paquete, introduce las hojuelas de maíz en la bolsa y para finalizar cierre el paquete para su almacenado posterior. Durante este proceso, puede que el dispensador de hojuelas no funcione por fallas técnicas o que no existan hojuelas en el dispensador principal. 

Si se detecta durante la actividad “Introducir bolsa en paquete de cereal” que no existen hojuelas de maíz en el dispensador, se debe proceder a utilizar un dispensador manual mientras se surte de hojuelas el dispensador principal. Esta condición puede modelarse en BPMN 2.0 mediante la utilización de compensaciones.  Se puede observar que en la actividad se incluye un evento intermedio de compensación que dispara un evento hacia una actividad que utiliza una bandera o flag que indica que la actividad está destinada para propósitos de compensación. Otra condición que puede presentarse en una falla técnica del dispensador principal, en este escenario se dispara un evento de error y se lanza un evento de compensación para la utilización del dispensador manual de igual forma que en el caso anterior. 

Lo importante de este ejemplo es la clara diferenciación de un evento de compensación y error y como pueden ser modelados en un diagrama.

Saludos;

Un ejemplo completo de un proceso modelado en BPMN 2.0 con Signavio

Hace poco realice diversos talleres sobre las técnicas que deben ser utilizadas para especificar y modelar procesos de negocio utilizando la notación gráfica BPMN 2.0. En dicho proceso genere una versión simplificada de un proceso para la gestión de quejas que puede ser una referencia sobre algunas practicas.

tratamientoQueja

En el diagrama anexo se puede observar:

1. Como utilizar los gateway de eventos para representar acuerdos de servicios, es decir tiempos acordados para el desarrollo de una tarea.
2. Como representar diversos tipos de mensajes utilizando un gateway exclusivo.
3. Como utilizar eventos intermedios para representar indicadores.
4. Como representar la gestión de mas de un evento de inicio en un pool.

Saludos;

https://editor.signavio.com/p/model/89738ac5f57942dfa8e8d4ad0f748012/png?inline&authkey=5260516c69d6a2ad8e2c7c24b4521cf66c4c6b6426f82f4b347ccbe3473972

BPMN 2.0 Utilización de Eventos en Subprocesos

BPMN 2.0 Utilización de Eventos en Subprocesos

En la notacion BPMN 2.0 se desarrollo la capacidad para gestionar eventos dentro de un subprocesos, en ingles "Event-Sub-Process" y "Collapsed Event-SubProcess". En el ejemplo anexo podemos observar un subproceso que ejecuta la actividad 1 y la actividad 2. Este subproceso tiene 4 eventos (Event-Sub-Process) asociados.

Un Event-Sub-Process puede ser colocado dentro de otro subproceso, y es activado cuando un evento es disparado; su principal característica es que puede interrumpir el contexto del subproceso o correr en paralelo, es decir no interrumpir el proceso. De forma similar un Collapsed Event-SubProcess establece el tipo de evento que podra disparar la logica interna del event-subproceso, el cual puede tener asociados un evento de message, timer, escalation, conditional, error, compensation, signal, multiple. Este tipo de evento puede cancelar la ejecución si "is interrupting" esta seteado; por el contrario este se ejecuta en paralelo. 

En el ejemplo, los primeros eventos en el subproceso incluyen un evento de inicio condicional y un evento de error intermedio que ejecutan las actividades A y B. Estos dos subprocesos puede interumpir el subproceso que los contiene; de igual forma 2 Collapsed Event-SubProcess que pueden interrumpir el proceso.

 

BPMN 2.0 Utilización de Eventos de Error

BPMN 2.0 Utilización de Eventos de Error

 En este post, podemos descubrir las técnicas que podemos aplicar para gestionar errores en los procesos que modelemos en BPMN 2.0.

En el ejemplo, se modela un proceso en donde un paciente se dirige a un Centro Asistencial para realizar un examen de sangre (análisis de muestra de sangre). En el proceso existe un analista que procede a extraer la sangre del paciente mediante una maquina que realiza el análisis de los componentes de la sangre en tiempo real. Durante este proceso no es común que la maquina presente problemas, sin embargo aveces ocurre. En la notacion BPMN podemos utilizar un evento intermedio de error para capturar errores. Otro error que no ocurre con frecuencia es que la maquina no pueda finalizar el examen de sangre.

En BPMN, podemos utilizar eventos de error intermedios para capturar los errores y posteriormente lanzarlos a los triggers que se encuentran en los limites del  subproceso expandido.

Como podemos observar en el proceso puede generarse dos errores, el primero una averia de la maquina que extrae la sangre del paciente y el análisis de la sangre no pudo ser finalizado. En el ejemplo estas dos excepciones son modeladas sobre un subproceso expandido. El subproceso puede lanzar dos errores. Estas errores pueden ser capturados luego en dos eventos de error intermedios ("Trigers") asociados al subproceso. En el diagrama podemos ver la utilización de eventos intermedios y de finalizacion de errores.

Por ultimo, cuando los eventos son capturados, se procede a solicitar la reparación del equipo o a resolver las inconsistencias en el análisis de la muestra de sangre. En el diagrama no incluyo participantes para simplificar su representación.

BPMN 2.0 Utilización de Eventos de Error

Utilización de Tareas En Serie en BPMN 2.0

BPMN 2.0 Tareas Secuenciales

Cuando modelamos procesos existen escenarios donde se requiere la creación de varias instancias de una actividad, la cual puede ser ejecutada en paralelo o en serie (una detrás de otra); por ejemplo la compra de varios artículos en un mercado, donde el operador registra cada articulo en la caja. Generalmente cuando tenemos un conjunto de actividades en bucle (loop) que requieren ser repetidas utilizamos una condición que se comprueba antes o después de cada iteración. BPMN 2.0, introdujo las tareas en serie o en paralelo, las cuales simplifican el modelado de este tipo de escenarios.

Como funcionan las actividades en Serie
Dentro de cada instancia de proceso, varias instancias de una actividad pueden ser creadas. El número necesario de instancias puede depender de una serie de factores como el tiempo de ejecución, su estado, la disponibilidad de recursos y la comunicación entre procesos. El numero de instancias se conoce antes que las instancias de la actividad sean creadas Una vez iniciada, las instancias son independientes una de la otra. Es necesario sincronizar las instancias al finalizar, antes que una actividad posterior se deba activar.

Ejemplo
En este proceso, tenemos dos participantes: operador1 y operador2. Cada uno realiza actividades similares, solo con la diferencia que el operador1 realiza un conjunto de actividades de forma secuencial utilizando la nueva notación para tareas secuenciales y el operador2 con el modelo tradicional con gateways. Ambos modelos son similares. El operador1 entrega los items de compra al operador2, este los recibe y los procesa, registrando informacion adicional en cada item; posteriormente el operador2 procesa cada item. Este ultimo es representado con el modelo tradicional (en rojo) utilizando bucles mediante gateways. Las notaciones gris y rojas son similares.

Con esta nueva representación se simplifica el comportamiento de bucle que se muestra en el diagrama con color rojo.

Saludos;

Un ejemplo de modelado de procesos mediante gateways de tipo evento

post001

Cuando modelamos un proceso, es imprescindible incluir en nuestro análisis la identificación y uso de eventos que puedan producir y consumir los participantes. En el diagrama anexo, podemos observar un proceso común de venta de productos, donde existe tres participantes: cliente, vendedor y proveedor. El cliente realiza la solicitud de compra de un producto a un vendedor, posteriormente; el vendedor solicita a un proveedor su entrega. La interacción entre el vendedor y el proveedor es representada mediante la utilización de un gateway tipo evento y 4 eventos intermedios.

1. En el primer evento (de arriba hacia abajo), se establece un acuerdo de servicio entre el vendedor y el proveedor para la entrega de un producto solicitado, el cual se representa con un timer intermedio. Este timer, por ejemplo; puede establecerse en 3 días.
2. El segundo evento intermedio de mensaje es activado cuando el proveedor efectivamente realiza la entrega del producto al vendedor.
3. El tercer evento intermedio de mensaje es utilizado para permitir un feeback entre el proveedor y vendedor en relación a acuerdos o acciones que sean necesarias para resolver incidencias que pueden presentarse durante el proceso de aprovisionamiento.
4. Por ultimo, un cuarto evento utilizado para recibir la factura del proveedor.

Cuando utilizamos un gatetway tipo evento, este lanza de forma paralela cada evento, el primero que reaccione determina que ruta o path sera utilizada por el proceso.

Algunas recomendaciones

1. Incorpore en su análisis la identificación de eventos.
2. Utilice un  gateway de evento para describir la producción o consumo de eventos. Por ejemplo, el evento timer puede disparar una notificación de incumplimiento de un SLA.
3. Si es necesario el establecimiento de un loop, utilice un gateway que reciba el mensaje, no lo dirija directamente al gateway de evento.

Saludos a todos;

"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!!!

"BPMN 2.0 by Example" - Un resumen sobre tipos de diagramas e intercambios

El propósito de este post es presentar un conjunto de ejemplos de diagramas de procesos utilizando la notación grafica BPMN 2.0. En ellos se muestran los principales tipos de diagramas e interacciones.

Subproceso Expandido:

Subproceso : En este ejemplo tenemos dos diagramas: El proceso y el subproceso asociados.

Utilización de múltiples lanes:

Ejemplo de un proceso sobre una colaboración vertical:

Ejemplo de un proceso de conversación

Ejemplo de un proceso de coreografía

Saludos;

"BPMN 2.0 by Example" – Travel Booking - Reserva de Viajes

El propósito de este post es proporcionar un ejemplo del manejo de eventos en línea  a través de eventos sub-proceso (event sub-process) en BPMN 2.0.

El escenario de Reservas de Viajes

TravelBooking

La agencia de viajes recibe una solicitud de reserva de viajes, incluyendo el transporte aéreo y la reserva de las habitaciones de hotel, por parte de un cliente. A raíz de la investigación y la evaluación de la disponibilidad de vuelos y habitaciones de hotel, las alternativas seleccionadas se colocan en un paquete y se ofrecen al cliente.

El cliente tiene 24 horas para seleccionar una propuesta alternativa o cancelar la solicitud. En caso de una cancelación, o después de este plazo, la agencia actualiza el registro del cliente para reflejar la solicitud de cancelación y el cliente es notificado. Cuando se realiza una selección, se le solicita al cliente que proporcione la información de su tarjeta de crédito. Una vez más, el cliente tiene 24 horas para proporcionar esta información o la solicitud se cancela a través de las mismas actividades mencionadas anteriormente (actualización y notificación).

Después de haber recibido la información de la tarjeta de crédito, se llevan a cabo las actividades de reserva: El vuelo y el hotel están reservados. Se toman las medidas para asegurar las inversiones de las reservas si se producen problemas en las actividades de reserva y pago. El cliente también tiene derecho a proporcionar a la Agencia modificaciones de la información de la tarjeta de crédito antes de que la reserva se haya completado. Dicha información se guardará en su registro.

Si surge un error durante las actividades de reserva, la reserva de vuelo y hotel son reversadas y el registro del cliente se actualiza. La reserva se intenta de nuevo, siempre y cuando el límite de reintentos de reserva no sea superado. Siguiendo la reserva de manera satisfactoria las reservaciones se cargarán en la tarjeta de crédito del cliente y el proceso se detiene después de la confirmación de éxito. Si ocurre un error durante esta actividad la reserva del vuelo y el hotel se reversan. Se le solicita al cliente nuevamente la información de su tarjeta de crédito y se intenta de nuevo realizar la reserva, siempre y cuando el proceso de pago no exceda el límite de reintentos. En ambos casos, tras el error, cuando el límite de reintentos se supera, el cliente es notificado y se detiene el proceso.

Aqui el proceso en una imagen:

Saludos;

"BPMN 2.0 by Example" – Nobel Prize Example - Proceso de Selección de Premio Nobel de Medicina

premioNovel

La selección de un Premio Nobel es un proceso largo y cuidadosamente ejecutado. Los procesos para cada uno de los 6 premios son muy similares. A continuación se presenta la descripción del proceso para la selección del Premio Nobel de Medicina. Los principales actores en el proceso de nominación, selección, aceptación y recepción del premio son:

• Comité del Premio Nobel de Medicina.
• Nominadores.
• Expertos especialmente designados para evaluar los trabajos de los nominados.
• Asamblea Nobel.
• Premios Nobel.

Cada año en el mes de septiembre, se gestionan unas 3.000 invitaciones o formularios confidenciales de nominación que son enviados por el Comité del Premio Nobel de Medicina a nominadores seleccionados. Los nominadores tienen la oportunidad de nominar a uno o más candidatos. Los formularios deben ser enviados al Comité del Premio Nobel de Medicina quien selecciona los candidatos preliminares.

El Comité del Premio Nobel de Medicina realiza una primera evaluación y selecciona a los candidatos preliminares. Después de esta selección, el Comité puede solicitar la asistencia de expertos. Si es así, este envía la lista con los candidatos preliminares a expertos especialmente designados con la solicitud de evaluar el trabajo de los candidatos. Al finalizar la asistencia de los expertos, se recomienda el candidato final y premios asociados.

El Comité del Premio Nobel de Medicina presenta el informe con recomendaciones a la Asamblea Nobel. El presente informe contiene la lista de los candidatos finalistas y sus obras asociadas. La Asamblea Nobel elige los Premios Nobel en Medicina a través de la mayoría de votos, los nombres de los ganadores del Premio Nobel y obras asociadas son anunciados posteriormente. La Asamblea Nobel se reúne dos veces para la selección, en la primera reunión de la Asamblea se discute el informe; en la segunda reunión los Premios Nobel en Medicina y obras asociadas son elegidos. La ceremonia de entrega del Premio Nobel Premio se celebrara en Estocolmo.

En este proceso podemos observar las diversas semánticas utilizadas para modelar el proceso, entre las cuales están el tipo de loop y la multiplicidad de un participante.

Saludos;

"BPMN 2.0 by Example" – Diagramas y Modelos

Modelos y Diagramas

El propósito de este post es mostrar algunos ejemplos sobre las relaciones existentes entre modelos, diagramas y algunos tips. Veremos cómo diferentes diagramas pueden ser representados sobre diferentes escenarios de serializacion.

Lanes 

Un proceso puede ser representado en un diagrama con o sin lanes. Ambas representaciones del proceso tienen diferencias en el modelo y diagrama. La principal diferencia entre las dos serializaciones es que uno tiene un nodo Xml llamado Laneset, mientras que el otro no. Aquí un ejemplo:

lanes

Pool

Los pools están presentes en diagramas de colaboración (colaboración, coreografía, conversaciones).  La introducción de un pool en un diagrama lo convierte en una representación de colaboración. Sobre la anterior premisa, el diagrama está incompleto dado que la colaboración debe realizarse entre dos o más participantes.

SubProceso expandido
En este ejemplo, el proceso “Gestión de Órdenes" contiene un subproceso llamado “Aprobar Orden” el cual es representado mediante un rectángulo expandido. En este escenario de modelado, se trata de un proceso único representado en un solo diagrama. Aquí un ejemplo:

SubProceso

Sub Procesos e invocación de Procesos
En esta sección, exploramos  el uso de subprocesos (expandir y contraer), junto con el llamado de procesos, sus diferencias y como su contenido puede ser representado en diagramas.

En este ejemplo el proceso “Gestión de Ordenes" presenta un subproceso llamado “Aprobar Orden”.  Este subproceso esta contenido en un diagrama separado. En este ejemplo, el subproceso es representado en dos diagramas, el diagrama padre y el diagrama de subproceso. Es importante destacar que ambas representaciones expandir y contraer son variaciones visuales del mismo "Gestión de Órdenes".

SubProceso2

Aprobar Orden

Invocación de Proceso
En este ejemplo estamos introduciendo el concepto de re-uso de procesos (“Process re-use”). En este caso, "Aprobar Orden"no es un subproceso del proceso “Gestion de Ordenes”, sino un proceso separado e independiente que puede ser invocado (reutilizado) dentro del proceso. Tenemos así dos procesos independientes. Aqui un ejemplo:

InvocarProceso

En el próximo post, estaré compartiendo con la comunidad ejemplos completos de procesos modelados en BPMN 2.

"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.