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