Cómo crear un diagrama de flujo a partir de un documento

Cómo convertir en diagrama de flujo un documento cuyos pasos nunca se numeraron: qué pasajes no son pasos, dónde van entonces el alcance, las definiciones y las responsabilidades, y por qué el diagrama sale demasiado largo.

Crear un diagrama de flujo a partir de un documento consiste en separar los pasajes que describen una acción de los tres tipos que no la describen nunca (alcance, definiciones y responsabilidades) y dibujar solo los primeros.

En resumen

  • La mayor parte de un documento no describe ninguna acción: el alcance, las definiciones y las responsabilidades no son pasos.
  • Los diagramas hechos a partir de documentos salen el doble de largos que el proceso, y el exceso es prosa.
  • Todo pasaje que no sea un paso tiene igualmente su sitio: una ruta, una etiqueta de rama, un carril o un comentario.
  • Un término definido suele ser el criterio que le faltaba a su decisión: explota las definiciones en lugar de dibujarlas.
  • Una frase que nombra tres casos es un rombo con tres salidas, no tres pasos seguidos.

El alcance, las definiciones y las responsabilidades no son pasos

Un documento se escribe para leerlo, no para ejecutarlo, y solo una minoría de él describe a alguien haciendo algo. El apartado uno enuncia el alcance, el dos define términos, el tres lista quién es responsable de qué, y las acciones empiezan en algún punto de la página cuatro. Transcribe esa estructura y el resultado es un diagrama del doble de largo que el proceso, en el que una docena de pasos reales conviven con una docena de cajas que no ejecuta nadie.

Clasifica cada pasaje en acción, condición o ninguna de las dos antes de teclear nada. Las acciones se convierten en cajas y las condiciones en decisiones etiquetadas; esa caza de condicionales es casi todo el trabajo cuando la fuente es un procedimiento numerado, y tiene guía propia. Lo particular de un documento es el tercer montón, y el error está en tratarlo como desecho. El alcance, las definiciones, las responsabilidades y las referencias tienen cada uno un destino que no es una caja.

El ejemplo de abajo es una política de gestión del cambio de un centro industrial, reconstruida como 26 filas repartidas en seis fases, de «Solicitud» a «Implantación y cierre». Fíjate en dónde acabaron sus no-pasos. La exclusión de su párrafo de alcance es ahora «¿Sustitución idéntica?», con una salida «Idéntica» que abandona el proceso; sus definiciones de riesgo son ahora las etiquetas de rama de «¿Qué nivel de análisis de peligros?»; su tabla de autoridades es un carril. Cuatro flechas apuntan hacia arriba en la hoja; la más larga vuelve a entrar en la revisión técnica.

Seis fases, un solo documento de política

Una política de gestión del cambio, reconstruida: fíjate en cómo su párrafo de alcance llega como una ruta de salida, sus definiciones de riesgo como etiquetas de rama y sus autoridades como un carril.

  1. El alcance se convierte en una ruta de salida

    El párrafo de alcance de la política excluye las sustituciones idénticas. Esa exclusión no es ni una caja ni una nota al pie: dibujada, es «¿Sustitución idéntica?» con una salida «Idéntica» hacia «Gestionado como mantenimiento», a la que se llega dos filas después de «Cambio propuesto» y antes de comprometer ningún trabajo.

  2. Una frase, tres salidas

    Una sola cláusula clasificaba los cambios por tipo, y es un rombo en lugar de tres pasos: «¿Permanente, temporal o de emergencia?», donde «Temporal» recoge «Fijar fecha de caducidad y plan de retirada» y «Permanente» va directo a la base técnica. La salida de emergencia estaba impresa en un apartado posterior.

  3. Las definiciones son los criterios

    El documento entierra sus definiciones de riesgo en un apartado que nadie dibujaría; son las salidas de «¿Qué nivel de análisis de peligros?»: «Riesgo bajo», «Riesgo medio» y «Riesgo alto». Una definición es lo que hace decidible una rama, y las tres rutas convergen en «Evaluar el impacto en sistemas y límites de seguridad».

  4. La lista de responsabilidades son los carriles

    Qué nivel de autoridad hace falta era una tabla del documento; aquí es el carril «Responsable autorizador», pegado a la fila donde decide algo. «¿Autorizado al nivel requerido?» se detiene con «Rechazado», avanza con «Autorizado» y regresa con «Requiere más trabajo» a la base técnica.

  5. La flecha más larga apunta hacia atrás

    «¿Superada la PSSR?» manda las acciones pendientes a dar otra vuelta antes de la puesta en marcha. Más adelante, «¿Sigue siendo necesario al vencer el plazo?» ofrece «Convertir en permanente», que vuelve a entrar en «Documentar la base técnica»: la flecha más larga del diagrama, y la cláusula de la que vive un cambio temporal.

Cómo funciona

  1. Clasifica cada pasaje en tres montones

    Lee el documento una vez marcando cada pasaje como acción, condición o ninguna de las dos. «El solicitante registrará el cambio» es una acción. «Para los cambios que no sean sustituciones idénticas» es una condición. El alcance, las definiciones, la tabla de responsabilidades y la lista de referencias no son ni una cosa ni otra, y en una política ocupan más páginas que las acciones.

  2. Gasta los no-pasos en lugar de dibujarlos

    El tercer montón se aprovecha, no se tira. Una exclusión de alcance se convierte en una decisión al principio con un final propio. Un término definido se convierte en el criterio de la decisión que lo usa, con su redacción exacta en el comentario de esa fila. La tabla de responsabilidades se convierte en el juego de carriles. Nada de ese montón se convierte en una caja.

  3. Escribe las acciones en filas

    En QueryChart cada fila es una caja, así que pon una acción marcada en la columna «Box text» de cada fila, en el orden en que ocurren las acciones y no en el orden en que se imprimieron. Deja la etiqueta lo bastante corta como para leerla de un vistazo y guarda la cláusula de la que salió en el comentario del paso. Une después las filas con la columna «Line to», que toma números de fila.

  4. Dale a cada condición una salida etiquetada

    Las filas que vienen de condiciones se convierten en rombos: pon su columna «Shape» en Decision y reescribe cada una como una pregunta. «Line text» toma entonces una etiqueta por rama, en el orden de los números de «Line to». Una cláusula que nombra tres casos necesita tres etiquetas («Riesgo bajo», «Riesgo medio», «Riesgo alto») o quien lee no puede saber cuál es su ruta.

  5. Coloca las rutas que el documento repartió

    Apunta cada rama a la fila a la que llega, también hacia atrás: una autorización que requiere más trabajo vuelve a la base técnica, y un cambio temporal al vencer su plazo vuelve a entrar en la misma revisión. Rellena después las columnas «Horizontal lane» y «Vertical lane» a partir de la tabla de responsabilidades, para que un paso se sitúe en «Cribado» bajo el «Coordinador de MOC».

  6. Lee el diagrama contra el documento

    Ve cláusula por cláusula marcando cada una contra una fila, una etiqueta de rama, un carril o el comentario de un paso. Quedan tres cosas fuera: detalle que pertenece a un comentario, una ruta que nadie ha dibujado todavía y cláusulas que el centro dejó de seguir hace años. Lleva esa última lista a quien sea dueño del documento: es la solicitud de revisión que se ha ganado el mapeo.

Errores que debes evitar

  • Dibujar una prohibición como un paso

    «Ningún cambio se implantará antes de su autorización» no es algo que alguien haga; es una afirmación sobre la topología. Satisfácela comprobando que nada llega a la implantación salvo pasando por la puerta, no añadiendo una caja.

  • Seis cajas que no ejecuta nadie

    Una lista de quién responde de qué no es una secuencia, y transcribirla produce seis cajas seguidas que no ejecuta nadie. Los roles van en las columnas de carril, pegados a los pasos que sí ocurren de verdad.

  • Cláusulas enteras pegadas dentro de una etiqueta

    Una caja que lleva cuarenta palabras de lenguaje normativo no se puede leer al tamaño al que se lee un diagrama. Deja la instrucción en la etiqueta y la redacción en el comentario del paso, donde el texto original sigue disponible para quien lo quiera.

  • Creerle al documento antes que a la planta

    Un procedimiento escrito registra lo que se aprobó, no lo que se hace. Recorre el diagrama con la gente que opera el proceso; allí donde describan una ruta para la que el documento no tiene ninguna cláusula, lo que está mal es el documento.

Convierte tu documento en un diagrama de flujo

Abre el ejemplo de gestión del cambio como diagrama propio y dibuja después solo los pasajes de tu propio documento que describan a alguien actuando.

Convierte tu documento en un diagrama de flujo

Guías relacionadas

Preguntas frecuentes

¿Cómo convierto un PDF en un diagrama de flujo?

Extrae primero el texto y convierte el texto, no la maquetación. El orden de lectura de un PDF es un artefacto de diseño (se entremezclan columnas, barras laterales, tablas y pies de página), así que cualquier cosa que lo siga produce cajas en un orden que el proceso nunca tuvo. Saca las acciones, marca los condicionales y construye a partir de esa lista. Pegar el texto extraído en la IA de QueryChart da un primer borrador utilizable de las filas; los condicionales que no consiga resolver son justamente la parte que necesita a una persona.

¿Dónde van el alcance y las definiciones en un diagrama de flujo?

Ninguno de los dos se convierte en una caja. Un enunciado de alcance se convierte en una decisión al principio del flujo con un final propio: en el ejemplo, la exclusión de la política es «¿Sustitución idéntica?», y la rama «Idéntica» se detiene en «Gestionado como mantenimiento» sin tocar el resto del proceso. Las definiciones se convierten en los criterios de las decisiones que las usan (riesgo bajo, medio y alto solo son decidibles como etiquetas de rama porque el documento dice dónde empieza cada banda) y la redacción exacta va en el comentario del paso.

¿Por qué salen demasiado largos los diagramas hechos desde documentos?

Por dos mecanismos, y los dos son evitables. El primero es transcribir los apartados que no describen ningún trabajo: una tabla de responsabilidades aporta una caja por rol, una lista de referencias una por documento, y ninguna de las dos describe nada que nadie haga. El segundo es la inflación en las decisiones: una frase que nombra tres casos dibujada como tres pasos seguidos en lugar de un rombo con tres salidas etiquetadas, de modo que el diagrama crece mientras la bifurcación sigue invisible. Entre los dos añaden una docena de cajas a un proceso de doce pasos.

¿Se puede dibujar una política o un contrato como diagrama de flujo?

Sí, y el ejercicio casi siempre encuentra algo. Los contratos y las políticas se escriben para repartir obligaciones y no para secuenciar trabajo, así que sus condicionales son densos y sus actores se nombran una vez y después aparecen como la parte o el destinatario. Dibujar uno obliga a meter cada obligación en el carril de un responsable y cada condición en una rama etiquetada, que es como salen a la luz la cláusula sin consecuencia declarada y el plazo de preaviso sin ningún paso detrás.

La plantilla detrás de esta guía

Diagrama de flujo de gestión del cambio (MOC, PSSR, caducidad) — Diagrama del proceso de gestión del cambio (MOC) en seguridad de procesos: criba de sustitución idéntica, clasificación, análisis de peligros, autorización, PSSR antes del arranque y el bucle de caducidad.

Browse all Guías de mapeo de procesos y diagramas de flujo de IA