Cómo hacer un diagrama de flujo de proceso
Cómo hacer un diagrama de flujo de proceso: fija el disparador y el estado final, una acción por caja, convierte cada «si» en una decisión etiquetada y cierra cada rama. Con un ejemplo paso a paso.
Un diagrama de flujo de proceso muestra el orden en que el trabajo ocurre de verdad: un disparador, una acción por caja, una decisión etiquetada allí donde el camino se bifurca y un estado final explícito en cada rama.
En resumen
- Fija primero el disparador y la meta; todo lo demás es el medio.
- Una acción por caja, empezando por el verbo: «Registrar la factura en el sistema», no «Facturación».
- Toda decisión es una pregunta y toda salida lleva etiqueta.
- Cada rama vuelve al flujo o termina en su propio terminador: ninguna línea se queda en el aire.
- El camino de la excepción es lo que hace que el diagrama valga la pena.
Qué convierte un dibujo en un diagrama de flujo
Casi todos los primeros intentos de diagrama de flujo de proceso no son diagramas de flujo. Son una hilera de rectángulos unidos por flechas que describe la versión del proceso en la que no falla nada. Ese dibujo es una lista de tareas con pasos de más, y por eso tantos diagramas se hacen una vez, se imprimen y no se vuelven a mirar: el camino feliz ya se lo sabe todo el mundo. El valor está en lo que el diagrama dice de los demás caminos.
Un diagrama de flujo que funciona tiene una gramática corta y estricta. Un solo inicio. Una acción por caja, redactada empezando por el verbo para que quede claro quién hace qué. Una decisión dibujada como pregunta y con todas las salidas etiquetadas, para que quien lee sepa por dónde va. Y cada rama vuelve al flujo principal o termina en su propio terminador, porque una línea que se queda en el aire significa que nadie sabe qué pasa después, que es exactamente la situación que el diagrama venía a resolver.
El ejemplo de abajo es un proceso real de aprobación de facturas, construido en cinco etapas. Fíjate en lo que ocurre en cada una: el diagrama se vuelve útil justo cuando aparecen las excepciones, la factura duplicada, el precio que no cuadra con la orden de compra, la incidencia que vuelve al proveedor y se reengancha más arriba. Esas tres ramas son la razón entera de que el diagrama valga más que la lista de tareas.
Mira cómo se construye un diagrama de flujo de proceso
Cinco etapas de un flujo real de aprobación de facturas. Recórrelas: cada una añade la siguiente pieza de gramática.
Un disparador, un primer paso
Todo diagrama de flujo empieza con una sola figura de inicio, y esa figura nombra un hecho en lugar de una actividad: una factura que llega, no «gestión de facturas». Si tu diagrama tiene dos inicios, en realidad estás dibujando dos procesos.
Haz la primera pregunta
El rombo es una pregunta: «¿Factura duplicada?», y las dos salidas llevan etiqueta. Fíjate en que la rama del Sí no se difumina: acaba en su propio terminador, porque bloquear un duplicado es un final legítimo de este proceso, no un dibujo a medio terminar.
Separa los caminos que de verdad son distintos
Una factura con orden de compra se concilia contra la orden y el documento de recepción; una factura sin orden se imputa a un centro de costos. Dos ramas, porque el trabajo es realmente distinto, no porque alguien quisiera que el diagrama pareciera exhaustivo.
Devuelve la excepción al flujo
Una diferencia de precio abre una incidencia con el proveedor y, una vez resuelta, el flujo vuelve a entrar en mitad del proceso en lugar de empezar de cero. Los bucles que regresan al centro de un proceso son normales; lo que no es normal es una rama de excepción que desaparece sin más.
Termina en un estado, no en una actividad
La aprobación se enruta por importe, por encima del umbral hace falta un refrendo, y el diagrama acaba en «Proveedor pagado y aviso de pago enviado», un estado que se puede verificar. «Procesar el pago» sería una actividad, y una actividad nunca es una meta.
Cómo funciona
Escribe primero el disparador y la meta
Antes de ninguna caja: ¿qué hecho arranca este proceso y qué estado significa que ha terminado? Esas dos frases fijan el alcance, y casi todas las discusiones sobre un diagrama de flujo resultan ser discusiones sobre los límites, no sobre los pasos. Escribe la meta como un estado: «proveedor pagado», no como una actividad.
Lista los pasos como filas, no como un dibujo
En QueryChart abre un diagrama nuevo y escribe los pasos en la columna «Box text», uno por fila. Resiste la tentación de colocar nada. Una lista se discute más rápido que un diagrama, y el diseño se genera solo: el trazado lo hace la aplicación, así que nada de lo que coloques a mano sobrevive de todas formas.
Conecta las filas por número
La columna «Line to» toma el número de fila del paso siguiente, así que la fila 2 apuntando a la 3 ya dibuja la flecha. Escribe varios números separados por comas cuando un paso lleve a más de un sitio. Esto es todo lo que hay que saber para conectar un diagrama en QueryChart, y por eso lo puede editar alguien que no ha usado nunca una herramienta de diagramas.
Convierte cada «si» de tus notas en una decisión
Allí donde tus notas digan «si», «salvo que» o «según», pon el «Shape» de esa fila en Decision y reescribe la etiqueta como una pregunta. Después pon las respuestas en la columna «Line text»: «Sí», «No», «Más de 10.000», para que cada salida diga qué caso cubre. Una bifurcación sin etiquetas es, con diferencia, el motivo más habitual de que un diagrama no se pueda seguir.
Dibuja el camino de la excepción
Coge la rama mala de cada decisión y síguela hasta una conclusión real: ¿vuelve a un paso anterior, se traspasa a otra persona o termina? Dale una figura de terminador cuando acabe. Esta es la parte que la gente se salta y la que de verdad necesita quien lee: nadie consulta un mapa de procesos para saber qué pasa cuando todo va bien.
Recórrelo con quien hace el trabajo
Lee el diagrama en voz alta a quien ejecuta el proceso y pregúntale dónde está mal. Cuenta con encontrar un paso que en realidad son tres y una rama que nadie había escrito nunca. Corrígelo en las filas, comparte el diagrama y ponle una aprobación, para que la versión que la gente mira sea la acordada y no una captura en la presentación de alguien.
Errores que debes evitar
Decisiones redactadas como afirmaciones
«Aprobación del responsable» es un paso; «¿Aprueba el responsable?» es una decisión. Si un rombo no se lee como una pregunta, las dos líneas que salen de él no se pueden etiquetar con sentido y quien lee tiene que adivinar cuál le toca.
Ramas que se quedan en el aire
Toda línea tiene que llegar a algún sitio: a otro paso o a un terminador. Una rama que simplemente se acaba es el diagrama admitiendo que nadie sabe qué pasa en ese caso, algo que conviene saber, pero que hay que resolver en vez de dibujar.
Una caja que hace tres cosas
«Revisar, aprobar y archivar» son tres cajas con dos puntos de fallo escondidos entre ellas. Si la etiqueta de un paso necesita una «y», casi siempre es más de un paso, y el traspaso que no se ve es donde vive el retraso.
Dibujar el proceso que te gustaría tener
Mapea primero el proceso tal como es hoy, con excepciones y apaños incluidos, aunque dé apuro. Un diagrama del proceso futuro dibujado antes de que nadie se haya puesto de acuerdo en lo que pasa hoy es una propuesta, y debería estar etiquetado como tal.
Crea tu propio diagrama de flujo de proceso
Empieza desde el ejemplo de aprobación de facturas de arriba, o bórralo y escribe tus propios pasos en las filas.
Guías relacionadas
Preguntas frecuentes
¿Qué figuras necesito para un diagrama de flujo de proceso?
Cuatro sirven para casi todo: un terminador para el inicio y para cada estado final, un rectángulo para una acción, un rombo para una decisión y una figura de documento para el paso que genera un registro (un formulario firmado, un informe, una entrada en un libro). QueryChart ofrece además terminadores Reject y Success, algo útil porque un diagrama suele tener más de una forma de acabar y colorearlas distinto deja los finales malos a la vista de un vistazo.
¿Cuánto detalle debe tener un diagrama de flujo de proceso?
El suficiente para que alguien que no hace ese trabajo pueda seguirlo, y ni uno más. Una prueba práctica: si un paso se puede entregar a otro equipo sin más explicación, es una caja. Si explicarlo ocupa un párrafo, probablemente sea un subproceso que merece su propio diagrama enlazado desde este. Entre quince y veinticinco cajas es el rango en el que la mayoría de los procesos operativos siguen siendo legibles en una pantalla.
¿Cuál es la diferencia entre un diagrama de flujo de proceso y un mapa de procesos?
Un diagrama de flujo muestra secuencia y lógica: qué pasa, en qué orden y con qué decisiones. Un mapa de procesos añade contexto alrededor de esa secuencia: quién es responsable de cada paso, en qué sistema ocurre, qué entra y qué sale. En la práctica la distinción va sobre todo de carriles: en cuanto divides el flujo por responsable ya tienes un mapa de procesos, y esa suele ser la versión que merece la pena para todo lo que cruza la frontera de un equipo.
¿Las decisiones tienen que ser siempre de sí o no?
No, pero deben ser exhaustivas y excluyentes entre sí. Una bifurcación de tres salidas por tipo de cambio (estándar, normal, urgente) está bien mientras cada solicitud caiga exactamente en una de ellas. Lo que rompe un diagrama es una decisión cuyas salidas etiquetadas no cubren todos los casos, porque quien lee y no se ve reflejado no tiene adónde ir y acabará inventándose su propio camino.