Diagrama de flujo

Conviene empezar por lo que casi nadie dice al vender la herramienta: el diagrama de flujo no mejora ningún proceso. Lo hace visible. Sirve para que un grupo de personas que ejecuta el mismo trabajo descubra —muchas veces con incomodidad— que cada una lo hace distinto, y para dejar por escrito quién decide en cada bifurcación. Todo el valor está en la conversación que obliga a tener; el archivo es el subproducto.

Los símbolos son cuatro y no hacen falta más para el 95 % de los casos: óvalo para inicio y fin, rectángulo para actividad, rombo para decisión —siempre con dos salidas rotuladas, sí y no— y rectángulo con base ondulada para documento o registro. Cuando un diagrama empieza a necesitar una leyenda de doce figuras, el problema no es de notación: es que se está intentando meter en un dibujo lo que corresponde a un procedimiento escrito.

Hay tres decisiones de encuadre que separan un diagrama útil de uno decorativo. La primera es el nivel: un diagrama que cabe en una página y tiene entre siete y quince pasos se lee y se discute; uno de sesenta pasos se archiva. Si el proceso no cabe, se parte en subprocesos, no se reduce la letra. La segunda es quién lo dibuja: si lo hace un consultor solo en su computador, documenta lo que le contaron; si lo dibuja el equipo que ejecuta —en una pared, con notas adhesivas, antes de pasarlo a limpio—, documenta lo que ocurre. La tercera es el carril: cuando el proceso cruza áreas, el diagrama por carriles (una fila por responsable) hace evidente el número de entregas entre departamentos, que es donde se pierde la mayor parte del tiempo.

En una empresa ecuatoriana el diagrama rinde sobre todo en cuatro momentos: al documentar un proceso para una certificación, al preparar la salida o el ingreso de una persona clave —el conocimiento que estaba en una cabeza queda en una página—, al discutir una automatización con un proveedor de software, y al investigar un error recurrente, porque la falla casi siempre está en un rombo sin regla escrita: nadie sabía quién decidía.

Y una advertencia sobre el uso más frecuente y menos rentable: dibujar el proceso como debería ser en lugar de como es. Un diagrama del proceso ideal no sirve para mejorar nada, porque no hay nada que comparar. El orden correcto es dibujar el proceso real —con los reprocesos, los correos de vuelta y las esperas—, medirlo y recién entonces dibujar el propuesto. Si quiere el detalle de cómo construirlo paso a paso, lo desarrollamos en la guía de flujograma de procesos empresariales; esta ficha define el término y decide cuándo usarlo.

Una importadora de Quito tarda entre 3 y 11 días en aprobar una orden de compra, y nadie sabe explicar por qué. El equipo dibuja el proceso real en una pared, por carriles: Solicitante, Jefatura, Compras, Gerencia y Contabilidad. El diagrama de una página deja tres cosas a la vista en veinte minutos. Hay siete entregas entre áreas para una compra de USD 200. Existe un rombo sin regla escrita —«¿requiere aprobación de Gerencia?»— que cada jefatura interpreta distinto, y ahí nace la diferencia entre 3 y 11 días. Y hay un lazo de retorno no declarado: si falta un dato, la orden vuelve al solicitante sin aviso y se detiene hasta que alguien pregunta.

Las correcciones salieron del propio dibujo, no de un proyecto: se escribió el criterio del rombo (monto y tipo de gasto), se eliminaron dos firmas que no agregaban decisión y se añadió una notificación automática en el lazo de retorno. El plazo quedó entre 2 y 4 días. Nadie compró software: el diagrama solo hizo imposible seguir discutiendo sin mirar el proceso.