Un diagrama de flujo permite representar de manera visual y ordenada una secuencia de pasos, con sus posibles desvíos y decisiones. En esencia, un diagrama de flujo es un esquema gráfico que muestra cómo se desarrolla un proceso, un procedimiento o un algoritmo, desde el inicio hasta el final, incluyendo las decisiones que pueden hacer que el recorrido tome diferentes caminos.

Aunque hoy asociamos los diagramas de flujo con la informática, su historia está estrechamente relacionada con la ingeniería industrial. En 1921, Frank B. Gilbreth y Lillian M. Gilbreth presentaron ante la Sociedad Americana de Ingenieros Mecánicos, ASME, su trabajo Process Charts, concebido como una herramienta para visualizar los procesos y buscar una mejor manera de realizar el trabajo. La publicación original de 1921 contiene ejemplos de estos diagramas y de sus símbolos, por lo que constituye una referencia histórica fundamental para entender el desarrollo de esta forma de representación.

Los Gilbreth estaban interesados especialmente en estudiar el trabajo con detalle para descubrir movimientos innecesarios y encontrar maneras de hacerlo más eficiente. Este interés también dio lugar al estudio de los llamados Therbligs, una clasificación de movimientos elementales utilizada para analizar las tareas manuales. La clasificación clásica se describe habitualmente mediante 17 movimientos básicos, y el nombre Therblig proviene de una inversión aproximada de la palabra Gilbreth. Estos movimientos permitían estudiar con mayor precisión lo que hacía un trabajador y detectar acciones que podían eliminarse, reducirse o reorganizarse.

Con el tiempo, las ideas relacionadas con los diagramas de procesos se fueron estandarizando. En 1947, la ASME adoptó un conjunto de símbolos derivado del trabajo de los Gilbreth para sus diagramas de operaciones y procesos. Más adelante, en el ámbito de la informática, los diagramas adquirieron una nueva importancia. Herman Goldstine y John von Neumann desarrollaron durante la década de 1940 diagramas destinados a planificar programas de computadora antes de escribir las instrucciones. Sus trabajos de 1947 constituyen uno de los antecedentes fundamentales de los diagramas de flujo utilizados posteriormente para representar algoritmos.

La idea resultó especialmente poderosa porque permitía convertir una serie de instrucciones abstractas en un recorrido que podía observarse de un vistazo. Antes de escribir un programa, por ejemplo, era posible representar qué operación debía realizarse, qué condición debía comprobarse y qué debía ocurrir dependiendo de la respuesta. De esta manera, el diagrama funcionaba como un mapa del algoritmo.

Hoy podemos encontrar diagramas de flujo prácticamente en cualquier actividad que implique una secuencia de pasos. Un técnico puede utilizarlos para representar el procedimiento que debe seguir cuando una computadora no enciende; una empresa puede emplearlos para mostrar el recorrido de un pedido desde que el cliente realiza la compra hasta que recibe el producto; un hospital puede representar mediante ellos determinadas rutas de atención; y un programador puede utilizarlos para comprender la lógica de un algoritmo antes de transformarla en código.

Su utilidad depende en buena medida de un pequeño conjunto de símbolos que actúa como un lenguaje visual compartido. Una figura redondeada suele representar el inicio o el final del proceso; un rectángulo representa una actividad o acción, como “moler el café” o “enviar el correo”; y un rombo representa una decisión o condición, como “¿hay azúcar?”. Desde ese rombo pueden salir diferentes caminos, normalmente identificados con respuestas como “sí” y “no”. Las flechas indican la dirección en la que debe seguirse el proceso. Existen muchos otros símbolos para representar datos, documentos, entradas, salidas, conexiones y otros elementos, pero con las figuras básicas es posible representar una gran cantidad de situaciones.

No existe una única norma que obligue a que todos los diagramas de flujo del mundo utilicen exactamente los mismos símbolos en todas las circunstancias. Sin embargo, existen estándares que ayudan a establecer convenciones comunes. Un ejemplo importante es la norma internacional ISO 5807:1985, que define símbolos y convenciones para documentar diagramas de flujo de datos, programas y sistemas, además de otros tipos de representaciones relacionadas con el procesamiento de información.

La lógica de un diagrama de flujo se entiende mejor con un ejemplo. Supongamos que quieres comprar un par de zapatos por internet. El proceso podría comenzar con “inicio”, continuar con “abrir la página web” y después con “elegir el modelo”. A continuación aparecería una decisión: “¿está disponible en mi talla?”. Si la respuesta es no, el proceso podría dirigirse hacia “buscar otro modelo”. Si la respuesta es sí, continuaría con “agregar al carrito”, “introducir los datos de pago” y “confirmar la compra”. Si la tarjeta fuera rechazada, aparecería otra decisión y el proceso podría desviarse hacia “intentar otro método de pago”. Finalmente, una vez realizada la compra, el proceso llegaría a su término.

Los diagramas de flujo también permiten representar ciclos. Por ejemplo, si una página web solicita una contraseña y esta es incorrecta, el proceso puede regresar al paso en el que se solicita nuevamente. Pero aquí aparece una cuestión importante: un bucle no es necesariamente un error. Algunos procesos necesitan repetir determinadas acciones. El problema aparece cuando un ciclo no tiene una condición adecuada de salida y, por lo tanto, puede repetirse indefinidamente. El rombo de decisión no es el responsable directo de los bucles infinitos. El rombo simplemente representa una decisión; el bucle infinito aparece cuando la lógica del proceso permite regresar continuamente a un punto sin alcanzar nunca una condición que termine el ciclo. La cultura popular incluso ha utilizado esta situación como recurso humorístico: en The Big Bang Theory, Sheldon Cooper diseña un algoritmo representado mediante un diagrama de flujo para intentar hacer amistad con Barry Kripke, y el algoritmo inicialmente queda atrapado en un ciclo hasta que Howard propone incorporar un contador y una salida.

A lo largo de la historia de la programación, los diagramas de flujo también han tenido defensores y críticos. Durante la evolución de las técnicas de programación estructurada, algunos especialistas cuestionaron la utilidad de representar determinados programas mediante diagramas complejos, especialmente cuando las estructuras de control del código podían expresarse de forma más clara mediante lenguajes de programación estructurados o pseudocódigo.

Con el desarrollo de la ingeniería de software y de la gestión de procesos aparecieron además otras técnicas de modelado. El Lenguaje Unificado de Modelado (UML), por ejemplo, ofrece diversos tipos de diagramas para representar estructura y comportamiento de sistemas de software, mientras que Business Process Model and Notation (BPMN) fue desarrollado específicamente para representar procesos de negocio. Ambos pueden compartir algunas ideas con los diagramas de flujo, como actividades, decisiones y secuencias, pero son lenguajes de modelado con sus propias reglas, símbolos y objetivos.

Una de las grandes ventajas del diagrama de flujo es que obliga a pensar en el orden de las acciones. Al intentar dibujar un proceso podemos descubrir que falta un paso, que una decisión no estaba contemplada o que dos personas entendían de manera diferente cómo debía realizarse una determinada actividad. También puede ayudar a localizar retrasos, repeticiones innecesarias, puntos de decisión excesivos o posibles errores. En otras palabras, dibujar el proceso puede revelar problemas que permanecían ocultos cuando únicamente se describía mediante palabras.

La representación visual también facilita la comunicación. Una persona que no participó en el diseño original de un proceso puede comprenderlo observando su recorrido. Por esa razón, los diagramas de flujo se utilizan tanto para documentar procesos que ya existen como para diseñar procesos nuevos. Pueden elaborarse con papel y lápiz, en una pizarra, mediante herramientas especializadas o con aplicaciones digitales. Lo importante no es la herramienta utilizada, sino que el diagrama represente de manera clara y coherente el proceso que se quiere explicar o analizar.

En cuanto a su forma de lectura, muchos diagramas convencionales se organizan de arriba hacia abajo y, cuando existen elementos dispuestos horizontalmente, de izquierda a derecha. Sin embargo, esto es una convención de diseño y legibilidad, no una regla absoluta que impida otras disposiciones. Cuando un diagrama se vuelve demasiado grande, pueden utilizarse conectores para evitar que las líneas se crucen y para enlazar distintas partes del proceso.

El resultado es una herramienta sorprendentemente sencilla pero poderosa. Un diagrama de flujo puede representar desde algo tan cotidiano como preparar un café hasta procesos industriales, procedimientos administrativos, algoritmos informáticos o rutas de atención en una organización. Su fuerza está en la capacidad de hacer visible la secuencia de acciones, decisiones, alternativas y posibles resultados de un proceso.

Al trasladar una secuencia de pasos de nuestra mente al papel o a una pantalla, podemos observarlo, explicarlo, cuestionarlo y mejorarlo. Más de un siglo después de los trabajos de los Gilbreth, los diagramas de flujo continúan siendo útiles, pues convierten procesos que pueden parecer complicados en recorridos visuales que cualquier persona puede seguir, analizar y, cuando sea posible o necesario, mejorar.

Referencias:

Diagrama de flujo: qué es, historia y usos

Cómo citar