Mejores prácticas en modelado de procesos

<< Click to Display Table of Contents >>

Navigation:  Bizagi Studio > Mejores prácticas y recomendaciones de implementación >

Mejores prácticas en modelado de procesos

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

2. Utilice el estándar BPMN

3. Utilice un etiquetado estricto

4. Simplifique los diagramas

 

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.

 

BestPractices1

 

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.

 

BestPractices2

 

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.

 

BestPractices3

 

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.

 

BestPractices23

 

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.

 

BestPractices4

 

 

2. Utilice el estándar BPMN

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.

 

BestPractices6

 

Defina tantos Pools como procesos. Debe haber siempre al menos un Pool.

 

BestPractices5

¿Qué verificar en Lanes?

Cree un Lane solo si se ejecuta al menos una tarea o un evento intermedio en él.

 

BestPractices7

 

No cree Lanes para representar un área o una entidad que lleva a cabo un tarea automática o una compuerta.

 

BestPractices8

 

No diagrame tareas, compuertas o eventos en medio de dos Lanes.

 

BestPractices9

 

¿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.

 

BestPractices10

 

No ramifique los flujos usando tareas. Siempre use las compuertas.

 

BestPractices22

 

¿Qué verificar en compuertas?

No use compuertas para juntar y separar al mismo tiempo. Esto producirá un error en tiempo de ejecución.

 

BestPractices18

 

Balancee las compuertas. Las divisiones deben unirse de manera equivalente.

 

BestPractices20

 

Siempre use el mismo tipo de compuerta para juntar los flujos que fue usado para dividirlos.

 

BestPractices21

 

Use sólo Eventos y/o Tareas después de una compuerta basada en eventos.

 

Bestpractices30

 

¿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.

 

BestPractices11

 

Use los Eventos de finalización terminal en vez de eventos de terminación en subprocesos embebidos.

 

Good practices23

¿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.

 

BestPractices12

 

¿Qué verificar en Milestones?

Siempre identifique y defina fases; estas representan un periodo de tiempo objetivo o una transición en el proceso.

 

BestPractices13

 

En lo posible, evite regresar entre Milestones.

 

BestPractices14

 

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.

 

BestPractices15

 

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.

 

BestPractices27

 

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).

 

BestPractices13

 

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.

 

BestPractices25

 

Si no aplica tener un nombre para la compuerta, use abreviaciones o números para diferenciarlas.

 

BestPractices28

 

Nombre las transiciones indicando la condición relacionada

 

BestPractices26

 

4. Simplifique los diagramas

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.

 

BestPractices24

 

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).

 

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.

 

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.