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