BPMN (Business Process Model and Notation) es el idioma estándar para dibujar procesos de negocio: un conjunto de símbolos que negocio y TI leen igual y que, en su versión 2.0, un motor puede ejecutar. Saber leer y escribir un diagrama BPMN es la habilidad central de cualquiera que trabaje con procesos — y dominar las pasarelas (gateways) es lo que separa un dibujo bonito de un proceso que funciona.
Esta guía recorre los símbolos BPMN agrupados por familias, con SVG de cada uno, explica las cuatro pasarelas y el error clásico que provoca un bloqueo, y termina con un diagrama BPMN completo de aprobación de facturas. Es el complemento práctico de nuestra guía ¿Qué es BPM?.
BPMN son las siglas de Business Process Model and Notation: modelo y notación de procesos de negocio. Es el estándar internacional para representar gráficamente cómo funciona un proceso, mantenido por el Object Management Group (OMG) y recogido como norma ISO/IEC 19510. Su objetivo es que el mismo diagrama lo entiendan tres públicos que normalmente hablan idiomas distintos: el analista de negocio que conoce el proceso, el responsable que lo aprueba y el equipo técnico que lo implementa.
La gran diferencia entre BPMN y un simple diagrama de flujo es la semántica precisa. En un diagrama de flujo, un rombo significa "una decisión" y cada autor lo dibuja a su manera. En BPMN, un rombo con una X dentro es una pasarela exclusiva con un comportamiento definido al milímetro, distinto del rombo con un signo + (paralela). Esa precisión es lo que permite que el diagrama BPMN 2.0 sea ejecutable: un motor de procesos lo interpreta directamente y lo convierte en una aplicación real, sin que nadie tenga que "traducirlo" a código y perder matices por el camino.
Conviene situar BPMN dentro de la disciplina mayor a la que sirve. BPMN es la notación que se usa en la fase de modelado del ciclo de vida BPM; si quieres el panorama completo — qué es la gestión por procesos, en qué se diferencia de un workflow o de RPA y cómo se implanta — empieza por la guía pilar ¿Qué es BPM?.
En una frase: BPMN es a los procesos lo que el pentagrama es a la música. Un lenguaje común que cualquiera puede leer y que una máquina puede ejecutar. Esta guía te enseña a leerlo y a escribirlo bien.
BPMN 2.0 define decenas de símbolos, pero no necesitas memorizarlos todos. Cuatro familias cubren la inmensa mayoría de los diagramas de negocio: eventos, actividades, pasarelas y flujos de secuencia. A su alrededor, dos elementos de organización — carriles (responsabilidad) y artefactos (anotaciones y objetos de datos) — completan el cuadro.
Círculos. Algo que ocurre: arranca, interrumpe o termina el proceso.
Rectángulos redondeados. El trabajo: tareas y subprocesos.
Rombos. Decisiones: el flujo se bifurca o se sincroniza.
Flechas. El orden: conectan los elementos en secuencia.
Un pool representa a un participante (una organización o un sistema); dentro, los carriles (lanes) dividen el trabajo por rol o departamento. Ubican cada actividad bajo un responsable claro. Lo vemos en detalle en la sección 6.
No alteran el flujo, lo documentan: objetos de datos (un documento que entra o sale de una tarea), anotaciones de texto (notas para el lector) y grupos (recuadros que agrupan visualmente). Útiles para que el diagrama se lea solo.
Un evento es algo que ocurre durante el proceso. Se dibuja siempre como un círculo, y el grosor del trazo indica su posición en el flujo: el evento de inicio lleva trazo fino, el intermedio es un doble círculo y el de fin tiene trazo grueso. Esa regla, sola, ya te permite leer por dónde entra y sale un proceso de un vistazo.
Además, un icono dentro del círculo indica el tipo de evento: un sobre es un evento de mensaje (llega o se envía algo), un reloj es un temporizador (vence un plazo), un rayo es un error y un triángulo es una señal (un aviso que varios procesos pueden escuchar a la vez).
El proceso arranca cuando llega algo de fuera: un correo, un formulario web enviado, una factura recibida. Es el disparador más común en procesos de negocio.
Hace esperar el flujo ("espera 3 días") o, adosado al borde de una tarea, la interrumpe si vence el plazo. Es la base de los escalados automáticos por SLA.
Captura un fallo de una tarea o subproceso y desvía el flujo por una rama de tratamiento de errores, sin romper la ejecución.
Cierra un camino del proceso. Un diagrama puede tener varios eventos de fin (aprobado, rechazado, cancelado): no es un error, es buena práctica para distinguir desenlaces.
Una actividad es el trabajo que se realiza, y se dibuja como un rectángulo de esquinas redondeadas. Lo que distingue un tipo de tarea de otro es un pequeño icono en la esquina superior izquierda: una persona para la tarea de usuario, unos engranajes para la tarea de servicio, una mano para la tarea manual, un pergamino para la tarea de script y una tabla para la tarea de regla de negocio (business rule).
Cuando una actividad encierra a su vez otro proceso, es un subproceso (con un signo + en el borde inferior, que indica que se puede desplegar) o una call activity (borde grueso) que invoca un proceso reutilizable definido aparte. Y los marcadores en la base de la tarea indican repetición: un bucle (↻) o tres barras de multi-instancia (la misma tarea para varios elementos a la vez, p. ej. "pedir presupuesto a 3 proveedores").
Detalle que importa para la ejecución: el tipo de tarea no es decorativo. En un motor BPMN, una tarea de usuario genera una entrada en la bandeja de una persona; una tarea de servicio dispara una llamada a un sistema o API; una de regla evalúa una tabla de decisión. Por eso modelar bien el tipo de cada tarea es lo que hace que el diagrama sea directamente ejecutable. Una tarea de servicio puede estar resuelta por código, por un bot RPA o por un agente IA gobernado — el diagrama no cambia.
Las pasarelas son el corazón de la lógica de un proceso y la parte que más dudas genera. Siempre se dibujan como un rombo, y un símbolo interior define su comportamiento. Hay cuatro que necesitas dominar. La regla mental: una pasarela divergente abre caminos y la convergente los vuelve a juntar; usar el tipo equivocado al juntarlos es la causa número uno de procesos que se bloquean.
El flujo toma un solo camino, el primero cuya condición sea verdadera. Es el "if/else" del proceso. Ejemplo: "¿el importe supera 5.000 €?" → Sí va a aprobación del director; No, se contabiliza directamente. Solo una de las dos ramas se ejecuta.
Activa todos los caminos simultáneamente, sin condiciones. Ejemplo: al contratar a alguien, en paralelo se prepara el equipo informático, se da de alta en nómina y se solicita la tarjeta de acceso. La convergencia paralela espera a que terminen todas antes de seguir.
Activa todos los caminos cuya condición se cumpla, de uno a todos. Ejemplo: una reclamación puede requerir, según el caso, revisión legal, revisión técnica o ambas. La convergencia inclusiva espera solo a las ramas que realmente se activaron.
El camino no lo decide una condición de datos, sino qué evento ocurre antes. Ejemplo: tras enviar un presupuesto, el proceso espera: si llega la aceptación del cliente, va a facturar; si vence el plazo de 15 días (temporizador), va a seguimiento comercial.
El fallo más frecuente al modelar BPMN: abrir el flujo con una pasarela exclusiva (donde solo se activa una rama) y luego intentar cerrarlo con una pasarela paralela de convergencia. La paralela espera a que lleguen todas las ramas — pero como la exclusiva solo activó una, las demás nunca llegan. El proceso se queda esperando para siempre: eso es un deadlock (bloqueo).
La regla para evitarlo: cierra con el mismo tipo con el que abriste. Lo que divergió en una exclusiva, vuelve a juntarse en una exclusiva; lo paralelo, en paralelo; lo inclusivo, en inclusivo. Coincidir la apertura con el cierre elimina la inmensa mayoría de los bloqueos.
Un diagrama BPMN no solo muestra qué pasa, sino quién lo hace. Para eso están los carriles (swimlanes). Imagina una piscina vista desde arriba: el rectángulo grande es el pool (el participante completo, p. ej. "Nuestra empresa") y las franjas horizontales de su interior son los carriles, uno por rol o departamento: Finanzas, RRHH, el sistema. Cada tarea se dibuja en el carril del responsable que la ejecuta — así, leyendo en vertical, sabes de quién es cada paso.
La distinción clave es cuándo usar un carril y cuándo un pool separado:
Cuando todos los participantes pertenecen a la misma organización y comparten el proceso. Las tareas se conectan con flujos de secuencia (flechas sólidas) que cruzan de un carril a otro. Ejemplo: Finanzas y el sistema ERP en el proceso de facturas.
Cuando interviene otra organización (un cliente, un proveedor, una administración) cuyo proceso interno no controlas ni ves. Los pools no se conectan con flujos de secuencia, sino con flujos de mensaje (flechas discontinuas): solo intercambian comunicaciones.
Esta regla evita un error común: meter al cliente como un carril más dentro de tu pool. Tú no orquestas las tareas internas del cliente — solo le envías y recibes mensajes. Modelarlo como pool separado deja claro el límite de responsabilidad y hace el diagrama honesto sobre lo que realmente controlas.
Juntemos todo en un diagrama real. Modelamos la aprobación de una factura con un pool de dos carriles — Finanzas (las personas) y Sistema (los pasos automáticos) — un evento de inicio de mensaje, una tarea de servicio de OCR, una pasarela exclusiva que decide según el importe, una tarea de usuario de aprobación, el registro en el ERP y un evento de fin.
Léelo siguiendo las flechas: la factura llega y arranca el proceso en el carril Sistema; la tarea de servicio OCR extrae importe, proveedor y vencimiento; la pasarela exclusiva mira el importe. Las de menos de 5.000 € no necesitan persona y van directas al ERP; las que lo superan suben al carril Finanzas, donde una persona aprueba antes de que el sistema las registre. Un único evento de fin marca "contabilizada".
Fíjate en lo que el diagrama deja explícito sin una sola línea de prosa: qué pasos son automáticos y cuáles humanos (los carriles), dónde está la decisión y con qué criterio (la pasarela y su etiqueta), y cuándo entra una persona (solo por encima del umbral). Esa es la potencia de BPMN: documenta, comunica y — en BPMN 2.0 — se ejecuta, todo con el mismo dibujo. Este es justamente el tipo de proceso que encontrarás listo para activar en el catálogo de plantillas BPM.
Aquí está la diferencia que cambió el mercado. En el mundo de los diagramas de flujo de toda la vida, el dibujo era documentación: alguien lo aprobaba, y luego un equipo lo "traducía" a código. En esa traducción se perdían matices, se introducían diferencias y, seis meses después, el diagrama y la realidad ya no coincidían.
Con BPMN 2.0 sobre un motor de procesos, no hay traducción: el diagrama es el programa. El motor lee el XML del modelo (BPMN 2.0 define un formato de intercambio estándar) y lo ejecuta tal cual. Cuando el flujo llega a una tarea de usuario, el motor crea la entrada en la bandeja de la persona; en una tarea de servicio, llama al sistema; en una pasarela, evalúa la condición y elige la rama. Lo que negocio validó es, literalmente, lo que corre en producción.
En una plataforma BPM low-code esto se lleva un paso más allá: además del diagrama, diseñas los formularios, las reglas y las integraciones de forma visual, sin programar. Las fases de modelar y ejecutar del ciclo de vida BPM colapsan en una sola. Por eso el primer proceso productivo se mide en semanas, no en meses.
Si quieres ver cómo se construye un proceso BPMN ejecutable de principio a fin, mira la plataforma BPM low-code de Dokuflex; y para el contexto completo de la disciplina, la guía ¿Qué es BPM?.
Un diagrama BPMN técnicamente correcto puede seguir siendo ilegible. Estas convenciones, sencillas, marcan la diferencia entre un modelo que se entiende solo y uno que necesita explicación:
"Aprobar factura", "Registrar en ERP", "Notificar al cliente". No "Factura" ni "Gestión": una tarea es una acción. Los eventos, en cambio, se nombran como sustantivo o estado ("Factura recibida", "Contrato firmado").
Dibuja el flujo principal en una línea recta horizontal y deja las excepciones y rechazos saliendo hacia arriba o hacia abajo. El lector debe poder seguir el caso normal sin esfuerzo y ver las desviaciones como ramas.
Las flechas que se cruzan son la señal visual de un diagrama desordenado. Reorganiza la posición de las tareas hasta que los flujos no se solapen; casi siempre se puede.
Si un proceso crece demasiado, deja de leerse. Encapsula bloques en subprocesos que se despliegan: el diagrama de primer nivel cuenta la historia, y cada subproceso aporta el detalle a quien lo necesite.
Lo que abre una exclusiva, lo cierra una exclusiva; lo paralelo, una paralela. Es la regla que evita los deadlocks de la sección 5. Y etiqueta siempre las ramas de una exclusiva (Sí/No, <5.000/>5.000).
Un proceso evoluciona. Guarda versiones del modelo y, en el motor, mantén conviviendo la versión antigua para los expedientes en curso y la nueva para los que arrancan. Cambiar el diagrama no debería romper lo que ya está en marcha.
Y un error de fondo más allá de la notación: no modeles el proceso que querrías tener, modela el que tienes — incluidas sus excepciones reales — y luego mejóralo. Un diagrama idealizado que ignora los casos difíciles se rompe el primer día en producción.
BPMN son las siglas de Business Process Model and Notation (modelo y notación de procesos de negocio). Es el estándar internacional, mantenido por el Object Management Group (OMG) y recogido en la norma ISO/IEC 19510, que define un lenguaje gráfico para dibujar procesos de forma que cualquier persona los entienda y, en BPMN 2.0, un motor los pueda ejecutar.
No. Un diagrama de flujo clásico es informal: cada autor usa los símbolos a su manera y no es ejecutable. BPMN 2.0 es un estándar con semántica precisa: cada símbolo tiene un significado definido (eventos de tipo mensaje o temporizador, pasarelas exclusivas o paralelas, carriles por responsable) y un motor BPM puede interpretar el diagrama y ponerlo en producción sin reinterpretarlo.
La pasarela inclusiva (rombo con un círculo dentro, símbolo O). Activa todos los caminos cuya condición sea verdadera, de uno a todos a la vez. Si solo puede cumplirse una condición usa la exclusiva (X); si quieres lanzar siempre todos los caminos en paralelo, sin condición, usa la paralela (+). Recuerda cerrar la divergencia inclusiva con otra pasarela inclusiva de convergencia para sincronizar correctamente.
Para dibujar basta cualquier editor que soporte el estándar (incluidos editores gratuitos basados en bpmn.io). Pero el valor de BPMN 2.0 es que el diagrama es ejecutable: en una plataforma BPM low-code el mismo diagrama que validas con negocio se convierte en la aplicación real, con formularios, reglas e integraciones, sin volver a dibujarlo en otra herramienta.
Sí. Una tarea de un proceso BPMN puede ser ejecutada por una persona, un servicio, un bot RPA o un agente IA. Modelar el paso de IA como una tarea de servicio dentro del diagrama mantiene la trazabilidad: la pasarela posterior decide según el resultado o el nivel de confianza, y el flujo escala a una tarea de usuario cuando la IA no llega al umbral (human-in-the-loop).
Aunque BPMN 2.0 define decenas de símbolos, cuatro grupos cubren el 90% de los diagramas reales: eventos (inicio, intermedio, fin), actividades (tareas y subprocesos), pasarelas (exclusiva, paralela, inclusiva y basada en eventos) y flujos de secuencia, organizados en carriles. Con ese subconjunto se modelan casi todos los procesos de negocio.
Trae el proceso que tienes dibujado — facturas, vacaciones, onboarding — y te enseñamos el mismo diagrama BPMN ejecutándose en Dokuflex en una demo de 30 minutos. Sin compromiso y con tu caso, no con uno de laboratorio.