Documentar procesos para automatizar: el detalle que de verdad hace falta

Casi todos los proyectos de automatización que se atascan se atascan en el mismo sitio: nadie sabe explicar con precisión cómo funciona el proceso que se quiere automatizar. Documentar procesos suena a tarea burocrática —y lo es, cuando se hace para el archivador— pero cuando el destinatario del documento es un robot, un flujo de trabajo o un agente de IA, deja de ser burocracia y se convierte en la especificación técnica del proyecto. Si está mal, lo que se construye está mal.

La mala noticia es que la documentación que ya existe en la mayoría de empresas no sirve. El manual de calidad, el diagrama que hizo un becario en 2021, el procedimiento de la ISO: todos describen el proceso que debería ocurrir, no el que ocurre. La buena noticia es que documentar un proceso con el nivel de detalle correcto se hace en días, no en meses, si se sabe qué apuntar y qué ignorar.

Esta guía explica qué información necesita de verdad quien va a automatizar, quién debería escribirla, cómo tratar el apartado que siempre se deja para el final —las excepciones— y cómo saber si lo que tienes ya es suficiente para pedir un presupuesto comparable.

¿Qué significa documentar un proceso para que se pueda automatizar?

Documentar para automatizar no es narrar lo que hace el equipo. Es responder, paso a paso, a cuatro preguntas que una máquina necesita tener resueltas antes de ejecutar nada:

• ¿Qué dispara el paso? Un correo que entra, un registro nuevo en el ERP, una hora del día, la decisión de una persona. Si el disparador es «cuando Marta lo ve», eso también se escribe, porque es un disparador humano y hay que decidir si se mantiene.
• ¿De dónde sale la información? Sistema, pantalla, campo, fichero, carpeta. «Del ERP» no vale. «Del campo `fecha_prevista` de la cabecera del pedido en el módulo de ventas» sí.
• ¿Qué decisión se toma y con qué regla? Aquí está el núcleo. La mayoría de pasos esconden un criterio que nadie ha escrito nunca: «si el importe es alto lo paso a dirección». ¿Alto es cuánto? ¿Siempre? ¿Y si es un cliente antiguo?
• ¿Dónde queda el resultado? Qué se crea, qué se modifica, a quién se avisa y cómo se sabe que el paso terminó bien.

Un proceso documentado así se puede leer de arriba abajo y convertir en un flujo sin volver a preguntar. Un proceso documentado como prosa («el departamento revisa la documentación y, si todo está correcto, procede a la tramitación») no se puede automatizar: revisar qué, correcto según quién, tramitar cómo.

Regla práctica: si quien lee el documento tiene que preguntarte algo para poder ejecutarlo, falta ese algo en el documento.

¿Por qué el manual de calidad no sirve?

Porque está escrito para otro lector. Un procedimiento de calidad existe para demostrar ante un auditor que hay control; está redactado en términos de responsabilidades y evidencias, no de datos y condiciones. Tres diferencias que lo hacen inservible como especificación:

| Manual de calidad | Documentación para automatizar | |---|---| | Describe el proceso aprobado, idealizado | Describe el proceso real, con atajos y retrabajos | | Habla de departamentos («Administración valida») | Habla de sistemas, campos y reglas concretas | | Omite las excepciones por ser «casos puntuales» | Las excepciones son la mitad del documento | | Se actualiza una vez al año, si eso | Se actualiza cada vez que cambia una regla |

Hay un segundo motivo, menos técnico y más incómodo: el proceso aprobado y el proceso real se separan con el tiempo porque el equipo inventa atajos para que el trabajo salga. Esos atajos no son indisciplina, suelen ser la respuesta inteligente a un sistema que no acompaña. Si automatizas el manual, automatizas la versión que el equipo ya había abandonado, y el primer día en producción aparecerán veinte casos que «siempre se han hecho de otra manera».

Cuando el proceso deja huella en los sistemas (pedidos, expedientes, tickets), la minería de procesos permite reconstruir ese flujo real a partir de los registros, sin depender de lo que cada uno recuerda. Cuando no la deja —porque vive en correos y hojas de cálculo—, no queda más remedio que sentarse a mirar.

¿Quién debe escribir la documentación del proceso?

La respuesta corta: quien ejecuta el proceso, acompañado por alguien que sepa preguntar. Ni solo uno ni solo el otro.

• Quien lo ejecuta conoce las excepciones, los atajos y los casos raros. Pero suele dar por obvio lo que lleva ocho años haciendo, y se salta precisamente los pasos que una máquina no puede adivinar.
• Quien analiza (consultor interno, responsable de sistemas, proveedor) sabe qué hay que preguntar y en qué formato hace falta la respuesta, pero no tiene ni idea de qué pasa cuando el proveedor manda el albarán con el número de pedido mal.
• El responsable del proceso no escribe, decide. Su papel es resolver las ambigüedades que aparecen: cuando el documento dice «depende», alguien tiene que fijar de qué.

El formato que mejor funciona es una sesión de dos horas con la persona que ejecuta, grabada o con alguien tomando notas, en la que se recorre el proceso con un caso real abierto en pantalla. No una entrevista en una sala: el proceso delante, pinchando. La frase que más información da en toda la sesión es «¿y esto qué pasa si...?».

Después, el borrador vuelve a quien ejecuta para que lo corrija. Siempre hay correcciones, y suelen ser las importantes.

¿Qué nivel de detalle es útil y dónde empieza a sobrar?

El error habitual es irse a uno de los dos extremos: media página que no especifica nada, o cuarenta páginas que nadie va a mantener. El nivel útil se puede definir con un criterio sencillo: detalla al máximo lo que va a ejecutar la máquina y resume lo que seguirá haciendo una persona.

En la práctica, para un proceso de tamaño medio (digamos, de la recepción de una factura de proveedor a su contabilización), un documento útil ocupa entre 4 y 8 páginas y contiene:

| Bloque | Qué incluye | Por qué importa | |---|---|---| | Alcance | Dónde empieza y dónde acaba el proceso, y qué queda fuera | Evita que el proyecto crezca por los bordes | | Volumen | Cuántos casos al mes, picos, estacionalidad | Decide si compensa automatizar y qué arquitectura aguanta | | Flujo principal | Pasos del caso normal, con disparador, dato, regla y resultado | Es el 70-80% de los casos | | Reglas de decisión | Cada condición escrita como regla comprobable | Es lo que más tiempo ahorra al desarrollar | | Excepciones | Qué casos se salen y qué se hace con cada uno | Es donde mueren los pilotos | | Sistemas y accesos | Qué aplicaciones intervienen, con qué usuario, qué permisos | Determina el coste de integración | | Criterio de «bien hecho» | Cómo se sabe que un caso terminó correctamente | Sin esto no hay forma de medir ni de probar |

Lo que sobra casi siempre: la historia del proceso, el organigrama, las capturas de pantalla decorativas y la descripción de pasos que el proyecto no va a tocar. Si una sección no cambia ninguna decisión de diseño, fuera.

¿Qué hacer con las excepciones?

Aquí está el trabajo de verdad. Un proceso típico tiene un camino principal que cubre el 70-80% de los casos y una cola larga de situaciones que el equipo resuelve a mano sin considerarlas excepciones, porque pasan todas las semanas.

La forma de sacarlas a la luz es preguntar por el caso concreto, no por el proceso en abstracto:

• ¿Cuál fue el último caso que te dio problemas? ¿Qué tenía de raro?
• ¿Qué haces cuando falta un dato? ¿Esperas, lo inventas, llamas a alguien?
• ¿Qué pasa si llega dos veces lo mismo?
• ¿Qué caso te obliga a salirte del sistema y resolverlo por correo o por teléfono?
• ¿Hay algún cliente o proveedor que se trate distinto «porque es él»?

Cada excepción detectada se clasifica en una de tres casillas, y la clasificación la hace el responsable del proceso, no quien documenta:

1. Se automatiza igual. La excepción tiene una regla clara, solo que nadie la había escrito. Entra en el flujo. 2. Se deriva a una persona. La máquina detecta el caso, lo marca y lo pone en una bandeja con todo el contexto. Esto no es un fallo del proyecto: es el diseño correcto para los casos de juicio. 3. Se elimina. Muchas excepciones existen porque alguien pidió algo hace años y nadie lo ha revisado. Automatizar es una excusa estupenda para quitarlas.

La tercera casilla es la que más valor genera y la que más resistencia encuentra. Merece la pena pelearla antes de escribir una línea de código: cada excepción que se conserva multiplica el coste de desarrollo y, sobre todo, el de mantenimiento.

¿Cómo documentar un proceso en una semana?

Un plan que funciona para un proceso de tamaño medio, con dedicación parcial:

| Día | Qué se hace | Quién | |---|---|---| | 1 | Delimitar alcance y sacar volúmenes de los sistemas | Responsable del proceso + sistemas | | 2 | Sesión de observación con quien ejecuta, caso real en pantalla | Ejecutor + analista | | 3 | Redactar el flujo principal con disparador, dato, regla y resultado | Analista | | 4 | Sesión de excepciones y clasificación en las tres casillas | Ejecutor + responsable | | 5 | Revisión del borrador por quien ejecuta y cierre de ambigüedades | Todos |

Con eso en la mano ya se puede pedir presupuesto a dos o tres proveedores y comparar peras con peras, que es imposible cuando cada uno interpreta a su manera un proceso contado de viva voz. Si además quieres estimar si merece la pena, el documento ya contiene lo necesario: volumen, pasos manuales y tiempo por caso. A partir de ahí se calcula si la automatización se paga, algo que tratamos con más detalle en la guía sobre automatización de procesos con IA.

Errores que se repiten

• Documentar el proceso que se quiere tener. Primero se documenta el actual. Rediseñar está bien, pero es un paso posterior y consciente, no un deslizamiento mientras se escribe.
• Dejar las reglas en «depende». Si nadie fija el umbral, lo acabará fijando el desarrollador por su cuenta y nadie se enterará hasta que salga mal.
• Olvidar los accesos. Un flujo precioso que necesita un usuario con permisos que tarda seis semanas en aprobarse no es un flujo, es una espera.
• No volver a tocar el documento. La documentación que no se actualiza cuando cambia una regla se convierte en mentira en tres meses. Nombra un dueño y mételo en el circuito de cambios.
• Documentar para la máquina y olvidar a las personas. El equipo que ejecuta hoy tiene que entender qué va a cambiar en su día a día, o el flujo nuevo se esquivará igual que se esquivaba el manual. Eso es gestión del cambio, y empieza en esta misma fase.

Preguntas frecuentes

¿Hace falta usar BPMN para documentar un proceso?

No es obligatorio. Un documento estructurado con pasos numerados, reglas explícitas y tablas de excepciones es perfectamente válido y lo entiende todo el mundo. BPMN ayuda cuando el proceso tiene muchas ramas paralelas o cuando la organización ya lo usa; si hay que enseñar la notación antes de empezar, suele restar más de lo que suma.

¿Cuánto tiempo del equipo consume documentar un proceso?

Para un proceso de tamaño medio, entre 6 y 10 horas de la persona que lo ejecuta, repartidas en dos o tres sesiones, más el trabajo de redacción de quien analiza. Procesos muy ramificados o que cruzan varios departamentos pueden necesitar el doble, y en ese caso conviene partirlos en subprocesos con fronteras claras.

¿Se puede automatizar sin documentar, directamente observando?

Se puede empezar observando, y de hecho es lo recomendable, pero el resultado de esa observación hay que escribirlo. Lo que no está escrito no se puede revisar, ni contratar, ni probar, ni mantener cuando la persona que lo sabía cambie de puesto.

¿Quién debe mantener el documento una vez el proceso está automatizado?

El responsable del proceso, no el área técnica. La documentación describe decisiones de negocio —umbrales, excepciones, criterios— y quien las cambia es quien debe reflejarlas. El equipo técnico mantiene la implementación; el dueño del proceso mantiene la verdad sobre cómo debe comportarse.

---

Documentar bien no es un requisito que impone el proveedor para cubrirse: es la parte del proyecto donde se decide si lo que se construye sirve. Si estás valorando automatizar algo y no sabes si lo que tienes documentado es suficiente, en la auditoría lo revisamos con los procesos encima de la mesa y te decimos qué falta antes de que nadie empiece a desarrollar. Y si prefieres contarlo en una conversación, hablemos.