Una compuerta exclusiva elige una ruta. Una compuerta paralela activa todas las rutas de salida. La diferencia resulta especialmente importante cuando esas rutas vuelven a unirse: la unión exclusiva no espera a que termine el trabajo concurrente; la paralela, sí.
Al representar un proceso en un espacio compartido para crear diagramas de flujo, define la regla de negocio antes de elegir el rombo. Este ejemplo de revisión de pedidos muestra por qué «recogida o entrega» y «comprobar pago y existencias» necesitan comportamientos distintos, aunque ambos dibujen dos ramas.
Compara el comportamiento de las compuertas
BPMN significa Business Process Model and Notation, un estándar para modelar procesos de negocio. Sus compuertas describen el comportamiento del proceso, no solo la forma del dibujo. La especificación BPMN de OMG define cómo se dividen y se unen los flujos.
| Pregunta | Compuerta exclusiva | Compuerta paralela |
|---|---|---|
| ¿Qué hace al dividir el flujo? | Selecciona una ruta de salida según las condiciones del modelo. | Activa todas las rutas de salida. |
| ¿Qué hace al unirlo? | Deja pasar cada token que llega; no sincroniza llegadas concurrentes. | Espera un token por cada ruta de entrada antes de continuar. |
| ¿Qué pregunta suele resolver? | ¿Cuál de las opciones corresponde? | ¿Qué tareas deben terminar todas? |
| ¿Cómo se representa? | Con una X dentro de un rombo; también puede mostrarse sin la X. | Con un signo + dentro de un rombo. |
Un token permite razonar sobre el avance de una instancia del proceso. Para los ejemplos siguientes, imagina una ficha que recorre cada ruta activa. No representa un cliente ni una unidad de inventario.
La documentación de Camunda sobre compuertas exclusivas explica la selección de una ruta y la unión sin sincronización. Su documentación sobre compuertas paralelas describe la activación de todas las salidas y la espera en la unión. La concurrencia lógica no garantiza que dos personas o máquinas trabajen exactamente al mismo tiempo.
Elige entre recogida y entrega con una compuerta exclusiva
Piensa en un pedido cuyo método ya está registrado como recogida o entrega. Tras recibirlo, el proceso pregunta «¿Cómo se entrega el pedido?». Una rama prepara las instrucciones de recogida y la otra, los detalles de entrega.
Solo debe ejecutarse una de esas ramas para este pedido. Etiqueta las rutas como «Recogida» y «Entrega» y utiliza una compuerta exclusiva. Ambas pueden converger en una unión exclusiva antes de pasar a la siguiente etapa.
Recorre el caso de un pedido para recoger. Una ficha avanza por esa ruta, llega a la unión y continúa. No se espera ninguna ficha de la ruta de entrega, porque nunca se seleccionó.
Decide también qué sucede si falta el dato o tiene un valor inesperado. Si nadie ha elegido el método, «entrega» no debería convertirse en la respuesta por accidente. Añade una ruta explícita de aclaración o establece una condición previa válida. En un modelo ejecutable, configura deliberadamente las condiciones y el posible flujo predeterminado: una etiqueta no constituye por sí sola una regla ejecutable.
Comprueba pago y existencias con una compuerta paralela
Ahora el proceso debe comprobar el estado del pago y la disponibilidad de existencias antes de preparar el pedido. En este ejemplo, ninguna comprobación necesita el resultado de la otra para empezar. Una división paralela activa ambas rutas: «Comprobar pago» y «Comprobar existencias».
En la unión paralela, el pedido espera a que terminen las dos comprobaciones. Si la del pago finaliza primero, su ficha espera allí. Cuando termina la de existencias, la unión consume ambas llegadas y deja continuar una sola ficha.
Terminar no equivale a aprobar. La comprobación de existencias puede concluir «no disponible» y la del pago, «sin confirmar». Después de la unión, utiliza otra decisión para evaluar esos resultados. La unión coordina la finalización, pero no decide que el pedido esté listo.
La secuencia de esta etapa es: iniciar ambas comprobaciones → esperar ambos resultados → decidir si el pedido puede continuar. Si los dos resultados son aceptables, se prepara el pedido. En caso contrario, se deriva al trabajo necesario para resolver la incidencia.
Detecta los dos errores de unión
Algunos diagramas tienen las actividades correctas y la unión equivocada. Comprueba el recorrido de un pedido, en vez de juzgar el dibujo por su simetría.
| Patrón incorrecto | Qué ocurre al recorrerlo | Corrección para este caso |
|---|---|---|
| División exclusiva entre recogida y entrega seguida de una unión paralela | Llega la ficha de recogida, pero la unión también espera a la ruta de entrega, que no se activó. Esa segunda ficha no llegará. | Utilizar una unión sin sincronización para estas alternativas mutuamente excluyentes. |
| División paralela entre pago y existencias seguida de una unión exclusiva | La primera comprobación puede continuar sin esperar. La segunda también puede continuar después y activar dos veces el trabajo posterior. | Sincronizar las dos comprobaciones obligatorias mediante una unión paralela antes de evaluar sus resultados. |
No son errores decorativos. Cambiar el símbolo de un rombo puede hacer que un proceso espere indefinidamente, continúe demasiado pronto o inicie una tarea más de una vez.
Tampoco lo reduzcas a «combina siempre compuertas idénticas». Un proceso real puede incluir decisiones anidadas, bucles o ramas que terminan por separado. Elige la unión según las llegadas posibles y lo que deba suceder antes de continuar. Repetir el mismo símbolo no sustituye ese razonamiento.
Prevé una comprobación que no pueda terminar normalmente
¿Qué sucede si el servicio de inventario no está disponible? Si simplemente eliminas esa ruta del dibujo, la ficha del pago se queda esperando en la unión. Define qué significa «comprobación terminada» cuando no se puede obtener un resultado.
En un esquema de negocio de alto nivel, la tarea puede terminar con un resultado explícito: «desconocido: requiere revisión». La decisión posterior a la unión envía el pedido a revisión en lugar de interpretar que hay existencias. Un modelo BPMN ejecutable necesita el tratamiento de errores, tiempos de espera, cancelaciones y reintentos adecuado para su motor y sus requisitos de negocio.
Primero resuelve la pregunta de negocio: ¿debe esperar todo el pedido, pasar a revisión manual o detenerse? No desvíes una comprobación fallida alrededor de la unión directamente a «Preparar pedido», salvo que ese sea realmente el proceso autorizado. Saltarse la sincronización puede anular el motivo por el que se exigían dos comprobaciones.
Recorre el proceso con el equipo en Boardmix
Crea dos zonas separadas en el lienzo de Boardmix. La primera contiene la elección exclusiva entre recogida y entrega y su unión. La segunda muestra las comprobaciones paralelas de pago y existencias, su unión y la decisión posterior sobre los resultados.
Utiliza nombres de tarea breves que empiecen con un verbo, símbolos de compuerta visibles y etiquetas junto a las rutas alternativas. Deja espacio debajo para recorrer el proceso manualmente. Mueve una pequeña figura por la ruta de recogida y usa dos figuras para las comprobaciones paralelas. La pizarra sirve para discutir la lógica; para ejecutar el proceso, utiliza un motor BPMN.
Abre una pizarra de Boardmix e invita a quienes realizan las comprobaciones a recorrer el ejemplo contigo. Identifica con el equipo dónde puede faltar un resultado, qué tareas pueden comenzar de forma independiente y qué debe saberse antes de iniciar la siguiente.
Si la regla es «realizar una o varias comprobaciones según corresponda», ni una elección exclusiva simple ni una división paralela incondicional la expresan por completo. Mantén visible esa regla y estudia la ramificación condicional adecuada. Dos flechas no aclaran si debe ejecutarse una ruta, ambas o un subconjunto variable.
