El estándar de Modelo y Notación de Procesos de Negocio (BPMN; por sus siglas en inglés) proporciona a las organizaciones la capacidad de comprensión de sus procesos internos de negocio en una notación gráfica y la capacidad de comunicar sus procedimientos de manera estándar. Sin embargo, el uso del estándar no garantiza que los procesos se modelen de forma clara y eficaz; la forma en que los modeladores interpretan las condiciones de negocio y cómo definen su estructura, es crucial para asegurar que se entienden correctamente.
Esta sección proporciona modeladores de procesos algunas pautas para construir modelos claros y eficaces compatibles con el estándar BPMN.
Principios de modelado BPMN
Cuando se definen los diagramas de proceso que debe tomar en cuenta los siguientes principios básicos:
•1. Mantenga una secuencia lógica y clara
•3. Utilice un etiquetado estricto
Aplique patrones de procesos
No reinvente la rueda. los expertos de BPMN han trabajado en la definición de patrones de modelado para diferentes situaciones de negocios. Úselos para modelar las condiciones de negocio requeridas al tiempo que simplifica sus diagramas.
Para más información sobre los patrones de modelado por favor revise el documento de Patrones de Modelado de Procesos BPMN.
A continuación encontrará consejos útiles para seguir estos principios y ayudar a la definición correcta procesos y su comunicación.
1. Mantenga una secuencia lógica y clara
Esto pareciera ser obvio, pero es uno de los errores más comunes en el modelado de procesos. Los diagramas pueden se pueden difíciles de leer y muy confusos cuando la lógica de proceso no es explícita y clara. Las siguientes técnicas le ayudarán a mantener una secuencia lógica y clara en sus modelos.
Definir un comienzo y un final claro
En BPMN, comienzan y los eventos extremos son opcionales. Sin embargo, los procesos con los eventos de inicio y fin implícitas son indeseables y podrían dar lugar a malas interpretaciones.
Utilice eventos de inicio y final de cada proceso y subproceso para representar su comienzo y finalización.
Siga una dirección consistente del flujo
Haga visible la lógica del proceso en el diagrama. Evite las líneas cruzadas (conectores), mantenga una secuencia de tiempo y una dirección de flujo constante. La lectura diagrama será más fácil y su comunicación eficiente.
Mantenga claro el escenario principal
El escenario principal debe ser fácilmente identificado al leer el diagrama. Diagrame el escenario principal primero y luego los flujos alternativos.
Mantenga claros los escenario alternativos
BPMN ofrece las herramientas necesarias para representaren el diagrama la lógica del manejo de excepciones de forma explícita. Una vez que el escenario principal es diagramado, haga uso de los siguientes elementos para modelar los flujos alternativos según sea necesario:
Utilice procesos transaccionales
Los procesos transaccionales permiten escenarios de negocios con transacciones. Un conjunto de actividades debe realizarse con éxito, de lo contrario compensación o cancelación flujos son seguidos. Para más información ver subprocesos.
Distinga los estados finales exitosos y no exitosos
Utilice eventos finales separados para identificar cuando un proceso terminó con éxito y cuando no, para propósitos de documentación y revisión.
Mantenga un formato estándar
Mantenga un formato único a lo largo de sus diagramas y enfóquese en una apariencia limpia y agradable. El uso de diferentes tamaños de fuente, colores, dimensiones de cajas o etiquetas superpuestas podrían hacer que la lectura de los diagramas sea un desafío.
El estándar BPMN define los lineamientos utilizados para diagramar los procesos de negocio. Sin embargo, seguir las directrices de BPMN está completamente en sus manos. Asegúrese de que sus modelos cumplen con la norma para asegurar su correcta comprensión.
Una vez se ha definido la lógica del proceso, valide sus diagramas asegurándose de utilizar correctamente los diferentes elementos de BPMN. El siguiente aspecto debe ser revisado para cada elemento BMPN:
Lo que hay que revisar en Pools
•Diagrame los procesos completamente dentro de un Pool. Nunca diagrame flujos fuera de los límites de un Pool.
•Defina tantos Pools como procesos. Debe haber siempre al menos un Pool.
¿Qué verificar en Lanes?
•Cree un Lane solo si se ejecuta al menos una tarea o un evento intermedio en él.
•No cree Lanes para representar un área o una entidad que lleva a cabo un tarea automática o una compuerta.
•No diagrame tareas, compuertas o eventos en medio de dos Lanes.
¿Qué verificar en Actividades?
•No diagrame varias instancias de la misma tarea para representar a varios participantes. Sólo diagrame una tarea en un área. Defina los participantes como condiciones de asignación en la documentación y en reglas de asignación.
•No ramifique los flujos usando tareas. Siempre use las compuertas.
¿Qué verificar en compuertas?
•No use compuertas para juntar y separar al mismo tiempo. Esto producirá un error en tiempo de ejecución.
•Uso obligatorio de la compuerta exclusiva como elemento de convergencia.
•Siempre use el mismo tipo de compuerta para juntar los flujos que fue usado para dividirlos.
Cuando utilice Compuertas basadas en eventos, no utilice una Compuerta basada en eventos para juntar los flujos que fueron divididos.
•Use sólo Eventos y/o Tareas después de una compuerta basada en eventos.
¿Qué verificar en Eventos?
•Utilice eventos de terminación sólo cuando sea estrictamente necesario. Estos se utilizan para modelar situaciones donde se habilitan varios caminos alternativos y todo el proceso tiene que ser terminado cuando uno de ellos se ha completado.
Esto tiene una excepción descrita en el siguiente ítem.
•Use los Eventos de finalización terminal en vez de eventos de terminación en subprocesos embebidos.
¿Qué verificar en Conectores?
•Use flujos de secuencia para conectar todas las actividades, eventos y compuertas. Nunca use el flujo de mensajes para conectar las actividades del mismo Pool o deje formas sin conectar.
¿Qué verificar en Milestones?
•Siempre identifique y defina fases; estas representan un periodo de tiempo objetivo o una transición en el proceso.
•En lo posible, evite regresar entre Milestones.
3. Utilice un etiquetado estricto
El nombramiento correcto de los diferentes elementos de los diagramas es fundamental para una comprensión fácil y correcta de los procesos.
Al revisar los logs, es muy útil saber cómo se ejecutó el proceso. Cuando no se nombra alguna forma en el proceso, los Logs se muestran en blanco, lo que hace que sea difícil de entender. Estas son algunas recomendaciones que le ayudarán a hacerlo:
Etiquetas de los procesos
Los nombres de los procesos deben describir claramente su propósito principal. Asegúrese de no utilizar nombres cortos o abreviaturas.
Prefijo: utilizando el nombre de proceso, cree un prefijo que se utilizará en todos los componentes que pertenecen al proceso. Por ejemplo, si el nombre del proceso es: Solicitud del cliente, puede usar el prefijo SC_. Los siguientes prefijos están restringidos para otros fines: "P_", "M_".
Etiquetas de las actividades
Dé a las actividades un nombre compuesto por un verbo y un objeto. De esta manera los lectores puedan entender con claridad el objetivo de una tarea. Además, asegúrese de que usted no utiliza nombres cortos o abreviaturas.
Etiquetas de los Eventos
Utilice el etiquetado cuando se utilizan múltiples eventos de inicio y fin. Nómbrelos para que el diagrama puede explicarse por sí mismo y permitir que los usuarios sepan cómo termina el proceso.
Al etiquetar eventos de temporización recomendamos no especificar la cantidad de tiempo del evento, en cambio, describir el evento esperado o el propósito del tiempo dado.
Para las compuertas convergentes y basadas en eventos sugerimos etiquetarlas con el prefijo del tipo de compuerta y un numero serial (p. ej. la primera compuerta exclusiva convergente sería EX01). En la siguien tabla se muestran los prefijos de las compuertas:
Type |
Label |
Compuerta Exclusiva |
EX |
Compuerta Paralela |
P |
Compuerta Compleja |
C |
Compuerta Inclusiva |
I |
Compuerta Basada en Eventos |
EV |
Etiquetas de los Milestones
Los Milestones deberían ser nombrados 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 las Compuertas
Las compuertas de divergencia deben tener un nombre que indique claramente la decisión o condición evaluada cuando aplique. Utilice un nombre compuesto por un verbo, un objeto, y un signo de interrogación para identificar lo que se está evaluando. Usted puede incluso utilizar preguntas para aclarar la decisión en cuestión.
•Si no aplica tener un nombre para la compuerta, use abreviaciones o números para diferenciarlas.
•Nombre las transiciones indicando la condición relacionada
Los diagramas grandes no permiten dar una perspectiva de extremo a extremo para los lectores. Son difíciles de leer y el propósito del proceso es difícil de comunicar.
Es fundamental definir el alcance correcto de las tareas y el nivel de detalle de los procesos para reducir el exceso de información. Los siguientes consejos le ayudarán:
Reduzca el número de tareas redundantes
El nivel de detalle en un proceso a veces es un verdadero reto. En muchos casos, usted puede enfrentar dificultades para definir el alcance de una sola tarea. Tome en cuenta que:
•Cuando diagrame, es útil imaginar que usted es el usuario final. Si un conjunto de actividades consecutivas puede ser realizada por la misma persona, al mismo tiempo, entonces estas actividades podrían integrarse en una sola actividad.
•Un conjunto de actividades consecutivas en el mismo Lane puede indicar falta de un participante, demasiado detalle, o un desajuste el alcance de las tareas. Revise estos patrones para identificar oportunidades de la integración de la actividad.
Agrupe las actividades
Utilice subprocesos para agrupar actividades con el mismo propósito. Después, puede ampliar los subprocesos para exponer los detalles de los niveles inferiores de la jerarquía. Un proceso contendrá varias páginas, pero internamente, se mantiene la integridad de un modelo único.
Utilice subprocesos embebidos cuando:
•Un conjunto de actividades consecutivas tiene un propietario diferente del propietario del proceso principal (por ejemplo, un proceso de Solicitud de Compra se realiza el área de Compras y el proceso de Cuentas por Pagar se realiza el área Financiera).
•Un conjunto de actividades consecutivas tiene un objetivo diferente al del proceso principal (por ejemplo, Solicitud de Crédito se centra en la gestión de todas las actividades para aprobar una solicitud de crédito y Verificar la información del solicitante se centra en comprobar si el solicitante está en lista negra, así como la información presentada).
Utilice subprocesos reutilizables cuando:
•El subproceso debe ser invocado desde diferentes procesos (por ejemplo, el subproceso Verificar la información del solicitante se puede invocar desde el proceso de Solicitud de Crédito o desde Solicitud de Seguros).
Utilice Formas de Inicio
Use Formas de Inicio para comenzar un nuevo caso de instancia temporal, y permita a los usuarios finales confirmar la creación del proceso cuando ellos sean conscientes de dicha acción, o cuando cierren la forma sin enviar una confirmación, evitando la creación innecesaria de casos.
No utilice antipatrones
Mientras simplificar sus modelos tenga en cuenta no utilizar Antipatrones. Estos son patrones de modelado que se usan generalmente en la automatización, pero son malas prácticas que no son recomendados por Bizagi
Documente los detalles menores
Deje los detalles a la documentación. No incluya toda la información en diagramas. La información adicional debe ser documentada como propiedades de forma, no como objetos o texto en el diagrama.