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;