Modelo y notación de procesos de negocio, o BPMN, es un lenguaje visual estandarizado para describir cómo se realiza el trabajo. Ayuda a los analistas de negocio, gerentes, desarrolladores y participantes del proceso a comprender el mismo proceso sin depender de procedimientos escritos extensos.
Un diagrama BPMN se construye a partir de cuatro categorías amplias:
-
Objetos de flujo: Eventos, actividades y puertas de control
-
Objetos de conexión: Flujos de secuencia, flujos de mensajes y asociaciones
-
Carriles: Bases y carriles
-
Artefactos: Objetos de datos, grupos y anotaciones de texto
Esta guía se centra en la categoría más importante: Objetos de flujo de BPMN. Los objetos de flujo describen qué ocurre en un proceso, qué trabajo se realiza y cómo el proceso se desplaza de un camino a otro.
1. ¿Qué son los objetos de flujo de BPMN?
Los objetos de flujo son los elementos centrales de un diagrama de proceso BPMN. Están conectados por flujos de secuencia y representan el comportamiento de un proceso.
Existen tres tipos:
| Objeto de flujo | Forma básica | Propósito principal |
|---|---|---|
| Evento | Círculo | Algo que ocurre |
| Actividad | Rectángulo redondeado | Trabajo que se realiza |
| Puerta de control | Rombo | Un punto de decisión, división, fusión o sincronización |
Un proceso simple podría verse conceptualmente así:
Evento de inicio → Actividad → Puerta → Actividad → Evento de fin
Por ejemplo:
Pedido recibido → Verificar inventario → ¿Está disponible el artículo?
├── Sí → Enviar pedido
└── No → Notificar al cliente
Las formas son simples, pero los símbolos dentro de ellas proporcionan significado adicional.
2. Eventos: Cosas que ocurren
Un evento representa algo que ocurre durante el transcurso de un proceso. A diferencia de una actividad, un evento no es un trabajo realizado por una persona o un sistema. Puede desencadenar un proceso, interrumpir una actividad, señalar una condición o indicar cómo termina un proceso.
Los eventos se muestran como círculos. El borde indica dónde ocurre el evento en el proceso:
| Tipo de evento | Apariencia del borde | Significado |
|---|---|---|
| Evento de inicio | Línea simple delgada | Muestra cómo comienza un proceso |
| Evento intermedio | Línea doble | Ocurre entre el inicio y el fin |
| Evento de fin | Línea simple gruesa | Muestra cómo termina un camino de proceso |
Un evento de inicio puede capturar un desencadenante, como un mensaje entrante o un tiempo programado. Un evento intermedio puede esperar o enviar algo. Un evento de fin produce el resultado final de un camino de proceso.
2.1 Eventos de inicio
Un evento de inicio indica el desencadenante que inicia un proceso o subproceso.
Se dibuja como un círculo con un borde delgado.
Los ejemplos comunes incluyen:
-
Un cliente presenta un pedido
-
Un empleado presenta una solicitud de permiso
-
Un temporizador alcanza una fecha programada
-
Llega un mensaje
-
Un sistema detecta una condición
-
Se crea un nuevo caso
Evento de inicio nulo
Un círculo de inicio simple significa que el proceso comienza sin un disparador modelado específicamente.
○
Ejemplo:
○ → Revisar solicitud
Utilice un evento de inicio nulo cuando el disparador preciso sea desconocido, irrelevante o intencionalmente dejado general.
Evento de inicio por mensaje
Un símbolo de mensaje dentro del evento de inicio indica que el proceso comienza cuando se recibe un mensaje.
Ejemplo:
◉ símbolo de sobre → Procesar solicitud del cliente
Casos de uso típicos:
-
Recibir un correo electrónico
-
Recibir una solicitud de API
-
Recibir una orden de compra
-
Recibir una solicitud de otro participante
Evento de inicio por temporizador
Un reloj dentro del evento de inicio indica que el proceso comienza según un horario o fecha.
Ejemplos:
-
Iniciar la generación de facturas mensualmente
-
Iniciar un proceso de renovación 30 días antes de la expiración
-
Ejecutar un proceso de conciliación diario
Evento de inicio condicional
Un evento de inicio condicional comienza cuando una condición empresarial se vuelve verdadera.
Ejemplo:
El nivel de inventario cae por debajo del punto de reorden
Evento de inicio por señal
Un evento de inicio por señal comienza cuando se recibe una señal de difusión. A diferencia de un mensaje, una señal generalmente no está dirigida a un destinatario específico.
Ejemplo:
Recibir señal de "Cierre de Emergencia" → Cerrar todas las sucursales
Evento de inicio múltiple
Un evento de inicio múltiple indica que varios desencadenantes diferentes pueden iniciar el mismo proceso.
Por ejemplo, un caso de soporte podría comenzar cuando:
-
Un cliente envía un formulario web
-
Un agente ingresa un caso manualmente
-
Un sistema de monitoreo automatizado detecta un problema
2.2 Eventos intermedios
Un evento intermedio ocurre después de que un proceso ha comenzado pero antes de que haya terminado. Puede pausar el proceso, esperar algo, enviar un mensaje, crear un camino de excepción o responder a una condición.
Se dibuja con un borde doble.
Los eventos intermedios pueden ser:
-
Captura: Esperar o recibir algo
-
Lanzamiento: Enviar o producir algo
Un evento de captura generalmente tiene un marcador vacío o de contorno, mientras que un evento de lanzamiento generalmente utiliza un marcador relleno.
Evento intermedio de temporizador
Un evento de temporizador representa un retraso, una fecha límite, una duración o un horario recurrente.
Ejemplos:
-
Esperar tres días hábiles
-
Esperar hasta una fecha específica
-
Escalar si no llega respuesta dentro de 24 horas
-
Realizar una acción recurrente mientras el proceso esté activo
Ejemplo:
Enviar cotización → Esperar 3 días → Verificar respuesta
Evento intermedio de mensaje
Un evento intermedio de mensaje espera un mensaje o lo envía.
Ejemplos:
Enviar solicitud de aprobación → Esperar respuesta de aprobación
Un evento de mensaje es especialmente útil cuando un proceso interactúa con otro participante, departamento, organización o sistema.
Evento intermedio de error
Un evento de error representa una condición de error que afecta el flujo normal del proceso.
Se utiliza comúnmente como un evento de borde adjunto a una actividad o subproceso.
Ejemplo:
Procesar pago
│
└── Error → Manejar fallo de pago
Evento intermedio de escalación
Un evento de escalación indica que un problema requiere atención a un nivel superior sin representar necesariamente un fallo técnico.
Ejemplo:
Resolver queja del cliente
│
└── Escalación → Revisión del supervisor
Evento intermedio condicional
Un evento condicional espera hasta que una condición especificada se vuelva verdadera.
Ejemplo:
Esperar hasta que la cuenta del cliente esté verificada
Evento intermedio de señal
Un evento de señal transmite o recibe una señal que puede ser relevante para múltiples participantes del proceso.
Ejemplo:
Transmitir señal de retirada de producto
Evento intermedio de enlace
Un evento de enlace conecta dos puntos distantes dentro del mismo diagrama de proceso sin dibujar una larga línea de flujo de secuencia a través de la página.
Utilice los eventos de enlace con cuidado. Pueden mejorar la legibilidad del diagrama, pero un uso excesivo puede hacer que el proceso sea más difícil de seguir.
Evento intermedio de compensación
Un evento de compensación activa trabajos correctivos para deshacer o compensar una actividad anterior.
Ejemplo:
Cancelar reserva de hotel
La compensación es diferente de una ruta de error ordinaria. Se ocupa específicamente de revertir o compensar el trabajo completado.
2.3 Eventos de borde
Unevento de borde se adjunta directamente al borde de una actividad o subproceso. Representa algo que puede ocurrir mientras dicha actividad está en curso.
Ejemplo:
┌────────────────────┐
│ Procesar Solicitud │
└────────────────────┘
○
│
└── Tiempo agotado → Escalar Caso
Los eventos de borde son útiles para modelar:
-
Tiempo agotado
-
Cancelaciones
-
Errores
-
Escalaciones
-
Mensajes entrantes
-
Compensación
-
Señales externas
Eventos de borde interrumpientes
Un evento de borde interrumpiente detiene la actividad adjunta cuando ocurre.
Ejemplo:
Procesar Pago
│
└── Error de Pago → Manejar Fallo
La actividad de pago termina cuando ocurre el error.
Eventos de borde no interrumpientes
Un evento de borde no interrumpiente inicia una ruta adicional mientras la actividad original continúa.
Generalmente se muestra con un borde discontinuo.
Ejemplo:
Procesar Solicitud
│
└── Recordatorio por temporizador → Enviar Recordatorio
El proceso de solicitud continúa mientras se ejecuta la ruta del recordatorio.
Esta distinción es importante:
| Tipo de evento de borde | Efecto en la actividad adjunta |
|---|---|
| Interrumpiente | Detiene la actividad |
| No interrumpiente | Mantiene la actividad en ejecución |
2.4 Eventos de finalización
Un evento de finalizaciónindica la conclusión de una ruta de proceso. Se dibuja como un círculo con un borde grueso.
Un proceso puede tener más de un evento de finalización porque diferentes resultados pueden terminar el proceso.
Ejemplos:
-
Pedido completado
-
Solicitud rechazada
-
Pago fallido
-
Caso cancelado
-
Cliente notificado
-
Proceso completado con compensación
Evento de finalización nulo
Un evento de finalización simple indica que la ruta ha finalizado sin especificar un resultado particular.
●
Evento de finalización de mensaje
Un evento de finalización de mensaje envía un mensaje cuando el proceso finaliza.
Ejemplo:
Pedido aprobado → Enviar confirmación → Fin de mensaje
Evento de finalización de error
Un evento de finalización de error termina el proceso lanzando un error a un proceso o manejador de nivel superior.
Úsalo para condiciones de fallo a nivel de proceso que deben manejarse en otro lugar.
Evento de finalización de escalación
Un evento de finalización de escalación termina la ruta de proceso actual y comunica que se ha producido una escalación.
Evento de finalización de terminación
Un evento de finalización de terminación finaliza inmediatamente toda la instancia de proceso, incluidas otras rutas activas.
Esto es más fuerte que un evento de finalización ordinario. Debe usarse cuando todo el trabajo restante debe detenerse.
Evento final de compensación
Un evento final de compensación activa actividades de compensación antes de que concluya el camino del proceso.
3. Actividades: Trabajo realizado
Una actividad representa el trabajo realizado por una persona, equipo, sistema o servicio automatizado. Las actividades se dibujan como rectángulos con esquinas redondeadas.
Los ejemplos incluyen:
-
Revisar solicitud
-
Aprobar factura
-
Enviar confirmación
-
Validar datos del cliente
-
Calcular costo de envío
-
Actualizar cuenta
-
Generar informe
Las actividades forman la columna vertebral operativa de un diagrama BPMN porque muestran dónde se concentran el tiempo, el esfuerzo, el costo y la responsabilidad.
3.1 Nomenclatura de actividades
Un buen nombre de actividad generalmente sigue este patrón:
Verbo + objeto
Ejemplos:
-
Revisar solicitud
-
Aprobar factura
-
Crear registro de cliente
-
Validar pago
-
Enviar correo de confirmación
Evite nombres vagos como:
-
Procesamiento
-
Gestionar solicitud
-
Paso 1
-
Otro trabajo
-
Administración
Un nombre de actividad claro debe describir una acción y su sujeto.
| Nombre débil | Mejor nombre |
|---|---|
| Procesando | Procesar pago |
| Revisar | Revisar solicitud |
| Paso del cliente | Verificar identidad del cliente |
| Correo electrónico | Enviar correo de aprobación |
| Actualizar | Actualizar estado del pedido |
Una tarea normalmente representa una unidad de trabajo que no puede o no debe desglosarse más. Un subproceso representa una colección de actividades relacionadas.
3.2 Tareas
Una tarea es el tipo más simple de actividad. Representa una única unidad de trabajo.
Una tarea básica se muestra como un rectángulo redondeado:
╭────────────────────╮
│ Revisar solicitud │
╰────────────────────╯
Las tareas pueden incluir marcadores que identifiquen el tipo de trabajo que se está realizando.
Tarea de usuario
Una tarea de usuario es realizada por una persona utilizando un sistema o aplicación.
Ejemplos:
-
Aprobar informe de gastos
-
Introducir información del cliente
-
Revisar contrato
-
Asignar caso de soporte
Tarea manual
Una tarea manual es realizada por una persona sin la asistencia de un motor de procesos de negocio o aplicación.
Ejemplos:
-
Inspeccionar equipo
-
Firmar un documento en papel
-
Empaquetar un producto físico
-
Entregar un documento en mano
Tarea de servicio
Una tarea de servicio se realiza automáticamente por un sistema, aplicación, servicio web o API.
Ejemplos:
-
Obtener puntuación crediticia
-
Enviar correo electrónico automatizado
-
Calcular impuestos
-
Crear registro en la base de datos
-
Llamar al servicio de pago
Tarea de script
Una tarea de script ejecuta un script o un fragmento de código dentro del entorno del proceso.
Ejemplos:
-
Transformar datos
-
Calcular un valor
-
Formatear un mensaje
-
Aplicar una regla de datos simple
Tarea de regla de negocio
Una tarea de regla de negocio evalúa reglas de negocio, a menudo mediante un motor de reglas.
Ejemplos:
-
Determinar límite de crédito
-
Calcular prima de seguro
-
Decidir si un pedido califica para envío gratuito
-
Determinar nivel de aprobación
Tarea de envío
Una tarea de envío envía un mensaje a otro participante o sistema.
Ejemplos:
-
Enviar factura
-
Enviar confirmación de pedido
-
Enviar notificación al almacén
Recibir tarea
Una tarea de recepción espera un mensaje de otro participante o sistema.
Ejemplos:
-
Recibir contrato firmado
-
Recibir confirmación de pago
-
Recibir estado de envío
3.3 Subprocesos
Un subproceso es una actividad que contiene un proceso más detallado.
Puede mostrarse de dos formas:
-
Subproceso colapsado: Un rectángulo redondeado con un marcador de más
-
Subproceso expandido: Un rectángulo redondeado más grande que muestra el flujo interno
Utilice un subproceso cuando varias tareas pertenezcan juntas y el diagrama de alto nivel se vuelva demasiado detallado si se muestran todas.
Ejemplo:
╭──────────────────────────────╮
│ + Completar la incorporación del cliente│
╰──────────────────────────────╯
El subproceso podría contener:
Recopilar información
↓
Verificar identidad
↓
Crear cuenta
↓
Enviar mensaje de bienvenida
Cuándo usar un subproceso
Use uno cuando:
-
Un grupo de pasos tiene un propósito empresarial claro
-
El grupo puede reutilizarse conceptualmente
-
El diagrama principal se está volviendo abigarrado
-
Las partes interesadas necesitan tanto un resumen como una vista detallada
-
El proceso interno tiene su propio inicio, fin, excepción o lógica de decisión
Subproceso incrustado
Un subproceso incrustado se define dentro de su proceso padre y forma parte del flujo de dicho proceso.
Actividad de llamada
Una actividad de llamada invoca un proceso reutilizable definido por separado o una tarea global.
Úsela cuando la misma lógica de proceso se llame desde múltiples lugares, como:
Verificar la identidad del cliente
Si la verificación del cliente aparece en varios procesos empresariales, una actividad de llamada reutilizable puede ser más apropiada que duplicar todos sus pasos internos.
Subproceso de evento
Un subproceso de evento se activa mediante un evento de inicio mientras su proceso o subproceso contenedor está activo. Es útil para manejar situaciones excepcionales o paralelas, como solicitudes de cancelación, escalaciones urgentes o actualizaciones entrantes. Los subprocesos de evento pueden ser interruptores o no interruptores.
Ejemplo:
Proceso principal: Cumplir pedido
Subproceso de evento:
Solicitud de cancelación → Cancelar cumplimiento → Reembolsar al cliente
3.4 Marcadores de actividad
Las actividades pueden incluir pequeños marcadores que añaden información sobre su comportamiento.
Marcador de bucle
Un marcador de bucle indica que una actividad se repite hasta que se cumple una condición.
Ejemplo:
Revisar documento
↻
Úsela para actividades como:
-
Revisar hasta que sea aprobado
-
Intentar la entrega hasta que sea exitosa
-
Contactar al cliente hasta lograrlo
Marcador de instancia múltiple en paralelo
Esto indica que múltiples instancias de la misma actividad se ejecutan al mismo tiempo.
Ejemplo:
Obtener tres aprobaciones
La actividad puede realizarse simultáneamente por varios revisores.
Marcador de instancia múltiple secuencial
Esto indica que múltiples instancias se ejecutan una tras otra.
Ejemplo:
Revisar elementos uno a la vez
Marcador de compensación
Esto identifica una actividad utilizada para compensar el trabajo previamente completado.
Ejemplo:
Reembolsar al cliente
Marcador ad hoc
Un subproceso ad hoc se representa mediante un marcador similar a una tilde. Indica que las actividades dentro del subproceso pueden realizarse en un orden flexible o poco estructurado, en lugar de seguir una secuencia fija.
4. Puertas de paso: Decisiones, divisiones y fusiones
Una puerta de paso controla cómo el flujo del proceso se divide o converge. Las puertas de paso se dibujan como rombos.
Una puerta de paso no es normalmente una tarea. No realiza el trabajo de toma de decisiones en sí misma. En cambio, representa cómo se controla el flujo del proceso después de que se haya evaluado una decisión, condición o evento.
Por ejemplo:
Revisar solicitud → ¿Está completa la solicitud?
La actividad de revisión recopila o evalúa información. La puerta de paso luego dirige el proceso según el resultado.
Las puertas de paso pueden:
-
Dividir un camino en varios caminos
-
Fusionar múltiples caminos en uno
-
Sincronizar trabajo paralelo
-
Esperar uno o más eventos
-
Dirigir el trabajo según condiciones o reglas
4.1 Puerta de paso exclusiva: XOR
Una puerta de paso exclusiva selecciona exactamente un camino de salida.
Comúnmente se muestra como un rombo que contiene una “X”, aunque el marcador puede omitirse en algunos diagramas.
Ejemplo:
┌── Aprobado → Crear cuenta
Revisar solicitud ─◇
└── Rechazado → Enviar rechazo
Solo se sigue un camino.
Usos típicos:
-
Si el pago es aprobado, continuar; de lo contrario, rechazar
-
Si el cliente es elegible, ofrezca un descuento
-
Si la solicitud está completa, procésela; de lo contrario, devuélvala
Las rutas de salida normalmente deben tener condiciones o etiquetas claras:
-
Aprobado
-
Rechazado
-
Completo
-
Incompleto
-
Monto > $10,000
-
Monto ≤ $10,000
Fusión exclusiva
Una compuerta exclusiva también puede fusionar rutas alternativas de nuevo en una sola ruta. No espera a que todas las rutas se completen, ya que solo una de las rutas alternativas debería haberse tomado.
Flujo predeterminado
Una ruta predeterminada puede utilizarse cuando ninguna de las condiciones especificadas es verdadera.
Por ejemplo:
Aprobado
Rechazado
Predeterminado → Revisión manual
Una ruta predeterminada es útil para casos inesperados o no clasificados.
4.2 Compuerta paralela: Y
Una compuerta paralela divide el proceso en múltiples rutas que se ejecutan concurrentemente.
Se representa mediante un rombo que contiene un signo más.
Ejemplo:
┌── Preparar factura ──┐
Pedido aprobado ─◇ ◇── Enviar pedido
└── Reservar inventario ┘
Ambas actividades comienzan, y el proceso puede esperar más tarde a que ambas terminen.
División paralela
Una división paralela inicia todas las rutas de salida.
Úsela cuando todas las actividades deben ocurrir, independientemente de las condiciones.
Ejemplos:
-
Enviar confirmación y actualizar inventario
-
Notificar a finanzas y notificar a operaciones
-
Realizar verificación de seguridad y verificación de fraude
Unión paralela
Una unión paralela espera a que todas las rutas de entrada se completen antes de continuar.
Esto a veces se denomina sincronización.
Preparar factura ──┐
◇── Cumplir pedido
Reservar inventario ┘
Si una rama de entrada se retrasa, la unión espera por ella.
4.3 Puerta inclusiva: OR
Una puerta inclusiva selecciona una o más rutas de salida dependiendo de cuáles condiciones sean verdaderas.
Se representa mediante un rombo que contiene un círculo.
Ejemplo:
El cliente califica para:
- Descuento estándar
- Descuento por lealtad
- Descuento promocional
Puede seleccionarse más de una acción relacionada con descuentos si se cumplen múltiples condiciones.
Use una puerta inclusiva cuando:
-
Una o más condiciones pueden ser verdaderas
-
Varias rutas pueden ejecutarse al mismo tiempo
-
El proceso debe continuar después de que todas las rutas seleccionadas finalicen
A diferencia de una puerta exclusiva, una puerta inclusiva no necesariamente elige solo una ruta. A diferencia de una puerta paralela, no necesariamente elige todas las rutas.
4.4 Puerta basada en eventos
Una puerta basada en eventos dirige el proceso según el evento que ocurra primero.
Comúnmente es seguida por eventos intermedios de captura o tareas de recepción.
Ejemplo:
Enviar cotización → Puerta basada en eventos
├── Mensaje recibido → Proceso de aceptación
└── Temporizador expira → Enviar recordatorio
Solo el primer evento que ocurre determina la ruta.
Use una puerta basada en eventos cuando el proceso esté esperando un comportamiento externo en lugar de evaluar una condición de negocio conocida. Por ejemplo, el proceso podría esperar una respuesta del cliente o una expiración de tiempo.
Puerta basada en eventos frente a puerta exclusiva
| Pregunta | Compuerta exclusiva | Compuerta basada en eventos |
|---|---|---|
| ¿Qué determina el camino? | Una condición o regla de negocio | El primer evento que ocurre |
| Pregunta típica | ¿Se aprueba la solicitud? | ¿Qué ocurre primero? |
| Elementos siguientes comunes | Actividades o flujos de secuencia | Eventos de captura o tareas de recepción |
| Fuente de decisión | Datos o lógica | Evento externo |
4.5 Compuerta compleja
Una compuerta compleja maneja lógica de enrutamiento avanzada que no puede expresarse claramente con los tipos de compuerta estándar.
Los ejemplos incluyen:
-
Continuar cuando se reciban al menos dos de tres aprobaciones
-
Elegir un camino basado en una combinación compleja de condiciones
-
Sincronizar caminos seleccionados según reglas personalizadas
Las compuertas complejas deben usarse con moderación. En muchos casos, varias compuertas más simples o una tarea de regla de negocio claramente nombrada serán más fáciles de entender y mantener.
4.6 Variantes de compuerta basada en eventos
BPMN también soporta variaciones de compuerta basada en eventos, incluyendo:
-
Compuertas exclusivas basadas en eventos
-
Compuertas paralelas basadas en eventos
-
Compuertas basadas en eventos de instanciación
Una compuerta paralela basada en eventos puede esperar múltiples condiciones de evento, mientras que una compuerta exclusiva basada en eventos avanza según el primer evento que ocurre. La variante correcta depende de si el proceso está esperando un evento o una combinación de eventos.
5. Cómo trabajan juntos los objetos de flujo
El significado de un diagrama BPMN proviene de las relaciones entre eventos, actividades, compuertas y flujos de secuencia.
Considere un proceso de pedido:
Inicio
↓
Recibir Pedido
↓
Verificar Inventario
↓
¿Está el artículo disponible?
├── Sí → Empaquetar Pedido → Enviar Pedido → Fin
└── No → Notificar al Cliente → Fin
Este ejemplo contiene:
-
Un evento de inicio que inicia el proceso
-
Actividades para recibir, verificar, empacar, enviar y notificar
-
Una compuerta exclusiva que elige un camino
-
Dos eventos de fin o caminos de fin que representan diferentes resultados
Una versión más avanzada podría ser:
Inicio
↓
Recibir Pedido
↓
Verificar Inventario
↓
¿Está el artículo disponible?
├── No → Notificar al Cliente → Fin
└── Sí → Compuerta Paralela
├── Reservar Inventario
├── Preparar Factura
└── Verificar Fraude
↓
Unión Paralela
↓
Enviar Pedido
↓
Fin
Aquí:
-
La compuerta exclusiva determina si el cumplimiento puede proceder.
-
La compuerta paralela inicia tres actividades.
-
La unión paralela espera a las tres actividades.
-
El envío comienza solo después de que la sincronización esté completa.
6. Eventos, Actividades y Compuertas: Una Comparación Rápida
| Elemento | Pregunta clave | Ejemplo |
|---|---|---|
| Evento | ¿Qué sucedió o sucederá? | Pago recibido |
| Actividad | ¿Qué trabajo se realiza? | Verificar el pago |
| Puerta de enlace | ¿Qué ruta debe seguir el proceso? | ¿Es válido el pago? |
Una regla útil es:
-
Ocurren eventos
-
Se realizan actividades
-
Las puertas de enlace controlan el camino
Si no está seguro de qué símbolo usar, pregunte:
-
¿Es esto algo que ocurre sin ser tratado como trabajo? Use un evento.
-
¿Alguien o algo está realizando una acción? Use una actividad.
-
¿El proceso se está dividiendo, fusionando o esperando una condición de enrutamiento? Use una puerta de enlace.
7. Conectar correctamente los objetos de flujo
Los objetos de flujo se conectan mediante diferentes tipos de líneas. Usar el conector incorrecto puede hacer que un diagrama sea engañoso.
7.1 Flujo de secuencia
Un flujo de secuencia es una línea sólida con una punta de flecha. Muestra el orden en que se ejecutan los objetos de flujo dentro del mismo proceso.
Actividad A → Actividad B
Use el flujo de secuencia para conectar:
-
Eventos a actividades
-
Actividades a puertas de enlace
-
Puertas de enlace a actividades
-
Actividades a eventos finales
Un flujo de secuencia normalmente no debe cruzar el límite entre diferentes pools.
7.2 Flujo de mensaje
Un flujo de mensaje es una línea discontinua con una punta de flecha abierta. Representa la comunicación entre diferentes participantes o pools.
Ejemplos:
-
El cliente envía un pedido al vendedor
-
El vendedor envía una confirmación al cliente
-
El banco envía el resultado del pago al comerciante
Utilice el flujo de mensaje para la comunicación, no para mostrar el orden interno del proceso.
7.3 Asociación
Una asociación es una línea punteada utilizada para conectar artefactos, notas o representaciones de datos a objetos de flujo.
Ejemplos:
-
Adjuntar un documento a una tarea
-
Vincular una anotación de texto a una actividad
-
Mostrar que una tarea utiliza un objeto de datos
Los tres tipos principales de objetos de conexión son flujos de secuencia, flujos de mensaje y asociaciones.
8. Pools y carriles
Aunque los pools y los carriles no son objetos de flujo, proporcionan un contexto esencial para entender quién realiza cada actividad.
Pool
Un pool representa a un participante en un proceso.
Ejemplos:
-
Cliente
-
Proveedor
-
Banco
-
Empresa
-
Agencia gubernamental
-
Sistema externo
Un proceso puede contener un proceso completo o puede mostrarse como un participante de caja negra sin detalles internos.
Carril
Un carril divide un proceso según la responsabilidad, el rol, el departamento, el sistema o la ubicación.
Ejemplos:
-
Servicio al cliente
-
Finanzas
-
Almacén
-
Gerente
-
Sistema de pago
Los carriles ayudan a responder la pregunta:
¿Quién es responsable de esta actividad?
También pueden revelar transferencias, retrasos, trabajo duplicado y propiedad poco clara.
9. Objetos de datos y otros elementos de apoyo
Los objetos de datos no son objetos de flujo, pero proporcionan un contexto útil sobre la información utilizada, creada o modificada por las actividades.
Ejemplos:
-
Formulario de solicitud
-
Factura
-
Orden de compra
-
Registro del cliente
-
Documento de aprobación
-
Etiqueta de envío
Un objeto de datos podría estar conectado a una actividad de la siguiente manera:
Formulario de solicitud → Revisar solicitud
Los objetos de datos identifican la información relevante, pero no necesariamente representan cada pieza de datos manejada por el proceso.
Otros elementos de apoyo incluyen:
-
Almacenes de datos:Ubicaciones persistentes donde se almacenan los datos
-
Notas de texto:Notas explicativas
-
Grupos:Organización visual de elementos relacionados
-
Asociaciones:Enlaces entre elementos de soporte y objetos de flujo
10. Un método paso a paso para modelar un proceso
Paso 1: Definir el alcance del proceso
Decida dónde comienza y termina el proceso.
Por ejemplo:
Desde: El cliente presenta el pedido
Hasta: El pedido se envía o se rechaza
Evite modelar toda la organización en un solo diagrama.
Paso 2: Identificar a los participantes
Liste las personas, departamentos, sistemas u organizaciones involucrados.
Ejemplos:
-
Cliente
-
Equipo de ventas
-
Departamento de finanzas
-
Almacén
-
Pasarela de pago
Estos pueden convertirse en pools o carriles.
Paso 3: Identificar el disparador de inicio
Pregúntese:
¿Qué causa que este proceso comience?
Utilice el evento de inicio adecuado:
-
Mensaje
-
Temporizador
-
Disparador condicional
-
Señal
-
Ninguno
Paso 4: Listar las actividades principales
Escriba cada actividad utilizando un formato de verbo y objeto:
-
Recibir pedido
-
Validar pedido
-
Calcular total
-
Aprobar pago
-
Enviar pedido
En esta etapa, no se preocupe por cada excepción.
Paso 5: Añadir decisiones
Busque preguntas como:
-
¿Está el pedido completo?
-
¿Está aprobado el pago?
-
¿Hay inventario disponible?
-
¿Califica el cliente?
-
¿Ha pasado el plazo?
Use compuertas para representar cómo la respuesta afecta el proceso.
Paso 6: Añadir trabajo en paralelo
Identifique actividades que pueden ocurrir simultáneamente.
Por ejemplo:
-
Actualizar inventario
-
Enviar confirmación
-
Crear factura
Use compuertas paralelas cuando todas las ramas deban completarse o sincronizarse.
Paso 7: Añadir eventos intermedios y de límite
Pregúntese qué puede ocurrir mientras el trabajo está en progreso:
-
¿Tiene la actividad un plazo?
-
¿Puede cancelarse?
-
¿Puede ocurrir un error?
-
¿Puede llegar un mensaje externo?
-
¿Debe escalonarse el proceso si tarda demasiado?
Paso 8: Añadir eventos finales
Identifique todos los resultados significativos:
-
Completado
-
Rechazado
-
Cancelado
-
Fallido
-
Escalado
-
Compensado
Paso 9: Agregar datos y anotaciones
Incluya documentos, sistemas, notas y reglas de negocio solo donde mejoren la comprensión.
Paso 10: Revisar el diagrama
Verifique que:
-
Cada camino del proceso tiene un inicio claro
-
Cada camino eventualmente termina
-
Las condiciones de las compuertas son comprensibles
-
Las actividades tienen responsables claros
-
Los flujos de secuencia muestran el orden real
-
Los flujos de mensaje se usan solo entre participantes
-
Ninguna compuerta se está usando como una tarea
-
El diagrama no está sobrecargado con detalles innecesarios
11. Errores comunes en el modelado BPMN
Error 1: Usar una compuerta como una actividad de decisión
Una compuerta debe enrutar el proceso, no realizar el análisis.
Modelo débil:
◇ Verificar puntaje de crédito
Mejor modelo:
Verificar puntaje de crédito → ¿Crédito aprobado?
La actividad realiza la verificación. La compuerta enruta según el resultado.
Error 2: Usar flujo de secuencia entre buques separados
El flujo de secuencia representa el orden interno del proceso. La comunicación entre participantes separados debe usar flujo de mensaje.
Concepto incorrecto:
Bucle del cliente ── flujo de secuencia sólido ── Bucle del vendedor
Mejor concepto:
Pool de Cliente ── flujo de mensaje discontinuo ── Pool de Vendedor
Error 3: Dejar las rutas de las compuertas sin etiquetar
Una compuerta sin etiquetar genera ambigüedad.
En lugar de:
◇ → Ruta A
→ Ruta B
Usar:
◇
├── Aprobado
└── Rechazado
Error 4: Usar una compuerta exclusiva para trabajo paralelo
Si todas las actividades deben ocurrir, no use una compuerta exclusiva.
Incorrecto:
◇ ├── Enviar Confirmación
└── Actualizar Inventario
Esto significa que solo se selecciona una ruta.
Use una compuerta paralela si ambas actividades deben ocurrir:
+ ├── Enviar Confirmación
└── Actualizar Inventario
Error 5: Usar una compuerta paralela para trabajo condicional
Una compuerta paralela activa todas las rutas de salida. Si solo algunas rutas deben ejecutarse, use una compuerta exclusiva o inclusiva.
Error 6: Modelar cada acción menor
Un diagrama puede volverse ilegible si se incluye cada clic, entrada de campo y acción interna del sistema.
Modele al nivel apropiado para su audiencia:
-
Los ejecutivos necesitan las etapas principales
-
Los propietarios del proceso necesitan responsabilidades y decisiones
-
Los desarrolladores pueden necesitar detalles a nivel de implementación
-
Los auditores pueden necesitar controles y evidencias
Error 7: Crear rutas sin salida
Cada ruta de flujo de secuencia debe eventualmente llegar a un evento final apropiado o a un límite de subproceso claramente definido.
Error 8: Mezclar lógica de negocio e implementación técnica innecesariamente
Un diagrama de proceso de negocio debe explicar el proceso primero. Los detalles técnicos deben incluirse solo cuando ayuden a la audiencia prevista.
12. Convenciones prácticas de nomenclatura
Una nomenclatura consistente hace que los diagramas sean más fáciles de leer.
Eventos
Nombre de los eventos con un resultado, ocurrencia o condición:
-
Pedido Recibido
-
Pago Confirmado
-
Plazo Alcanzado
-
Cliente Canceló
-
Ocurrió un Error
Actividades
Uso:
Verbo + objeto
Ejemplos:
-
Revisar Contrato
-
Aprobar Solicitud
-
Actualizar Cuenta
-
Enviar Notificación
Pasarelas
Las pasarelas suelen ser más claras cuando se asocian con una pregunta:
-
¿Está completa la solicitud?
-
¿Está aprobado el pago?
-
¿Hay inventario disponible?
-
¿Ha pasado el plazo?
Las rutas de salida deben contener las respuestas:
-
Sí / No
-
Aprobado / Rechazado
-
Disponible / No disponible
Eventos finales
Nombre de los eventos finales según el resultado:
-
Pedido Completado
-
Solicitud Rechazada
-
Pago Fallido
-
Caso Cancelado
13. Elegir la puerta de enlace correcta
Utilice esta guía de decisión:
| Necesidad de modelado | Puerta de enlace a utilizar |
|---|---|
| Elija exactamente un camino basado en condiciones | Puerta de enlace exclusiva |
| Iniciar todos los caminos salientes | Puerta de enlace paralela |
| Elija uno o más caminos basado en condiciones | Puerta de enlace inclusiva |
| Siga el camino del primer evento que ocurra | Puerta de enlace basada en eventos |
| Aplicar reglas de enrutamiento altamente especializadas | Puerta de enlace compleja |
Una prueba mental rápida:
-
¿Un camino? Exclusiva
-
¿Todos los caminos? Paralela
-
¿Algunos caminos? Inclusiva
-
¿Primer evento? Basada en eventos
-
¿Lógica personalizada inusual? Compleja
14. Un ejemplo completo: Proceso de reembolso al cliente
Considere un proceso de reembolso al cliente.
Inicio: Solicitud de reembolso recibida
↓
Revisar solicitud de reembolso
↓
¿Es elegible la solicitud?
├── No
│ ↓
│ Enviar notificación de rechazo
│ ↓
│ Fin: Reembolso rechazado
│
└── Sí
↓
Aprobar reembolso
↓
Puerta de enlace paralela
├── Emitir reembolso
└── Actualizar cuenta del cliente
↓
Unión paralela
↓
Enviar confirmación de reembolso
↓
Fin: Reembolso completado
Este modelo demuestra:
-
Un evento de inicio de mensaje
-
Actividades de usuario o manuales
-
Una puerta exclusiva
-
Una ruta de rechazo
-
Una división paralela
-
Una unión paralela
-
Una actividad de confirmación
-
Diferentes resultados finales
Si el servicio de reembolso puede fallar, agregue un evento de error de borde a Emitir reembolso:
Emitir reembolso
│
└── Error → Crear caso de revisión manual
Si el reembolso debe completarse en cinco días hábiles, agregue un evento de temporizador de borde:
Emitir reembolso
│
└── Tiempo de espera de 5 días → Escalar reembolso
15. Una hoja de trucos compacta de símbolos BPMN
| Categoría de símbolo | Significado | Uso típico |
|---|---|---|
| Círculo delgado | Evento de inicio | Iniciar un proceso |
| Círculo doble | Evento intermedio | Esperar, enviar, recibir o reaccionar |
| Círculo grueso | Evento de fin | Terminar una ruta de proceso |
| Rectángulo redondeado | Tarea o actividad | Realizar trabajo |
| Rectángulo redondeado con más | Subproceso colapsado | Agrupar trabajo detallado |
| Rombo con X | Puerta exclusiva | Elegir un camino |
| Rombo con más | Puerta paralela | Ejecutar todos los caminos |
| Rombo con círculo | Puerta inclusiva | Ejecutar uno o más caminos |
| Rombo con marcador de evento | Puerta basada en eventos | Seguir el primer evento |
| Flecha sólida | Flujo de secuencia | Mostrar orden interno |
| Flecha discontinua | Flujo de mensaje | Mostrar comunicación |
| Conector punteado | Asociación | Vincular notas o datos |
| Piscina | Participante | Representar una organización o proceso |
| Carril | Rol o responsabilidad | Asignar propiedad |
| Forma de documento/dato | Objeto de datos | Mostrar la información utilizada o producida |
16. Principios finales de modelado
Los diagramas BPMN más efectivos siguen algunos principios básicos:
-
Utilice eventos para las cosas que ocurren.
-
Utilice actividades para el trabajo que realizan las personas o los sistemas.
-
Utilice compuertas para controlar o sincronizar rutas.
-
Utilice flujos de secuencia para el orden interno del proceso.
-
Utilice flujos de mensajes para la comunicación entre participantes.
-
Etiquete claramente las decisiones y las condiciones de salida.
-
Utilice subprocesos para controlar la complejidad.
-
Muestre la responsabilidad con carriles y pozos.
-
Utilice eventos de límite para tiempos de espera, errores e interrupciones.
-
Modele al nivel adecuado para la audiencia.
-
Proporcione un resultado claro a cada ruta significativa.
-
Prefiera diagramas simples y comprensibles sobre los excesivamente elaborados.
Una vez que estas tres ideas centrales se vuelven familiares—los eventos ocurren, las actividades se realizan y las compuertas controlan el flujo—la mayoría de los diagramas BPMN se vuelven mucho más fáciles de leer y crear.