La mayoría de las decisiones sobre documentación de procesos no son realmente decisiones. Alguien abre Lucidchart, dibuja cajas y flechas, y da el trabajo por terminado. Luego el proceso se entrega a ingeniería. Después, cumplimiento pregunta quién es responsable del paso 7. Luego alguien intenta conectarlo a una plataforma de automatización. Finalmente, el diagrama original se convierte en un artefacto histórico en el que nadie confía.
Ahí es donde realmente comienza la cuestión de BPMN vs. diagrama de flujo: no en un debate sobre metodologías, sino en el momento en que un diagrama simple deja de ser suficiente y nadie lo previó.
Lo que los equipos aprenden demasiado tarde
- BPMN es una notación estandarizada por ISO; un diagrama de flujo es un boceto informal. No son intercambiables cuando hay automatización o cumplimiento normativo de por medio.
- Elegir un diagrama de flujo para un proceso con varios roles no es mantener la simplicidad; es posponer una reconstrucción más costosa.
- Los diagramas BPMN 2.0 son ejecutables: los motores BPM pueden procesarlos, no solo leerlos.
- Los diagramas de carriles muestran visualmente la responsabilidad, pero no tienen un estándar de notación obligatorio; la mayoría de los equipos los confunden con BPMN.
- Los procesos empresariales simples funcionan perfectamente con diagramas de flujo; el problema es no saber dónde está el límite.
Qué es realmente un diagrama de flujo (y dónde termina la definición)
Un diagrama de flujo es un diagrama de procesos de uso general que muestra pasos, decisiones y las conexiones entre ellos mediante formas geométricas y flechas. IBM lo describe como una representación visual de la secuencia de pasos y decisiones necesarias para completar un proceso. Esa definición es acertada y también explica el problema: «uso general» y «sin estándar obligatorio» son lo mismo dicho de dos formas distintas.
Un diagrama de flujo puede usar un rombo para una decisión o un rectángulo para un paso. O un círculo. O un hexágono, si a alguien le parecieron más atractivos los hexágonos esa semana. No hay un organismo rector que supervise el conjunto de símbolos. No existe un requisito de cumplimiento. Nada impide que un diagrama de flujo de datos, un boceto de proceso y un organigrama con carriles compartan la etiqueta de «diagrama de flujo».
Esa flexibilidad aporta un valor real para documentar rápidamente. También es la razón por la que los flujos dibujados de ese modo se vuelven ambiguos en cuanto más de un equipo los lee. La persona que dibujó el diagrama sabe qué significa cada forma. El desarrollador que lo recibe tres semanas después, no. Y el auditor de cumplimiento seis meses más tarde, definitivamente tampoco.
Los diagramas de flujo funcionan porque son rápidos de leer y no requieren formación. Dejan de funcionar cuando un proceso tiene varios responsables, excepciones importantes o necesita determinar el comportamiento real de un software. Llegado ese punto, la informalidad que los hacía sencillos se convierte en el coste.
Qué es un diagrama BPMN y por qué existe el estándar
Business Process Model and Notation, o BPMN, está definido por ISO/IEC 19510:2013, el estándar internacional publicado por Object Management Group. El objetivo de diseño era específico: ofrecer a los usuarios de negocio y a los equipos técnicos una notación compartida para que el mismo diagrama pudiera ser entendido tanto por quien diseñó el proceso como por el equipo que lo implementa en software. Sin traducciones necesarias ni brechas de interpretación.
Un diagrama BPMN es, técnicamente, un tipo de diagrama de flujo. Utiliza formas conectadas por líneas para mostrar el flujo del proceso. Pero mientras que un diagrama de flujo estándar permite elegir símbolos de manera informal y ad hoc, BPMN define un conjunto fijo de símbolos con una semántica específica y no negociable. Una compuerta en BPMN significa una cosa concreta. Un evento intermedio significa algo distinto de un evento de inicio. No se pueden sustituir las formas. La notación que define el estándar es precisamente el propósito del estándar.
Object Management Group desarrolló BPMN para resolver un patrón recurrente de fracaso: las organizaciones tenían diagramas de procesos que las personas de negocio podían leer pero los ingenieros no podían implementar, o especificaciones técnicas que los ingenieros podían construir pero el negocio no entendía. BPMN es una notación diseñada para cerrar esa brecha al ser lo suficientemente precisa para la implementación y lo bastante legible para las partes interesadas del negocio en un mismo documento.
Ese objetivo de diseño también explica por qué la adopción de BPMN creció junto con las plataformas BPM. El mercado de BPM se estima actualmente en 26.660 millones de USD y se prevé que alcance los 64.290 millones de USD en 2033, con una tasa de crecimiento anual compuesta del 13,4 %, lo que refleja que las organizaciones están dejando atrás la documentación informal de procesos para adoptar modelos capaces de impulsar la automatización y el cumplimiento normativo. BPMN es la notación que sustenta ese cambio.
BPMN 2.0: qué cambió y por qué esta es la versión importante
BPMN 1.2 era un estándar de documentación. Útil, pero no directamente ejecutable. BPMN 2.0 cambió esto de forma fundamental: introdujo semántica de ejecución, lo que significa que un diagrama de especificación BPMN 2.0 puede ser procesado por un motor BPM, no solo leído por una persona.
Un archivo XML de BPMN 2.0 contiene la definición del proceso en un formato legible por máquinas. Introdúzcalo en un motor compatible y el motor ejecutará el proceso, enruta las tareas, activa eventos y gestiona las compuertas según las reglas definidas en el diagrama. El modelo visual y la especificación ejecutable son el mismo artefacto. Esta alineación entre el lenguaje de ejecución de procesos empresariales y la notación del diagrama explica por qué BPMN 2.0 es la versión que los equipos implementan actualmente, en lugar de tratar los diagramas como algo separado del código.
La consecuencia práctica para los equipos que evalúan si usar BPMN es clara: si el proceso acabará ejecutándose en una plataforma BPM, BPMN 2.0 no solo es preferible, sino estructuralmente imprescindible.
Elementos de BPMN: los símbolos que más equipos interpretan mal
Los elementos de BPMN se organizan en cuatro categorías principales. Objetos de flujo: eventos (inicio, intermedios, fin, representados por círculos), actividades (tareas y subprocesos, rectangulares) y compuertas (puntos de decisión y ramificación, con forma de rombo). Objetos de conexión: flujos de secuencia, flujos de mensajes y asociaciones. Carriles: pools que representan participantes separados y lanes que los subdividen en roles. Artefactos: anotaciones y grupos que aportan contexto sin afectar a la lógica del flujo.
En mi experiencia, la forma BPMN que genera más confusión es la compuerta. Los usuarios de diagramas de flujo ven un rombo y lo interpretan como una decisión simple de sí/no. En BPMN, las compuertas tienen tipos: exclusiva (XOR), inclusiva (OR), paralela y basada en eventos. Cada una se comporta de forma diferente. Una compuerta exclusiva dirige a una única ruta. Una compuerta paralela activa todas las rutas simultáneamente. Usar una cuando se pretendía usar otra genera un diagrama de proceso que parece sensato, pero se ejecuta incorrectamente.
La segunda interpretación errónea más habitual: el círculo al inicio de un diagrama BPMN no es decorativo. Los eventos tienen una semántica definida: un evento temporizador se comporta de manera distinta que un evento de mensaje, que a su vez se comporta de manera distinta que un evento de error. Los equipos familiarizados únicamente con diagramas de flujo informales suelen omitir por completo los tipos de eventos y reemplazarlos por marcadores genéricos de inicio/fin, eliminando la información que la notación fue diseñada para capturar.
Un conjunto de símbolos sin semántica obligatoria no es BPMN. Es un diagrama de flujo con formas más redondeadas.
BPMN vs. diagrama de flujo: diferencias clave que realmente afectan a su trabajo
La siguiente comparación cubre los criterios de decisión que realmente importan al elegir entre ambos. No diferencias teóricas, sino las que se manifiestan cuando el diagrama debe cruzar el límite entre equipos o impulsar automatización real.
| Criterio | Diagrama de flujo | Diagrama BPMN |
|---|---|---|
| Estándar de notación | Ninguno: informal, sin estándar obligatorio | ISO/IEC 19510:2013, publicado por OMG |
| Conjunto de símbolos | Flexible, definido por el usuario | Símbolos y notación estándar BPMN fijos con semántica obligatoria |
| Compatibilidad con roles/carriles | Opcional, sin semántica definida | Pools y lanes estructurados con reglas formales de participación |
| Preparación para automatización | No: los diagramas no pueden ejecutarse directamente | Sí: los diagramas BPMN 2.0 pueden ser procesados por motores BPM |
| Curva de aprendizaje | Baja: legible sin formación | Moderada: los tipos de compuerta y la semántica de eventos requieren estudio |
| Mejor audiencia | Partes interesadas generales, procesos de un solo equipo | Equipos multifuncionales, analistas de negocio e implementadores técnicos conjuntamente |
| Adecuación a la complejidad | Procesos simples de una sola rama | Procesos con múltiples ramas, roles, excepciones o requisitos críticos de cumplimiento |
Conviene añadir una nota: el enfoque de comparar BPMN y diagramas de flujo puede llevar a los equipos a pensar que solo una opción es siempre correcta. Para procesos realmente simples y de un único rol, un diagrama de flujo es la opción predeterminada correcta. La tabla anterior muestra para qué está diseñada cada notación, no cuál es superior en abstracto.
Modelado de procesos con diagramas de flujo: dónde funcionan y dónde se doblan
Los diagramas de flujo tienen fortalezas reales. Son rápidos de crear, no exigen conocimientos especializados para leerse y comunican con claridad la lógica secuencial a cualquier audiencia. Un responsable de producto que esboza una nueva secuencia de incorporación, un responsable de soporte que documenta una ruta de clasificación o un fundador que describe un proceso de ventas a una nueva contratación: todas estas son situaciones en las que un diagrama de flujo gana de inmediato.
La definición de IBM lo fundamenta bien: los diagramas de flujo son herramientas de visualización de procesos diseñadas para hacer comprensibles las secuencias de eventos. Para la documentación y el análisis de procesos en contextos iniciales o de una sola disciplina, eso es suficiente.
Donde los diagramas de flujo se doblan: en cualquier proceso que cruce límites organizativos, implique ejecución paralela, gestione excepciones con lógica empresarial específica o deba servir como especificación para una implementación de software. En esos contextos, la informalidad que hace accesibles a los diagramas de flujo se convierte en la fuente de ambigüedad. Distintos lectores interpretan el mismo diagrama de manera diferente. Los desarrolladores plantean preguntas que el diagrama no puede responder. Los auditores de cumplimiento encuentran traspasos de responsabilidad que no están claramente asignados.
El diseño de procesos empresariales no es lo mismo que la documentación de procesos empresariales. Un diagrama de flujo puede documentar lo que sucede. Tiene dificultades para especificar lo que debe suceder, quién es responsable, en qué condiciones y qué ocurre cuando falla. Esa brecha importa más a medida que los procesos escalan.
Cuándo un diagrama de flujo es suficiente para procesos empresariales
Use un diagrama de flujo cuando: el proceso implique un único rol o equipo, la audiencia no conozca BPMN y aprenderlo ralentizaría todo, el diagrama sea un boceto interno en lugar de un artefacto de entrega, o el proceso tenga una ruta principal con decisiones simples de sí/no.
Condiciones específicas en las que un diagrama de flujo es la elección adecuada para procesos empresariales:
- Mapeo de procesos en etapa inicial: está capturando lo que sucede actualmente, no especificando lo que debe suceder; la claridad rápida supera a la precisión.
- Comunicación con partes interesadas no técnicas: la audiencia debe participar en la revisión del proceso, y la notación BPMN la excluiría en lugar de incluirla.
- Flujos de un único rol: una secuencia de actividades empresariales gestionada íntegramente por una persona o equipo, sin traspasos multifuncionales.
- Documentación interna rápida: el diagrama vive en Confluence, lo lee el equipo que creó el proceso y no impulsa automatización ni cumplimiento normativo.
Recurrir a BPMN cuando un diagrama de flujo de dos cajas comunicaría lo mismo es optimizar los procesos empresariales de la manera equivocada. No todos los procesos necesitan la notación completa. La pregunta es si la ausencia de esa notación creará problemas más adelante.
Lo que un diagrama de flujo no puede expresar y BPMN sí
Un diagrama de flujo estándar no tiene un mecanismo formal para flujos paralelos: rutas que se ejecutan simultáneamente en lugar de secuencialmente. Puede dibujar dos flechas saliendo de una misma caja, pero ninguna notación obliga a interpretar lo que significa. ¿Ambas reciben el control? ¿Se elige una de forma condicional? BPMN proporciona una compuerta paralela con semántica definida. El diagrama no deja lugar a ambigüedades.
Los tipos de eventos son otra brecha. Un proceso complejo puede pausarse mientras espera un mensaje de un sistema externo, activar una comprobación temporizada cada 24 horas o desencadenar un gestor de errores si algo específico falla. BPMN representa cada uno como tipos de eventos distintos, con formas y comportamientos diferentes. Un diagrama de flujo no puede expresarlos sin improvisar símbolos, y los símbolos improvisados crean el problema de interpretación que BPMN fue diseñado para eliminar.
El flujo de mensajes entre pools —mostrar la comunicación entre dos participantes organizativos separados— requiere notación BPMN formal. Un proceso abstracto muestra que el Sistema A envía datos al Sistema B en un paso específico, mediante un protocolo específico. Un diagrama de flujo estándar muestra que «la comunicación ocurre aquí» y deja todo lo demás a la interpretación del lector.
La compensación es un ejemplo práctico: si un proceso de varios pasos falla a mitad de camino, BPMN incluye un evento de compensación que activa una secuencia de reversión o deshacer. Un diagrama de flujo puede aproximarlo con cajas y flechas adicionales. Pero no existe una comprensión compartida de lo que esas cajas significan para otro lector, lo que implica que un proceso complejo descrito en un diagrama de flujo depende de que quien lo dibujó esté disponible para explicarlo.
Esa dependencia del autor original es donde comienzan la mayoría de los problemas de documentación de procesos.
🤔 Piense en esto:
Los equipos suelen comenzar con un diagrama de flujo porque «lo simple es más rápido», y seis meses después descubren que el proceso afecta a tres departamentos y debe superar una auditoría de cumplimiento. La reconstrucción de diagrama de flujo a BPMN no es acumulativa: es una reescritura, porque el diagrama de flujo nunca capturó la información que BPMN habría exigido desde el principio. El diagrama original no migra. Simplemente se descarta. «Empiece de forma simple» es un buen consejo para un proceso realmente simple. Para los procesos empresariales y flujos multifuncionales, es un coste diferido.
Cuándo usar BPMN: complejidad de procesos, BPM y preparación para automatización
Use BPMN cuando el proceso vaya a alguna parte. Cuando vaya a entregarse a un equipo de desarrollo, implementarse en una plataforma BPM, revisarse por cumplimiento normativo o ejecutarse mediante un motor de automatización. Object Management Group e ISO diseñaron el estándar específicamente para conectar a los equipos de negocio y técnicos: un diagrama que ambos grupos pueden leer sin necesitar un traductor entre ellos.
Condiciones en las que BPMN es la opción adecuada frente a un diagrama de flujo genérico:
Un proceso implica varios roles con una responsabilidad clara en pasos específicos. La estructura de pools y lanes de BPMN lo hace inequívoco. Un diagrama de flujo puede mostrar departamentos; BPMN formaliza quién inicia, quién recibe, quién decide y quién finaliza dentro de un mismo diagrama.
Procesos empresariales complejos con rutas de excepción y lógica de compensación. Cuando falla un pago, se rechaza una aprobación o se activa un temporizador porque no ocurrió una acción requerida, se necesita una semántica de eventos definida, no símbolos improvisados.
Documentación de cumplimiento y auditoría en industrias reguladas. Banca, seguros y sanidad necesitan demostrar no solo qué hace un proceso, sino quién responde por cada paso y qué ocurre cuando algo sale mal. Los diagramas de flujo no tienen suficiente formalidad. Veo esto constantemente en conversaciones de soporte con equipos de servicios financieros: el diagrama de flujo satisfacía a los equipos internos y luego fallaba en la primera auditoría externa.
Canalizaciones de automatización donde el diagrama impulsará la configuración de herramientas. Las plataformas de gestión de procesos empresariales, incluidas Camunda, Activiti y herramientas similares, aceptan XML de BPMN 2.0 como entrada ejecutable. Crear un diagrama de flujo y después «convertirlo» en automatización equivale, en la práctica, a construir el proceso dos veces.
Procesos que se entregan entre analistas de negocio e ingenieros. Los traspasos multifuncionales sin un estándar de notación compartido son el lugar donde se pierden los requisitos. BPMN crea la notación común que estandariza la lectura del mismo diagrama por parte de ambos grupos.
Se prevé que el mercado de BPA crezca de 15.300 millones de USD en 2025 a 33.400 millones de USD en 2032, una señal de que más organizaciones están tratando la automatización de procesos como infraestructura en lugar de como una solución temporal. A medida que la automatización se vuelve más central para la operación de un equipo, se multiplica el coste del modelado informal de procesos.
Un proceso de aprobación de gastos interdepartamental que abarque empleado, gerente y finanzas —con comprobaciones paralelas, enrutamiento basado en políticas y gestión de excepciones para casos límite— es una situación donde la estructura de BPMN se amortiza de inmediato. Por ejemplo, construir esto en Latenode como un flujo automatizado de varios pasos exige comprender qué rutas se activan simultáneamente, qué decisiones se dirigen a qué aprobador y qué sucede cuando un gasto no supera una comprobación de política. Un modelo BPMN ofrece esta estructura en un formato que una plataforma de automatización low-code puede implementar realmente.
Diagrama de carriles vs. BPMN: cómo encajan los pools y lanes
Un diagrama de carriles es una convención de diseño, no un estándar de notación. Organiza los pasos de un proceso en bandas horizontales o verticales, cada una de las cuales representa un rol, equipo o departamento. Es útil, legible y ampliamente utilizado. Pero el carril no tiene una definición formal de lo que esas bandas significan técnicamente. Pueden mostrarse dos o más entidades empresariales, pero el diagrama no define la naturaleza de su comunicación y colaboración, quién inicia, qué pasa de un carril a otro o cómo se estructura el traspaso.
BPMN define formalmente los pools como participantes principales de un proceso: entidades organizativas completamente separadas. Los lanes subdividen un pool en roles dentro de un participante. Los flujos de mensajes entre pools siguen reglas específicas. Los procesos empresariales privados dentro de un pool se distinguen explícitamente de las interfaces públicas que interactúan con otros participantes. La semántica está en el estándar, no en la interpretación del lector.
Veo esta confusión con frecuencia. Un equipo crea un diagrama de carriles, lo llama su «mapa de procesos BPMN» y lo envía a un equipo de implementación. El equipo de implementación pregunta cómo fluyen los mensajes entre sistemas. El diagrama de carriles no puede responder a esa pregunta. El resultado es una reunión en la que el equipo orientado al negocio explica qué quería decir, en lugar de que el diagrama hable por sí mismo.
Los carriles son valiosos. Son una elección de diseño. Trátelos como una herramienta de legibilidad dentro de un diagrama BPMN, no como un equivalente de BPMN.
BPMN y UML: por qué no pertenecen al mismo espacio de problemas
Si trabaja en contextos de software empresarial, tarde o temprano encontrará BPMN y UML (Lenguaje Unificado de Modelado) utilizados para documentar procesos o sistemas, a veces dentro del mismo proyecto. Se superponen visualmente en algunos aspectos: los diagramas de actividad de UML se parecen a los diagramas de flujo BPMN. Sin embargo, abordan problemas distintos.
UML modela el comportamiento del software: estructuras de clases, interacciones de objetos, estados del sistema y diagramas de secuencia para comunicaciones entre componentes. Es el lenguaje de especificación de cómo se construye internamente el software. BPMN modela procesos empresariales: qué sucede entre roles organizativos, cuándo se activan eventos y cómo se gestionan las excepciones en un contexto de flujo.
Decision Model and Notation (DMN) es el estándar complementario de BPMN para la lógica de decisiones. Si necesita formalizar reglas empresariales que alimentan las decisiones de un proceso, DMN es el complemento adecuado.
Confundir UML con BPMN en contextos empresariales suele producir diagramas técnicamente rigurosos, pero que describen el asunto equivocado. Un ingeniero de software al que se le pida leer un modelo BPMN y un analista de negocio al que se le pida leer un diagrama UML entenderán las formas, pero pasarán por alto la intención.
Cómo elegir entre BPMN y un diagrama de flujo: un marco práctico de decisión
Una pregunta que debe responder antes de abrir una herramienta de diagramación: ¿este proceso necesita leerse o necesita implementarse?
La siguiente decisión relaciona condiciones específicas con una elección clara. Cada regla se basa en las diferencias entre el modelado de procesos informal y estandarizado. Siga la primera condición que coincida con su situación.
- Un solo rol, sin traspasos
Un diagrama de flujo es suficiente. Si una persona o equipo es responsable de cada paso y el diagrama no cruzará límites organizativos o de sistemas, la precisión adicional de BPMN introduce complejidad sin aportar valor.
- Varios roles con responsabilidad sobre pasos específicos
Use BPMN. En cuanto un proceso cambia de manos, la ambigüedad sobre quién es responsable de cada paso se convierte en un problema real. Los pools y lanes de BPMN formalizan la responsabilidad, en lugar de dejarla implícita. Este es el umbral a partir del cual los modelos de procesos empresariales necesitan estructura.
- El proceso se implementará en software de automatización o una plataforma BPM
Use BPMN, específicamente BPMN 2.0. La elección de modelado se convierte en la elección de configuración. Un diagrama de flujo deberá volver a dibujarse como BPMN antes de que cualquier plataforma de automatización de procesos pueda utilizarlo como especificación.
- Se requiere documentación de cumplimiento o auditoría
BPMN es la elección adecuada. Los analistas de negocio y los equipos de cumplimiento necesitan demostrar no solo qué sucede, sino quién es responsable, cómo se gestionan las excepciones y cuál es el alcance del proceso. Los diagramas de flujo no proporcionan suficiente responsabilidad formal para contextos regulatorios.
- La audiencia de partes interesadas no es especialista y la rapidez de comunicación importa
Un diagrama de flujo gana. Si el objetivo es conseguir rápidamente aprobación, comentarios de revisión o una comprensión compartida de una audiencia diversa en una reunión breve, la notación BPMN introduce una curva de aprendizaje que ralentiza la conversación. Optimice para la claridad ahora y para la precisión después.
- El proceso supera una rama de decisión con cambios de responsabilidad entre ramas
Cambie a BPMN. En cuanto un proceso tiene una ruta condicional en la que un equipo diferente toma el control según el resultado, un diagrama de flujo empieza a acumular ambigüedad. El alcance del proceso justifica entonces la estructura de la notación.
- Boceto de proceso en etapa inicial, sujeto a cambios
Use un diagrama de flujo. Sobredefinir en BPMN antes de que un proceso sea estable genera ciclos de revisión costosos. Esboce el flujo, valide los pasos y luego formalice en BPMN cuando el proceso esté listo para su entrega.
Las buenas partes interesadas suelen plantear una versión de esta pregunta cuando ven un diagrama de proceso por primera vez: «¿Quién es responsable de esta parte?». Si su diagrama no puede responder esa pregunta sin ambigüedad, esa es la señal para usar BPMN independientemente de la complejidad del proceso.
📊 En la práctica:
ISO/IEC 19510:2013 establece explícitamente que el objetivo de BPMN es proporcionar un estándar de notación para el modelado de procesos empresariales que sea comprensible para todos los usuarios de negocio, desde los analistas de negocio que crean los borradores iniciales hasta los desarrolladores que implementan la tecnología. Elegir un diagrama de flujo para un proceso que se implementará en software es una decisión deliberada, no una opción predeterminada neutral. El estándar para el modelado de procesos empresariales existe porque el coste de esa decisión fue lo bastante alto como para justificar una especificación internacional.
Tutorial de BPMN: lo mínimo que necesita para leer un diagrama BPMN
¿Nunca ha leído un diagrama BPMN? Es un buen punto de partida.
Esto es lo que necesita para orientarse en cualquier diagrama BPMN sin formación formal.
Cuatro categorías de elementos. Los eventos son círculos: un círculo fino inicia el proceso, un círculo con borde grueso finaliza el proceso y los círculos con formas internas son eventos intermedios (temporizador, mensaje, error) que ocurren durante el proceso. Las actividades son rectángulos redondeados: las tareas son pasos atómicos, y los subprocesos se expanden en sus propios diagramas cuando aparece el signo más en el centro inferior. Las compuertas son rombos: la forma de su interior indica el tipo, y el tipo determina si se activa una ruta (exclusiva), se activan todas las rutas (paralela) o el primer evento coincidente desencadena el siguiente paso (basada en eventos). Los objetos de conexión son las líneas: una flecha continua representa un flujo de secuencia dentro de un pool y una flecha discontinua representa un flujo de mensajes entre pools.
Estructura de pools y lanes. Cada pool es un participante separado en el modelo de proceso empresarial. Ventas, Cliente, Finanzas, Sistema externo: cada uno tiene su propio pool. Los lanes subdividen un pool en roles dentro de ese participante. Seguir un modelo de notación BPMN significa rastrear en qué lane se encuentra una actividad y cuándo una flecha cruza de un pool a otro, porque ese cruce representa un intercambio formal de mensajes con su propia semántica, no solo un traspaso de información.
Flujos de mensajes. Una flecha discontinua que conecta dos pools representa un flujo de mensajes: una comunicación explícita y definida entre dos participantes separados. Esto es lo que un diagrama de flujo estándar no puede representar sin improvisar símbolos. En un modelo BPMN bien dibujado, toda comunicación entre pools es visible y está tipificada.
La especificación BPMN 2.0 es la referencia completa, publicada por Object Management Group, y es exhaustiva. Para la mayoría de las tareas de lectura de notación de modelos de procesos empresariales —evaluar si un proceso necesita BPMN, revisar un diagrama que le han entregado o decidir si un proceso está correctamente modelado—, las categorías de elementos anteriores cubren aproximadamente el 90 % de lo que encontrará. La iniciativa de gestión de procesos empresariales que creó BPMN lo diseñó para ser legible a ese nivel sin certificación, y esa intención se mantiene en la práctica.
La representación XML, XML de BPMN 2.0, es lo que procesan los motores BPM. No necesita leerla como parte interesada, pero saber que existe explica por qué los diagramas BPMN creados en herramientas como Camunda o Bizagi son inmediatamente ejecutables: la representación visual de un proceso y la especificación que ejecuta el motor se producen a partir de la misma fuente.
