Business Process Model and Notation o por sus siglas BPMN, es uno de los estándares más conocidos para el modelado y gestión de procesos de negocio, siendo de gran ayuda en las etapas de definición y alineación de productos de software. El objetivo de BPMN es proporcionar a todos los participantes del proceso de entrega, es decir, a los analistas de negocio, a los equipos de desarrollo y pruebas y a las partes interesadas en el producto, un conjunto unificado de elementos y notaciones fácil de usar y comprensible.

Una gestión de procesos de negocio eficiente en la entrega de productos de software es esencial para el éxito del producto en el mercado y para la colaboración entre la empresa proveedora y el cliente, relación mediada por el analista de negocio. Todos sabemos que los patrocinadores de los productos de software no están familiarizados con los términos técnicos de TI, lo que provoca varios problemas de comunicación entre ellos y los equipos de entrega. A fin de facilitar este proceso de comunicación y mejorar la calidad de los requisitos funcionales obtenidos, los procesos institucionales deben diseñarse de manera clara y significativa, utilizando un lenguaje de fácil comprensión y normalizado.

Para crear diagramas BPMN, se pueden utilizar herramientas como: MS Visio, Sparx Systems Enterprise Architect o soluciones gratuitas como BonitaSoft, Intalio o ProcessMaker.

Nota: Abiztar es proveedor autorizado de Sparxs Systems.  Si necesitas adquirir licencias de Enterprise Architect, favor de comunicarte con nosotros a contacto@abiztar.com.mx o al teléfono de la empresa. 

Algunas palabras sobre procesos y BPDs

Podemos definir un proceso de negocio como un conjunto de actividades de negocio realizadas por los participantes del negocio con el fin de alcanzar los objetivos esperados y generar valor. Estos procesos se pueden describir en tres niveles de detalle y BPMN los soporta a todos, es decir:

• Mapa del proceso - este es un diagrama de flujo simple
• Descripción del proceso - este es un diagrama de flujo mejorado con información adicional
• Modelo de proceso - es un diagrama de flujo ampliado con suficiente información para que el proceso pueda ser analizado, simulado y ejecutado utilizando el BPEL - Business Process Execution Language (Lenguaje de Ejecución de Procesos de Negocio).

En el análisis de negocios, los procesos - independientemente de su tipo (gestión, operación o soporte) deben ser modelados para beneficiarse de las siguientes ventajas:

• Entender - los procesos, si se dividen en actividades atómicas, pueden ser mejor comprendidos por todos los participantes en la entrega.
• Monitoreo y evaluación - los procesos, si se representan de manera inequívoca y concisa, pueden ser mejor monitoreados y evaluados, y ciertos Indicadores Clave de Desempeño (KPI) pueden ser fácilmente aplicados.
• Optimización - los procesos, si se dividen en actividades independientes e interconectadas, pueden enfatizar los cuellos de botella, los caminos duplicados, los caminos alternativos y los bucles, siendo buenos candidatos para las mejoras.
• Creación de nuevos procesos - los procesos, si se diseñan correctamente, reflejando el comportamiento del sistema tal y como está, se convierten en puntos de partida sólidos para potenciales solicitudes de cambio de producto o extensiones adicionales.
• Automatización - los procesos, si se representan paso a paso, pueden ser fácilmente automatizados, reduciendo los costos asociados con el desarrollo y las pruebas, mejorando la calidad del producto y optimizando las etapas de mantenimiento y soporte. También BPMN es fácilmente interpretable por las herramientas de BPEL.

Los diagramas proporcionados por BPMN, llamados BPDs - Business Process Diagrams son similares a los diagramas de actividad UML, pero son mucho más sugerentes y fáciles de seguir, tanto por usuarios técnicos como no técnicos, siendo también interpretables por las herramientas BPEL.

Para crear el BPD, el analista de negocios debe detectar y modelar el evento de inicio del proceso, que los otros eventos - en orden cronológico, y después, el evento de parada - el que cierra el proceso. Las decisiones de negocio y los caminos alternativos (sucursales) se presentan a través de pasarelas.

Si el proceso de negocio es complejo, se puede descomponer funcionalmente en subprocesos, cada uno de los cuales se representa en un BPD correspondiente, y luego los resultados obtenidos pueden ser interconectados, para obtener una visión general.

¿Por qué usar BPMN?

Ahora, vamos a resumir algunas de las ventajas de este estándar que viene a ayudar tanto a los clientes como a los analistas de negocio:

• Sencillez - Los elementos y notaciones que ofrece BPMN son intuitivos, sin necesidad de conocimientos técnicos previos. Por lo tanto, es fácil para el analista de negocios para crear diagramas BPMN, que son muy fácilmente aceptables por el lado del negocio.
• Expresividad - el estándar es extremadamente expresivo y adaptable con respecto al modelado de procesos, permitiendo una amplia gama de restricciones. A diferencia de otros estándares, como por ejemplo UML, BPMN es mucho más versátil y puede ejemplificar flujos de negocio mucho más sofisticados.
• Estandarización - BPMN es de OMG - Object Management Group gobernado y mantenido como un estándar.
• Aplicabilidad de la TI - teniendo en cuenta que la TI es un servicio horizontal vertical como los sectores financiero o bancario, surgió una necesidad significativa y en continua evolución de contar con soporte de TI. La mayoría de los procesos de negocio deben ser modelados de forma clara, elocuente e inequívoca, con el fin de garantizar una mayor calidad de la entrega y la satisfacción del cliente.

Elementos BPMN

Un modelo BPMN puede describirse como una sucesión de nodos, conectados por flujos paralelos o secuenciales. Para aplicar BPMN en el análisis de negocio, nosotros - los analistas - tenemos que conocer un conjunto de elementos clave utilizados para describir la mayoría de los procesos de negocio. En primer lugar, debemos ser conscientes de que existen cuatro clases de elementos, como se puede ver a continuación:

Objetos de flujo

• Actividades - son acciones que ocurren durante el proceso de negocio, y se representan gráficamente como rectángulos redondeados. Aquí podemos hablar de tareas, subprocesos y tareas en bucle.
• Eventos - son acciones que pueden iniciar un proceso, pueden ocurrir dentro de un proceso o pueden detener un proceso y se representan como círculos, el tipo de borde que determina el tipo de evento. En consecuencia, tenemos eventos de inicio - frontera simple, eventos intermedios - eventos de frontera doble y eventos de parada - frontera en negrita.
• Pasarelas - son elementos que describen las interacciones entre los flujos de proceso. Se aprecian puertas exclusivas, inclusivas, paralelas o complejas, representadas gráficamente con formas de diamantes...

Conectores

• Flujos de secuencia - representados por flechas con línea continua, indican la orden de actividad en un proceso empresarial.
• Flujos de mensajes - representados por flechas con una línea interrumpida, indican el intercambio de mensajes entre entidades en diferentes carriles de natación.
• Las asociaciones - representadas por flechas con una línea punteada, se emplean para asociar datos, información y artefactos a los objetos.

Carriles

• Pools - ayudan a agrupar las actividades de los participantes, en procesos de negocio interactivos.
• Los carriles - representan subdivisiones de un pool y se utilizan normalmente para resaltar las funciones implicadas en el proceso empresarial.

Artefactos

• Objetos de datos - presentan la forma en que se utilizan los datos y documentos en un proceso empresarial y definen los consumos y/o salidas de actividad. Los objetos pueden recibir "estados" que explican la forma en que se modifican los documentos durante el proceso.
• Grupos - señalan ciertas secciones de la BPD sin añadir restricciones de rendimiento. Se puede emplear para clasificar los elementos utilizados para la notificación y no obedecer las restricciones impuestas por las piscinas o los carriles.
• Anotaciones - proporcionan información adicional sobre un proceso empresarial y pueden conectarse a determinados objetos de datos por medio de asociaciones.

Buenas prácticas en el modelado con BPMN

Incluso si BPMN es flexible y no impone restricciones de diseño, se recomienda adoptar ciertas buenas prácticas establecidas por el equipo, departamento u organización, como:

• Las actividades de los "procesos empresariales" deben presentarse en orden cronológico de izquierda a derecha.
• Los procesos empresariales suelen comenzar con un evento desencadenante y continuar hasta que se obtienen los resultados empresariales.
• Las tareas y actividades de un proceso empresarial deben estar asociadas a roles relevantes para la empresa.
• Un patrón completo de un proceso empresarial debe presentar las formas en que se transfieren los objetos y los datos.
• Los procesos de negocio deben descomponerse jerárquicamente, describiendo los subprocesos siempre que sea posible.
• Se recomienda establecer y emplear convenciones de nomenclatura al modelar procesos de negocio, por ejemplo: i) los nombres de los elementos deben ser cortos y concisos; ii) la repetición de términos como "tarea" o "proceso" cuando se nombra una tarea o un proceso es redundante; iii) todas las actividades deben ser nombradas como verbos; iv) se debe aplicar un Camel Case cuando se nombran elementos complejos, compuesto de varias palabras -por ejemplo, "AbsenceRequest" (SolicitudDeAusencia) y no "AbsenceRequest" (SolicitudDeAusencia) o "Absencequest" (SolicitudAusente).
• Si el proceso de negocio evoluciona con el tiempo, se recomienda versionar los BPDs creados, para poder seguir los cambios.
  

Caso de estudio

A continuación presentaré un ejemplo sencillo para subrayar la aplicabilidad del análisis BPMN en un escenario de negocio específico, así como los pasos necesarios a seguir en la creación de la BPD.

Estudiemos el proceso mediante el cual un empleado de un departamento de TI solicita una ausencia y su gerente, después de una evaluación adecuada, aprueba o rechaza su solicitud. También tendremos en cuenta la situación en la que el gestor no responde a la solicitud en un intervalo de tiempo determinado, decidiendo el sistema seguir un camino alternativo para proporcionar al empleado respuestas automáticas en nombre del gestor.

En el escenario dado, en primer lugar tenemos que identificar los actores involucrados en el proceso, en particular el empleado, el gerente y el sistema.

En el segundo paso de nuestro análisis, tenemos que determinar el conjunto de acciones realizadas por cada uno de los tres roles, respectivamente:

• El empleado: realiza una solicitud de absentismo - actividad seguida de una notificación enviada a su jefe.
• El gestor: procesa la solicitud de absentismo del empleado, decidiendo si la aprueba o no. Ambos resultados de la decisión van acompañados de un mensaje de notificación que se envía al empleado.
• El sistema: ofrece un flujo alternativo en este proceso, consistente en el rechazo automatizado de la solicitud de absentismo, en caso de timeout - el gestor no responde a la solicitud en el plazo de un día - actividad que envía un mensaje al empleado.

En el tercer paso tenemos que decidir qué elementos utilizar para nuestro BPD, es decir, una piscina con dos carriles, uno para el empleado y otro para el gerente. Las acciones del sistema también se modelarán en el pool del administrador a medida que el sistema se haga pasar por él en la situación dada. También necesitaremos actividades, puertas de entrada y eventos de inicio, parada e intermediación. En cuanto a las conexiones, la secuencia y los flujos de mensajes deben ser apropiados.

Para el cuarto paso se comienza por posicionar los elementos BPMN requeridos en el BPD, y se obtiene el siguiente resultado: en el carril del empleado se pone el evento de inicio, la actividad de solicitud de ausencia, el evento intermedio de notificación al gerente de la solicitud de ausencia y el evento de parada.

En el carril del gerente tenemos el evento de inicio - expresado por la recepción de la notificación de la solicitud de ausencia del empleado, la actividad de procesamiento de ausencias, la puerta de entrada de decisiones por la cual se aprueba o rechaza la solicitud, ya sea que el resultado sea seguido por un evento intermedio de notificación al empleado, y desde ambos casos el flujo conduce al evento de parada.

En el carril del administrador, desde la actividad de procesamiento de solicitudes tenemos un evento de tiempo límite intermedio (su valor es de un día) tras su vencimiento se desencadena un evento intermedio de notificación de rechazo de solicitudes por parte del empleado, seguido del evento de parada.

Conclusiones

La existencia de un estándar para el modelado de procesos de negocio, accesible y conocido por los analistas de negocio, clientes y equipos técnicos es de gran ayuda no sólo en el análisis de negocio - como disciplina, sino también en todo el proceso de entrega, más aún cuando hablamos de un estándar fácil y directo que no requiere conocimientos técnicos previos. Los principales beneficios de BPMN están representados por la facilidad de entendimiento y comunicación de los procesos de negocio entre los participantes involucrados y la capacidad de los modelos resultantes para ser ejecutados por BPEL.