Guía de BPMN con Visual Paradigm

1. Qué es BPMN

Modelo y notación de procesos de negocio (BPMN) es un lenguaje visual estandarizado para describir cómo se mueve el trabajo a través de un proceso. Ayuda a las partes interesadas del negocio, analistas y equipos técnicos a discutir el mismo flujo de trabajo utilizando símbolos consistentes. BPMN es mantenido por el Object Management Group; BPMN 2.0.2 se publica como ISO/IEC 19510.

Un diagrama BPMN es más que un diagrama de flujo: sus símbolos tienen significados definidos y sus reglas de conexión distinguen el flujo del proceso de los mensajes entre participantes. Un modelo útil puede documentar el proceso actual («como está»), aclarar un proceso propuesto («como debería ser») y ayudar a los equipos a identificar retrasos, transferencias, retrabajos o rutas de excepción faltantes.

2. Conceptos fundamentales de BPMN

Los bloques de construcción principales de BPMN son objetos de flujo, objetos de conexión, carriles, datos y artefactos.

Eventos

El contorno y el marcador de un evento transmiten su función y disparador:

• Evento de inicio:inicia una ruta de proceso.

• Evento intermedio:ocurre durante el proceso, por ejemplo, un mensaje recibido o la expiración de un temporizador.

• Evento de finalización:finaliza una ruta. Diferentes tipos de eventos de finalización pueden indicar diferentes resultados, como una finalización normal o un error.

• Evento de borde:adjunto a una actividad o subproceso para mostrar un evento que puede interrumpirlo o afectarlo, como un tiempo de espera agotado.

Utilice un evento de mensajecuando el proceso responde a una comunicación, y un evento de temporizadorcuando el tiempo es parte de la regla del proceso, como un plazo.

Actividades

Nombre de las actividades con un claro verbo + objeto, como «Verificar inventario», «Aprobar pago» o «Enviar confirmación». Utilice:

• Tareapara un único paso.

• Subprocesocuando un paso tiene suficiente detalle para modelarse por separado.

• Actividad de llamadacuando se reutiliza un proceso definido globalmente, si su enfoque de modelado lo permite.

Los marcadores de tarea comunes pueden especificar el tipo de trabajo, como trabajo realizado por el usuario, manual o automatizado. Añada este detalle solo cuando ayude a los lectores o a la implementación.

Puertas de bifurcación

Elija una puerta de bifurcación según la lógica del proceso, no solo por la forma que desea dibujar:

• Exclusiva (XOR): tome una de las rutas de salida. Ejemplo: «¿En stock?» → Sí o No.

• Paralela (AND): inicie todas las rutas de salida; una unión correspondiente puede esperar a que todas las rutas requeridas estén disponibles.

• Inclusiva (OR): tome una o más rutas de salida, según las condiciones.

• Basada en eventos: la siguiente ruta se determina según qué evento ocurra primero, como una respuesta de pago o un tiempo de espera agotado.

Etiquete los flujos de decisión de salida con condiciones, como Sí / No o Aprobado / Rechazado. Cuando una puerta de bifurcación divide un flujo, aclare la lógica de unión. Una unión exclusiva vuelve a unir rutas alternativas; una unión paralela sincroniza rutas que se iniciaron en paralelo.

Conexión de objetos y pools

Un flujo de secuencia muestra el orden del proceso y normalmente se mantiene dentro de un solo pool. Un flujo de mensaje muestra la comunicación entre pools separados, por ejemplo, un cliente enviando un pedido a una empresa. No utilice un flujo de mensaje para mostrar la siguiente tarea interna, ni un flujo de secuencia para representar la comunicación entre participantes separados.

Los pools pueden representar participantes independientes, como un cliente, una empresa y un proveedor de pagos. Los carriles dentro de un pool muestran roles o departamentos. Mantenga los límites de responsabilidad significativos: un carril debe aclarar quién realiza el trabajo, no simplemente decorar el diagrama.

3. Un flujo de trabajo de modelado práctico

1. Defina el alcance. Establezca el desencadenante, el resultado y los límites del proceso. Por ejemplo: «Desde la recepción de un pedido hasta la confirmación del envío.»

2. Identifique los participantes y los roles. Decida qué participantes necesitan pools separados y qué responsabilidades pertenecen a los carriles.

3. Describa el camino feliz. Liste los pasos ordinarios en orden antes de agregar puertas de bifurcación y rutas de excepciones.

4. Agregue eventos y decisiones.Muestre desencadenantes significativos, resultados, reglas de negocio y rutas alternativas.

5. Agregue transferencias de tareas y datos.Marque las comunicaciones entre participantes y la información necesaria o producida donde mejore la comprensión.

6. Verifique la integridad.Rastree cada ruta desde un inicio hasta un final. Confirme que las compuertas tengan condiciones comprensibles y que las rutas de excepción no desaparezcan de manera ambigua.

7. Revise con los usuarios del proceso.Valide el modelo con las personas que realizan o reciben el trabajo. Revíselo cuando difiera de la práctica real.

8. Mantenga el diagrama legible.Utilice una nomenclatura consistente, minimice las líneas que se cruzan y mueva los subprocesos detallados a diagramas separados cuando sea necesario.

Comience con un modelo que responda a la pregunta de negocio. Agregar todos los símbolos BPMN o detalles de implementación de una sola vez a menudo hace que el diagrama sea más difícil de revisar.

4. Ejemplo: cumplimiento de pedidos en línea

Alcance:Desde el envío del pedido por parte del cliente hasta la confirmación del envío. Este ejemplo se centra en el proceso de la empresa y utiliza un pool de clientes separado para mostrar el pedido entrante y la confirmación saliente.

Narrativa del proceso

1. El cliente presenta un pedido.

2. La empresa recibe el pedido y verifica el inventario.

3. Si un artículo no está disponible, la empresa notifica al cliente y finaliza esa ruta de pedido.

4. Si el artículo está disponible, la empresa procesa el pago.

5. Si el pago es rechazado, la empresa notifica al cliente y finaliza esa ruta.

6. Si el pago es aprobado, el almacén selecciona y embala el pedido.

7. La empresa entrega el paquete al transportista y envía una confirmación de envío.

Diagrama de texto

Pool de cliente:
(Inicio) → Presentar pedido ──mensaje──▶

Pool de empresa:
(Inicio por mensaje: pedido recibido)
  → Verificar inventario
  → XOR: ¿En stock?
      No  → Notificar al cliente: no disponible → (Fin)
      Sí → Procesar pago
             → XOR: ¿Pago aprobado?
                 No  → Notificar al cliente: pago rechazado → (Fin)
                 Sí → Seleccionar y embalar pedido
                         → Entregar paquete al transportista
                         → Enviar confirmación de envío ──mensaje──▶ Cliente
                         → (Fin)

Código PlantUML personalizado para BPMN (Solo compatible con el editor VPasCode)

@startuml
título Diagrama de proceso de negocio de cumplimiento de pedidos
<style>
    elemento { AnchoMaximo 160 }
    inicio   { ColorFondo #00695C }
    fin    { ColorFondo #C2185B }
    actividad{ ColorFondo #81D4FA; AnchoMaximo 150 }
    diamante { ColorFondo #FFB74D; AnchoMaximo 80 }
    flecha   { ColorLinea #424242; ColorFuente #000000 }
    carril{ ColorFuente #000000; TamañoFuente 14 }
</style>

|#F0F8FF|Cliente|
inicio
:<<TareaEnviar>>
Presentar pedido;

|#E8F5E9|Empresa|
:<<TareaRecibir>>
Pedido recibido;
:<<TareaUsuario>>
Verificar inventario;
if (¿En stock?) then (sí)
  :<<TareaServicio>>
  Procesar pago;
  if (¿Pago aprobado?) then (sí)
    :<<TareaManual>>
    Seleccionar y embalar pedido;
    :<<TareaEnviar>>
    Entregar paquete al transportista;
    :<<TareaEnviar>>
    Enviar confirmación de envío;
  else (no)
    :<<TareaEnviar>>
    Notificar al cliente: pago rechazado;
  endif
else (no)
  :<<TareaEnviar>>
  Notificar al cliente: no disponible;
endif
fin
@enduml

Usar flujos de secuencia para los pasos internos de la empresa y flujos de mensaje entre las piscinas de Cliente y Empresa. Etiquetar los flujos salientes de cada puerta XOR con sus condiciones. En Visual Paradigm, las preguntas «¿Hay stock?» y «¿Pago aprobado?» pueden colocarse como etiquetas de puerta, mientras que las flechas salientes llevan «Sí» y «No».

Posibles extensiones: Añadir un evento de borde de temporizador al procesamiento de pagos si la empresa tiene un plazo de pago; añadir un camino de excepción para un fallo en la entrega al transportista; o modelar la preparación y el embalaje como un subproceso si requiere su propio flujo de trabajo detallado.

5. Construcción del modelo en Visual Paradigm

Visual Paradigm proporciona una herramienta de modelado BPMN 2.0 y admite el desglose de subprocesos, por lo que un proceso de alto nivel puede vincularse a un diagrama de proceso más detallado. Sus características BPMN también incluyen documentar procedimientos de trabajo y modelar procesos «como están» y «como deberían estar».

Una secuencia práctica de construcción:

1. Crear un Diagrama de proceso de negocio BPMN en Visual Paradigm.

2. Añadir una piscina de Cliente y una piscina de Empresa; dividir la piscina de Empresa en carriles como Servicio al Cliente, Almacén y Envío si esas responsabilidades son relevantes.

3. Colocar el evento de inicio y las actividades, y luego añadir las puertas de inventario y de pago.

4. Dibujar flujos de secuencia dentro de la piscina de Empresa; usar flujos de mensaje para los intercambios con el Cliente.

5. Etiquetar tareas y caminos condicionales en lenguaje claro. Añadir objetos de datos, como un Pedido o un Resultado de Pago, solo donde ayuden a los lectores a comprender el proceso.

6. Organizar el diagrama de modo que el flujo principal se lea de forma coherente, generalmente de izquierda a derecha, y minimizar los conectores que se cruzan.

7. Revisar el diagrama con las partes interesadas. Si el detalle de un paso oscurece el camino principal, considerar colocar ese detalle en un diagrama de subproceso.

8. Guardar y compartir el modelo en el formato y espacio de trabajo adecuados para su equipo.

Visual Paradigm anuncia el modelado de diagramas BPMN, el desglose de procesos, la documentación de procedimientos de trabajo y el modelado «como están»/«como deberían estar». La disponibilidad de capacidades específicas puede depender de la edición.

6. Errores comunes de modelado

• Usar el conector incorrecto: El flujo de secuencia es el orden interno del proceso; el flujo de mensaje es la comunicación entre participantes.

• Usar una puerta sin lógica clara: etiquete la decisión y sus condiciones de salida.

• Tratar cada acción como un pool separado: use carriles para las responsabilidades dentro de un mismo participante; pools separados para participantes distintos.

• Dejar los caminos poco claros: muestre qué ocurre en caso de rechazos, tiempos de espera agotados, información faltante y otras excepciones relevantes.

• Sobrecargar un solo diagrama: use subprocesos para separar el trabajo detallado de la visión general.

• Modelar el ideal en lugar de la realidad: documente el proceso actual con precisión antes de proponer mejoras.

• Añadir detalles sin propósito: incluya datos, eventos y marcadores de tarea cuando respondan a una pregunta de modelado o revisión.

7. Lista de verificación rápida de revisión

• ¿El diagrama tiene un inicio y un final claros para cada camino relevante?

• ¿Puede un lector identificar quién realiza cada actividad?

• ¿Son explícitas las decisiones y las condiciones de salida?

• ¿Se utilizan los flujos de secuencia y los flujos de mensaje de manera apropiada?

• ¿Están representadas las excepciones y los resultados alternativos?

• ¿Es legible el diagrama en el tamaño de visualización previsto?

• ¿Han confirmado las personas que realizan el proceso que es preciso?