Cómo crear un diagrama de flujo de trabajo
Cómo crear un diagrama de flujo de trabajo: modela la solicitud, los puntos de aprobación, el trabajo en sí y la revisión que cierra el ciclo, con un rol responsable de cada estado. Con un ejemplo en vivo.
Un diagrama de flujo de trabajo muestra cómo una unidad de trabajo se mueve entre roles: qué la desencadena, por qué aprobaciones tiene que pasar, quién la ejecuta y en qué estado termina.
En resumen
- La unidad es el elemento (una solicitud, un ticket, un documento) y los estados por los que pasa.
- Cada punto de aprobación nombra a un aprobador y sus dos resultados.
- Un elemento nunca puede estar en un estado que nadie vigile.
- Los rechazos se enrutan a un sitio explícito: de vuelta para corregir, o a un estado cerrado.
- Dibuja la revisión periódica si la hay: muchos flujos de trabajo se reabren con el calendario.
Lo que muestra un diagrama de flujo de trabajo y un mapa de procesos no
Las palabras flujo de trabajo y proceso se usan como sinónimos, y casi siempre da igual. La distinción se gana el sueldo cuando piensas en qué estás dibujando: un mapa de procesos describe cómo se hace el trabajo, mientras que un diagrama de flujo de trabajo describe cómo un elemento concreto (una solicitud, un ticket, un documento) viaja entre las personas que tienen que actuar sobre él. La unidad de análisis es el elemento y los estados por los que pasa, no la actividad.
Eso cambia lo que corresponde poner en la página. Un diagrama de flujo de trabajo vive de sus puntos de aprobación: quién tiene que aprobar, en qué orden y qué pasa cuando uno de ellos dice que no. Debe ser inequívoco sobre dónde puede estar un elemento en cada momento y quién lo tiene en la mano, porque el fallo más habitual de un flujo de trabajo no es una decisión equivocada, sino un elemento aparcado en un estado que nadie vigila.
El ejemplo de abajo es una solicitud de accesos. Tiene cuatro aprobadores distintos, una comprobación de conflictos que puede mandar el elemento hacia atrás y un ciclo de recertificación que reabre el flujo meses después de que pareciera terminado, lo cual recuerda bien que el último estado de un flujo de trabajo no suele ser su último acontecimiento.
Un flujo de trabajo con cuatro puntos de aprobación
Una solicitud de accesos, del formulario al permiso concedido, y de vuelta a la salida en la recertificación.
El disparador y el primer control
Una solicitud con su justificación por escrito y, después, la decisión del responsable directo. Fíjate en que la justificación se recoge antes de cualquier aprobación: un control solo puede ser tan bueno como lo que se le enseña a quien aprueba.
Aprobaciones en serie, no en paralelo
El propietario del sistema revisa los permisos del rol, una comprobación de segregación de funciones puede devolver el elemento para ajustar el alcance y volver a comprobarlo, y el acceso privilegiado añade encima una aprobación de seguridad. Cada control tiene un único responsable y una salida etiquetada para el rechazo.
El trabajo en sí
Aprovisionar con mínimo privilegio, confirmar el acceso al solicitante, recoger la aceptación de las normas de uso y anotar el permiso en el registro de accesos. En casi todos los diagramas de flujo de trabajo, hacer el trabajo es la sección más corta, y eso suele ser justo el hallazgo.
El bucle que lo vuelve a abrir
La recertificación reinicia el flujo de trabajo en la fecha prevista, y la respuesta a «¿sigue siendo necesario el acceso?» reconfirma el permiso o dispara su revocación. Un flujo de trabajo que solo avanza deja los permisos acumulándose durante años.
Cómo funciona
Nombra el elemento y sus estados
Escribe qué es lo que fluye (una solicitud, una factura, un documento) y en qué estados puede estar: enviado, aprobado, aprovisionado, revocado. Los estados son lo que busca quien lee cuando pregunta dónde está algo, así que acordarlos primero evita que el diagrama se convierta en una lista de tareas.
Lista los controles en el orden en que se aplican
Para cada aprobación, anota quién es responsable y qué está decidiendo. Después comprueba si el orden es real: hay controles que podrían ir perfectamente en paralelo y se dibujan en serie solo porque así se configuró el sistema de tickets, y eso conviene sacarlo a la luz en vez de consagrarlo.
Construye los estados como filas y conéctalos
Pon cada estado o acción en una fila, cambia los controles a «Shape» Decision y conéctalos con la columna «Line to». Etiqueta las dos salidas de cada control en «Line text». A estas alturas el diagrama ya te enseñará cualquier estado del que no se pueda salir.
Dale un carril a cada estado
Coloca cada fila en el carril del rol que tiene el elemento en ese estado. Esto es lo que convierte el dibujo en una respuesta a «quién tiene parada mi solicitud», que es con diferencia la pregunta más frecuente que recibe un diagrama de flujo de trabajo.
Enruta los rechazos
Un elemento rechazado va a algún sitio: de vuelta al solicitante para corregirlo, a un estado cerrado o a un responsable de excepciones. Dibújalo. Los flujos de trabajo que dejan el rechazo implícito producen el fallo clásico en el que un elemento no está ni vivo ni cerrado y nadie lo reclama.
Añade la revisión periódica
Si el elemento se revisa con una periodicidad (un acceso que se recertifica, un documento que se revisa, un contrato que se renueva), dibújalo como una vía de vuelta al flujo con su propia decisión. Si no, el diagrama da a entender que el trabajo se acaba ahí, y el registro se va llenando en silencio de entradas que nadie vuelve a mirar.
Errores que debes evitar
Estados sin responsable
«Pendiente de revisión» sin carril significa que nadie responde de moverlo. Todo estado pertenece a alguien, aunque ese alguien sea una cola con un responsable con nombre y apellidos.
Dibujar la herramienta en lugar del trabajo
Copiar la lista de estados del sistema de tickets te da el diagrama de una configuración. Pregunta qué tiene que pasar de verdad y después compara: las diferencias son la parte interesante.
Aprobaciones apiladas por comodidad
Cada control de más añade tiempo de ciclo y diluye la responsabilidad, porque quien aprueba siendo uno de cinco firma sin mirar. Dos controles con sentido valen más que cinco de trámite.
Sin salida para un rechazo
Si el diagrama no dice qué pasa cuando alguien no aprueba, el resultado no feliz más habitual del flujo de trabajo se queda sin definir.
Crea tu propio diagrama de flujo de trabajo
Abre el ejemplo de solicitud de accesos como tu propio diagrama y cambia los controles, los aprobadores y los estados por los tuyos.
Guías relacionadas
Preguntas frecuentes
¿Cuál es la diferencia entre un diagrama de flujo de trabajo y un diagrama de flujo de proceso?
Un diagrama de flujo de proceso describe cómo se ejecuta el trabajo; un diagrama de flujo de trabajo describe cómo un elemento concreto se mueve entre las personas que actúan sobre él, con el énfasis puesto en los estados, la responsabilidad y los puntos de aprobación. En la práctica se solapan mucho y la misma notación sirve para los dos. La distinción es útil sobre todo como aviso: si no sabes decir qué elemento está fluyendo y en qué estados puede estar, estás dibujando un mapa de procesos, no un flujo de trabajo.
¿Cuántas aprobaciones debe tener un flujo de trabajo?
Las mínimas que lleven una decisión real. Cada control añade tiempo de espera y, pasados dos o tres, diluye la responsabilidad: quien aprueba siendo uno de cinco tiende a firmar sin mirar, y eso es peor que no tener control, porque genera la evidencia de una revisión que no ocurrió. Si un control no ha rechazado nada nunca, es una notificación y debería dibujarse como tal.
¿Un diagrama de flujo de trabajo debe usar carriles?
Casi siempre. La pregunta que más recibe un diagrama de flujo de trabajo es quién tiene ahora mismo este elemento, y los carriles la responden sin que nadie tenga que leer las cajas. La excepción es un flujo de trabajo que nunca sale de un mismo equipo, donde los carriles añaden una dimensión que no lleva ninguna información.
¿Cómo represento un flujo de trabajo que se repite con una periodicidad?
Dibuja el disparador como un paso y devuélvelo al flujo con una decisión sobre el resultado. En el ejemplo de accesos, la recertificación es un paso programado que alimenta la decisión «¿sigue siendo necesario el acceso?», que reconfirma o revoca. Modelarlo de forma explícita es lo que impide que el diagrama dé a entender que un elemento, una vez tramitado, ya está resuelto para siempre.
