Para simplificar un diagrama de flujo complejo, separa la vista general del detalle. Mantén las etapas principales y los resultados importantes en un diagrama superior, traslada los pasos internos de una etapa a un subproceso con nombre e indica exactamente cómo empieza y a dónde devuelve sus resultados.
No empieces reduciendo la letra ni eliminando las excepciones. Un diagrama puede parecer más limpio y, al mismo tiempo, resultar menos útil. El objetivo es seguir el recorrido principal sin perder los detalles necesarios para hacer el trabajo.
Identifica por qué cuesta leer el diagrama
Antes de mover los bloques, identifica el problema. El diagrama puede mezclar grandes etapas con clics individuales, repetir las mismas comprobaciones en varias ramas o colocar todas las excepciones en el recorrido principal. Puedes editar la vista general y los diagramas detallados juntos en Boardmix, manteniendo visibles sus conexiones.
Piensa en la pregunta que necesita responder cada lector:
- «¿Qué pasa con mi solicitud?» requiere las etapas principales, los puntos de espera y los finales posibles.
- «¿Qué debo hacer en esta etapa?» requiere acciones, decisiones, entradas y traspasos.
- «¿Por qué falló este caso?» requiere la excepción correspondiente y los datos que determinan su recorrido.
Intentar responder las tres preguntas al mismo nivel visual suele crear el enredo. Varias vistas pueden compartir el mismo proceso sin obligar a todos a inspeccionar cada paso.
Si el único problema son las líneas desordenadas, alinea los bloques y reduce los cruces primero. Un proceso breve y coherente no necesita varias páginas para parecer organizado. Divide una sección cuando sus detalles distraigan del flujo general y tenga una entrada y un resultado con sentido propio.
Define los límites antes de decidir qué ocultar
El procedimiento de ASQ para crear diagramas de flujo comienza por el alcance, el inicio, el final y el nivel de detalle necesario. Aplica ese principio antes de mover nada: escribe qué entra en el proceso y qué significa haberlo terminado.
En el ejemplo hipotético de este artículo, el alcance va desde el envío de una solicitud de gastos por parte de un empleado hasta su resolución y, si se aprueba, su entrega a finanzas. El pago queda fuera. Por eso, «Enviada a finanzas» no debe cambiarse por «Reembolsada».
Un diagrama original saturado podría incluir abrir la solicitud, leer un recibo, comprobar los datos exigidos, pedir un documento ausente, revisar la respuesta, enviar a aprobación, registrar la decisión, avisar al empleado y remitir el expediente aprobado. Todas son actividades útiles, pero no todas pertenecen a la vista general.
Conserva el diagrama original como referencia durante la reorganización. Este ejercicio cambia la forma de explicar el proceso, no la política de aprobación. Las propuestas de cambios operativos deben ir en una versión claramente separada.
Crea una vista general con resultados claros
Agrupa el ejemplo en tres etapas. Asigna un identificador estable a cada una para que se pueda encontrar el detalle aunque cambies los bloques de sitio.
- P1 — Comprobar la documentación. Determina si está presente la información justificativa requerida. Devuelve «Lista para revisión» o «Retirada». Una solicitud pendiente de información permanece dentro de P1.
- P2 — Revisar la solicitud. La persona autorizada registra la aprobación o el rechazo. Si se rechaza, el proceso termina como solicitud rechazada, sin enviarla a finanzas.
- P3 — Enviar el expediente aprobado a finanzas. Transfiere la solicitud aprobada y su documentación. El diagrama acaba en esa entrega, no en el pago.
La vista general muestra ahora el recorrido principal: Enviada → P1 → P2 → P3 → Enviada a finanzas. Conserva también dos salidas importantes: Retirada desde P1 y Rechazada desde P2. Ninguna queda escondida en un bloque genérico de «Completada».
No elimines un resultado porque sea poco frecuente. La vista general debe conservar los resultados que cambian lo que espera el siguiente participante. Las comprobaciones internas menores pueden pasar al detalle; la diferencia entre aprobación y rechazo no.
Desarrolla P1 sin cambiar su significado
Coloca una breve definición encima del diagrama detallado. Debe explicar qué se compromete a hacer el subproceso:
- Entrada: una solicitud enviada, con su identificador y la documentación aportada.
- Propósito: determinar si está presente la documentación requerida.
- Resultados de salida: Lista para revisión o Retirada.
- Estado de espera: Pendiente de información. No equivale a una finalización correcta.
A continuación, dibuja el flujo interno:
- P1.1 — Leer la solicitud y los documentos. Utiliza la lista de información exigida para ese tipo de solicitud.
- P1.2 — ¿Está completa la documentación? Si lo está, marca la solicitud como Lista para revisión y envíala a P2.
- P1.3 — Pedir la información que falta. Indica el documento o dato concreto, en lugar de enviar un «Rechazada» sin explicación.
- P1.4 — Esperar la respuesta del empleado. Un expediente corregido vuelve a P1.1. Una retirada explícita devuelve Retirada. Si no hay respuesta, la solicitud permanece Pendiente de información hasta que el procedimiento real de seguimiento indique otra cosa.
Un expediente puede estar completo sin estar aprobado. P1 comprueba la documentación; P2 toma la decisión sobre la solicitud. Fundir ambos significados en un bloque llamado «Validar» recrearía la ambigüedad inicial.
El estado de espera tampoco es un bucle que envía la misma petición una y otra vez. Pausa el proceso hasta recibir una respuesta externa. Si la organización tiene reglas de recordatorio o cierre, representa sus condiciones reales, sin inventar un plazo para completar el dibujo.
Facilita el paso entre la vista general y el detalle
Etiqueta la etapa superior como «P1 — Comprobar la documentación» y el mapa ampliado como «Detalle de P1». Usa los mismos términos para la entrada y las salidas en ambos. Si la vista general dice «Lista para revisión» pero el detalle devuelve «Aprobada», el lector no sabrá si son el mismo estado.
Coloca el detalle cerca de su etapa en el lienzo compartido, o añade una referencia explícita si vive en otro documento. Un conector etiquetado «Detalle de P1» resulta más claro que una flecha sin nombre que desaparece en el borde. La referencia debe permitir encontrar el detalle sin preguntar al autor.
Puedes utilizar un símbolo de proceso predefinido si encaja con la notación del equipo, pero la etiqueta y la conexión importan más que una forma decorativa. Si la organización utiliza una notación formal como BPMN, respeta sus reglas de subprocesos en lugar de mezclar convenciones sin criterio.
Dentro de una vista detallada, mantén un nivel similar. «Revisar la solicitud» y «Hacer clic en el icono de adjunto» no deberían ser etapas equivalentes salvo que el documento sea una guía operativa de pantalla. Lleva las instrucciones de clic a notas de apoyo o a una guía de tarea separada.
Recorre tres casos en ambas vistas
Elige casos que revelen la diferencia entre las vistas. No son nuevos pasos: sirven para comprobar si la reorganización conserva el proceso.
| Caso | Comportamiento detallado | Qué muestra la vista general |
|---|---|---|
| Documentación completa; solicitud aprobada | P1.1 y P1.2 devuelven Lista para revisión. | P1 → P2 → P3 → Enviada a finanzas. |
| Falta un recibo; el empleado lo aporta; la solicitud se rechaza | P1.3 pide el recibo. P1.4 lo recibe y vuelve a P1.1. | P1 termina como Lista para revisión. P2 devuelve Rechazada; nunca se entra en P3. |
| El empleado retira la solicitud mientras falta información | P1.4 devuelve Retirada. | La solicitud termina como Retirada, no Lista para revisión ni Aprobada. |
El segundo caso contiene un bucle en el detalle, pero no necesita una flecha que cruce toda la vista general. Esta sigue siendo fiel al proceso: la solicitud permanece en la comprobación documental hasta que esté lista o se retire.
Si no puedes recorrer un caso real, averigua si un paso se trasladó o se eliminó por error. Compara el original, los resultados del diagrama superior y las salidas del detalle. Corrige la discrepancia antes de pulir la composición.
Evita sustituir un diagrama saturado por un laberinto de diagramas
Dividir cada pocos bloques crea otro problema: el lector dedica más esfuerzo a buscar el siguiente diagrama que a entender el proceso. Mantén juntas las etapas coherentes. Un subproceso debe tener una razón de ser, como una responsabilidad clara, una operación reutilizable o una lógica interna considerable.
Si una comprobación se repite, confirma primero que es realmente la misma. «Confirmar la identidad antes de cambiar el acceso» y «Comprobar que la solicitud incluye un identificador de cliente» cumplen funciones distintas. Un nombre parecido no basta para unirlas.
En este ejemplo, coloca el flujo general en la parte superior del lienzo de Boardmix y el detalle de P1 justo debajo. Sitúa la lista de documentos requeridos junto a P1.2, donde se utiliza, en vez de introducirla entera dentro del rombo. Distingue los finales Rechazada y Retirada mediante texto y apariencia, no solo por color.
Abre Boardmix para reorganizar tu diagrama de flujo. Empieza por la etapa que genera más confusión, desarrolla solo ese detalle y deja intactas las partes que ya se entienden. El lector debería poder explicar la vista general y encontrar después las instrucciones exactas de su etapa.
