¿Qué es BPMN?

BPMN es una notación para procesos de negocio: el orden en que ocurren las cosas, quién las hace y qué las ramifica. Es un estándar de OMG, el mismo organismo que posee UML, y la versión 2.0 es la que significa todo lo que dice BPMN.

Su objetivo de diseño es inusual y conviene decirlo sin rodeos: pretende ser legible por el negocio y ejecutable por un motor. El mismo diagrama que un responsable de operaciones corrige en un taller puede, con suficiente detalle rellenado, desplegarse en un motor de procesos y ejecutarse. Ninguna otra notación de procesos intenta ambas cosas en serio.

Ese doble propósito explica el tamaño del juego de símbolos. BPMN tiene alrededor de cien símbolos, lo que suena alarmante y no lo es: son cinco familias con variaciones, y un diagrama que use veinte cubre casi cualquier proceso que alguien dibuje.

La familia a la que pertenece un símbolo siempre se ve por su contorno: círculo, rectángulo redondeado, rombo. La variación dentro de una familia siempre es un marcador interior o un grosor de borde. Esa regularidad es lo que hace aprendibles cien símbolos: aprendes cinco formas y un juego de adornos, no cien dibujos.

Esta es la regla que separa un diagrama BPMN de un diagrama de flujo con las esquinas redondeadas: un flujo de secuencia nunca puede cruzar la frontera de un pool. Un pool es un participante independiente con su propio proceso, y tú no decides en qué orden hace su trabajo otra organización. Lo único que puedes decir es que le enviaste algo, y eso es un flujo de mensaje.

Dentro de un pool, los carrilessubdividen el trabajo por rol, departamento o sistema. No llevan semántica de ejecución alguna - un motor los ignora por completo - y aun así son lo más valioso de muchos diagramas, porque "quién hace este paso" es la pregunta sobre la que un taller de procesos discute de verdad.

Una disciplina útil: cada cruce de carril es una entrega, y cada entrega es un sitio donde el trabajo espera. Contar los flujos de secuencia que cruzan una frontera de carril te da una primera lista de dónde el proceso es lento, antes de que nadie mida nada.

Casi toda discusión sobre "cuánto BPMN es demasiado" se disuelve en cuanto nombras cuál de estos tres estás haciendo.

El error no es elegir el nivel equivocado, es mezclarlos en un mismo diagrama. Un modelo descriptive con tres eventos de frontera de error totalmente especificados y once tareas desnudas no contenta a nadie: demasiado detallado para hojearlo, demasiado incompleto para ejecutarlo.

Un diagrama de actividad UML cubre terreno parecido y es mejor dentro de un sistema: tiene construcciones de flujo de control más ricas y encaja de forma natural junto a los demás diagramas UML que describen el mismo software. BPMN gana en cuanto hay más de una organización implicada, porque los pools y los flujos de mensaje no tienen en UML un equivalente que un público de negocio vaya a leer.

ArchiMate también sabe dibujar un proceso de negocio, y debería: una caja por proceso, en una vista de paisaje. En el momento en que quieres saber qué pasa cuando el pago falla, esa es la pregunta de BPMN, no la de ArchiMate.

1. Flujo de secuencia cruzando la frontera de un pool. El error más común con diferencia, y significa que el diagrama se arroga autoridad sobre el proceso de otro.
2. Ningún evento de fin. Todo camino debe terminar en uno. Una tarea colgando deja vivo para siempre un token de proceso, que es un fallo real una vez ejecutado el modelo y una ambigüedad real antes.
3. Decisiones dibujadas dentro de las tareas.Una tarea que "comprueba y encamina" esconde la ramificación. Pon una compuerta después.
4. Compuertas que ramifican y unen a la vez. Legal, ilegible. Usa una para separar y otra para unir.
5. Carriles con nombres de personas. Nombra el rol. La gente cambia de puesto y el diagrama no debería necesitar edición por ello.