10 Buenas Prácticas para Modelar Procesos en BPMN

Business Process Model & Notation (BPMN) es un estándar certificado ISO/IEC 19510:2013 (ISO/IEC, 2013). que ofrece una notación gráfica   para el modelado de un proceso de negocio, un metamodelo (la semántica de las definiciones de cada objeto y sus relaciones) y reglas de uso. El uso de BPMN facilita que todos los empleados de una organización tengan un lenguaje común y gráfico para comunicarse a través de los procesos de la organización.

Al utilizar una notación estándar,  cualquier empleado puede entender cada modelo de proceso de la organización, y así conocer las actividades a realizar, las responsabilidades de cada tarea y las interrelaciones entre todas las unidades funcionales que participan en un proceso transversal.  Las características de BPMN  crean un puente estandarizado entre el modelado lógico de procesos de negocio y la implementación de procesos (el modelado físico llevado a ejecución de procesos), gracias a los tres principales propósitos de BPMN: proporcionar una notación fácilmente comprensible por todos; dotar de semántica de ejecución formal y declarativa y ofrecer un formato de intercambio estándar de procesos.

Cuando se modela con Business Process Model & Notation (BPMN) es necesario crear modelos de procesos de negocio que sean:

• CORRECTOS – el diagrama BPMN no debe saltarse las reglas de la especificación BPMN, ni las reglas de estilo de la organización.
• CLAROS – la lógica del proceso no debe ser ambigua y no debe depender de la documentación adjunta al proceso para que sea entendible (solo usará Anotaciones de Texto para aclarar partes puntuales del proceso).
• COMPLETOS – el proceso o subproceso tendrá un único punto de inicio e incluirá todos los caminos posibles para contemplar todas las posibles casuísticas que puedan ocurrir y alcanzar los diferentes estados (eventos) finales.
• SENCILLOS – el diagrama de proceso o subproceso debería ocupar una página para facilitar su entendimiento e idealmente tener como máximo de 7 a 9 actividades o subprocesos por página. Y tres niveles de subprocesos como máximo. Los modelos con muchos elementos implican una mayor dificultad de entendimiento y de detectar posibles errores.

El arte de modelado de procesos en BPMN debe seguir fundamentalmente el siguiente decálogo de buenas prácticas:

1. Un flujo de secuencia no puede cruzar las fronteras de un contenedor (Pool), ni tampoco cruzar las fronteras de un subproceso, y siempre el subproceso comenzará en el evento de inicio del subproceso. Y el flujo de secuencia puede solo conectar una actividad, una compuerta, o un evento y los extremos tienen que estar conectados apropiadamente. Un flujo de mensaje no puede conectar “objetos” en el mismo contenedor y no puede conectarse desde una compuerta.
2. Se deben utilizar contenedores vacíos para representar a un Cliente o un proveedor o un participante externo a la organización, cuando se desee ver la comunicación existente. Aunque BPMN permite que un carril (lane) se divida en más carriles, no es una buena práctica dividir un carril en más carriles, ya que dificulta la comprensión del proceso.
3. Se debe modelar los procesos de forma jerárquica (divididos en subprocesos) para reducir el número de objetos representados en un modelo de proceso. Un proceso o subproceso sólo tiene un evento de inicio.
4. Cuando en un modelo exista un subproceso con dos salidas, siendo una de ellas la habitual (camino feliz), en lugar de utilizar una compuerta exclusiva a la salida del subproceso, se puede usar un evento frontera para la salida excepcional. Al colocar un evento frontera adjunto al subproceso, se permite que se muestre el camino feliz con mayor claridad y la excepción también.
5. Se utilizarán anotaciones de texto solo cuando sea necesario para hacer más clara la lógica del proceso que pudiera quedar ambigua. No se debe abusar de las anotaciones de texto para que quede un diagrama limpio. Si es recomendable usar anotaciones de texto en las compuertas que requieran explicación adicional a lo que indican las salidas de la compuerta.
6. Como regla general, no es recomendable usar objetos de datos para no recargar el diagrama con demasiada información. Solo se utilizarán de forma puntual cuando se interprete que es necesario para destacarlo y con el objetivo de explicar mejor el diagrama.
7. Se requiere un evento de fin diferente por cada estado fin diferente. Dos eventos de fin en un proceso no deberían tener el mismo nombre. Solo se usarán “Eventos Fin Terminación Inmediata” cuando se quiera finalizar un proceso o subproceso inmediatamente. En el resto de los casos se debe utilizar los “Eventos de Fin Simple” de instancia de un proceso o subproceso para evitar posibles errores de terminación completa.
8. Evitar el uso de “Eventos de Tiempo” con datos específicos de fecha y hora que impidan la reusabilidad del modelo.
9. El modelo de proceso debe estar estructurado asegurando que todos los caminos abiertos con las compuertas paralelas (AND) estén sincronizados con las correspondientes compuertas paralelas de “convergencia”. Y es obligatorio utilizar las compuertas inclusivas (OR) de “convergencia” que sincronicen todos los posibles caminos abiertos.
10. No usar nunca flujo condicional, en su lugar usar compuertas. Y para tratar alternativas de capturas de eventos que ocurren en medio de un flujo, utilizar siempre compuertas basadas en eventos, en lugar de usar compuertas exclusivas o inclusivas basadas en la evaluación de expresiones usando datos del proceso.

El modelado de procesos en BPMN busca el entendimiento del proceso tanto por Negocio como por el departamento de TI. Siguiendo las reglas de la especificación del estándar, así como las buenas prácticas, nos aseguramos de detectar errores del proceso, y poder realizar una correcta validación del proceso por todas las partes interesadas.

Pedro Robledo

Team Leader ITSM4BPM

Comité de Estándares de itSMF España