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

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.