El estándar BPMN (Business Process Model and Notation) brinda a las organizaciones la capacidad de entender sus procesos de negocio a través de una notación gráfica, así como la habilidad de comunicar sus procedimientos de manera estandarizada. Sin embargo, la utilización del estándar no garantiza que los procesos se modelen de forma clara y efectiva; la forma en que los modeladores de procesos interpreten las condiciones de negocio y definan la estructura de los mismos, es crucial para asegurar su correcto entendimiento.
Este artículo brinda a los modeladores de proceso algunos lineamientos que ayudarán a la construcción de modelos claros, de fácil comunicación y alineados con el estándar BPMN.
Principios de modelamiento BPMN
Al momento de construir diagramas de proceso, tenga en cuenta estos principios básicos:
•1. Mantenga una secuencia lógica y clara
•3. Nombre claramente los elementos
A continuación encontrará puntos útiles para seguir estos principios y conseguir una adecuada definición y comunicación de sus procesos.
1. Mantenga una secuencia lógica y clara
Este principio parece ser obvio, pero es uno de los errores más comunes al modelar procesos. Los diagramas pueden volverse confusos cuando la lógica no es explicita y clara. Los siguientes puntos le ayudarán a mantener una secuencia lógica y clara en sus modelos.
Defina un inicio y fin claro
En BPMN, los eventos de inicio y de fin son opcionales. Sin embargo, los procesos con inicio y fin implícito no son deseables y pueden confundir a lo lectores.
Utilice los eventos de inicio y fin en cada proceso y subproceso para representar su comienzo y finalización.
Siga una dirección consistente en el flujo
Haga visible la lógica del proceso en el diagrama. Evite el cruce de conectores, mantenga una secuencia cronológica y una dirección consistente del flujo. La lectura del diagrama será más clara y su comunicación más eficiente.
Mantenga claro el escenario primario
El camino principal debería ser fácilmente identificado al leer el diagrama. Diagrame el camino principal primero y luego agregue los caminos alternativos.
Mantenga claros los escenarios alternativos
BPMN ofrece las herramientas necesarias para representar la lógica de manejo de excepciones de manera explicita en los diagramas. Una vez que se ha diagramado el escenario principal, haga uso de los siguientes elementos para modelar los flujos alternativos según lo requiera:
Utilice eventos adjuntos a actividades
Si un evento se adjunta a los límites de una actividad, cambiará el flujo normal hacia un flujo de excepción, cuando algo suceda (se reciba un mensaje, se cumpla una condición, se cumpla un tiempo, etc). Para mayor información consulte Eventos adjuntos
Utilice procesos transaccionales
Los procesos transaccionales permiten modelar escenarios de negocio con transacciones. Un conjunto de actividades debe ser completado exitosamente, de lo contrario, se siguen flujos de compensación o cancelación. Para mayor información consulte Tipos de subproceso
Distinga estados finales de exitosos y no exitosos
Utilice eventos de finalización separados para identificar cuándo un proceso ha sido finalizado exitosamente y cuándo no.
Mantenga un formato
Mantenga un formato único a lo largo de sus diagramas y enfóquese en una apariencia limpia y amigable. Utilizar diferentes tamaños de fuente, dimensiones de cajas o sobreponer etiquetas puede hacer de la lectura de los diagramas todo un reto.
2. Utilice el estándar BPMN
El estándar BPMN define los lineamientos utilizados para diagramar procesos de negocio. Sin embargo, el seguimiento de estos lineamientos esta completamente en sus manos. Asegúrese de que sus modelos cumplen con el estándar para asegurar su adecuado entendimiento.
Una vez que la lógica del proceso ha sido definida, valide sus diagramas asegurándose que utilizar adecuadamente los diferentes elementos BPMN. Los siguientes aspectos deberían ser verificados en cada elemento:
Aspectos a verificar en Contenedores
•Diagrame los procesos completamente dentro de un Contenedor. Nunca diagrame flujos fuera de los límites de un Contenedor.
•Defina tantos Contenedores como procesos. Siempre debe haber al menos un Contenedor.
Aspectos a verificar en Carriles
•Cree un Carril solo si al menos una tarea o evento intermedio se ejecuta en él.
•No cree Carriles para representar el área o entidad que desempeña tareas automáticas.
•No diagrame tareas, compuertas o eventos en medio de dos Carriles.
Aspectos a verificar en Actividades
•No diagrame múltiples instancias de la misma tarea para representar múltiples participantes. Solo diagrame una tarea en un área. Defina los múltiples participantes como condiciones de asignación en la documentación.
•No ramifique flujos utilizando tareas. Siempre use compuertas para este fin.
Aspectos a verificar en Compuertas
•No use compuertas para unir o separar flujos al mismo tiempo.
•Balancee las compuertas. Las ramificaciones de flujo deben ser sincronizadas equivalentemente.
•Para sincronizar flujos utilice siempre el mismo tipo de compuerta utilizado para ramificarlos.
Aspectos a verificar en eventos
•Siempre use eventos de inicio y de fin.
•Utilice eventos de fin terminal solo cuando sea estrictamente necesario. Estos se utilizan para modelar situaciones donde múltiples caminos alternativos son habilitados y solo se requiere la finalización de uno de ellos para finalizar todo el proceso.
Aspectos a verificar en Conectores
•Utilice flujos de secuencia para conectar todas las actividades, eventos y compuertas. Nunca utilice flujos de mensaje para conectar actividades dentro del mismo Contenedor o deje elementos sin conectar.
•Nunca utilice flujos de secuencia para conectar elementos de diferentes Contenedores. Utilice flujos de mensaje para representar intercambio de información entre procesos.
Aspectos a verificar en Fases
•Siempre identifique y defina fases; estas representan un periodo de tiempo, objetivo o transición en el proceso.
•Evite regresar hacia etapas previas.
3. Nombre claramente los elementos
Un correcto nombramiento de los diferentes elementos de los diagramas es fundamental para un fácil y correcto entendimiento de los procesos. Aquí algunas recomendaciones para hacerlo.
Etiquetas de Procesos
Los nombres de los procesos deberían describir claramente su principal propósito, Asegúrese de no utilizar nombres cortos ni abreviaciones.
Etiquetas de Actividades
Nombre las actividades con un verbo, y un objeto. De esta manera podrá identificarse claramente el objetivo de la tarea. Asegúrese de no utilizar nombres cortos ni abreviaciones.
Etiquetas de Eventos
No etiquete los eventos de inicio y de fin cuando son únicos. Es muy común nombrarlos como "Inicio del proceso" y "Fin del proceso" pero esto es redundante e innecesario.
•Nombre los eventos cuando se utilicen múltiples eventos de inicio o de fin. Nómbrelos de acuerdo con lo que representan utilizando un nombre. Evite repetir nombres.
Etiquetas de Fases
Las Fases deberían ser nombradas con un sustantivo que haga referencia a un periodo de tiempo (verano, madurez) o a lo que suceda en un periodo de tiempo (creación, aprobación, entrega).
Etiquetas de Compuertas
La compuertas de divergencia deberían tener un nombre claro que indique la decisión o condición evaluada, cuando esto aplique. Puede incluso utilizar preguntas para clarificar la decisión involucrada.
•Si no aplican nombres para una compuerta, utilice abreviaciones o números para diferenciarlas.
•Nombre las transiciones indicando la condición relacionada.
4. Simplifique los diagramas
Los diagramas extensos no permiten dar una perspectiva global a los lectores. Dificultan la lectura y la facilidad para comunicar claramente el propósito de los procesos.
La definición correcta del alcance de las tareas y el nivel de detalle de los procesos es clave para reducir el exceso de información. Los siguientes puntos ayudarán a simplificar sus diagramas.
Reduzca el número de tareas redundantes
Definir el nivel de detalle en un proceso es algunas veces todo un reto. En muchos casos, usted puede enfrentar dificultades para definir el alcance de una tarea, Tenga en cuenta que:
•Cuando se diagrama es útil imaginar que usted es un usuario final. Si un conjunto de tareas consecutivas puede ser ejecutado por la misma persona, al mismo tiempo, entonces estas actividades deberían integrarse en una sola.
•Un conjunto de actividades consecutivas en el mismo Carril puede indicar falta de un participante, alto nivel de detalle, o una desalineación en el alcance de las tareas. Revise estos patrones para identificar oportunidades de integración de actividades.
Agrupe las actividades
Utilice subprocesos para agrupar actividades con el mismo propósito. Puede ampliar los subprocesos más adelante para exponer los detalles de los niveles inferiores de jerarquía. Un proceso podría contener varias páginas, pero internamente se mantiene la integridad de un modelo único.
Utilice subprocesos embebidos cuando:
•Un conjunto de actividades consecutivas tiene un dueño diferente al del proceso principal (por ejemplo, un proceso de solicitud de compra es realizado por el área de compras y el proceso de Pago de cuentas es llevado a cabo por el área financiera).
•Un conjunto de actividades consecutivas tiene un objetivo diferente al del proceso principal ( por ejemplo, una solicitud de crédito se centra en la gestión de todas las actividades para aprobar una solicitud de crédito y el proceso de verificación de la información del solicitante se centra en comprobar si el solicitante está reportado en las centrales de riesgo) .
Utilice subprocesos reusables cuando:
•El sub - proceso debe ser invocado desde diferentes procesos (por ejemplo, un subproceso de Verificar información del solicitante puede ser invocado desde un proceso de solicitud de crédito o de un proceso de solicitud de seguros) .
Aplique patrones de proceso
No reinvente la rueda. Expertos BPMN han trabajado en la definición de patrones de modelamiento para diferentes situaciones de negocio. Utilícelos para modelar sus condiciones de negocio mientras simplifica sus diagramas.
Para mayor información acerca de los patrones de modelamiento consulte el Documento de patrones de modelamiento BPMN
Documente los detalles menores
Deje los detalles para la documentación. No incluya toda la información en los diagramas. La información adicional debería ser documentada en las propiedades de los elementos y no como objetos o texto en los diagramas.