Documentar los clics no sirve: eso ya lo guarda la herramienta
Cuando alguien busca cómo documentar automatizaciones, casi siempre acaba haciendo lo mismo: capturas de pantalla del editor, un paso a paso de qué módulo va detrás de cuál y una descripción de cada nodo. Una tarde entera de trabajo. Y es trabajo tirado, porque estás copiando a mano lo único que la herramienta ya sabe sola.
Make, n8n, Zapier o Power Automate te enseñan el grafo del flujo en dos clics: qué lo dispara, qué viene después, qué campo se mapea con qué campo. Eso está vivo y siempre al día. Tu captura no: envejece la primera vez que el fabricante mueve un menú o cambia el color de un botón, y a partir de ahí documenta una interfaz que ya no existe.
El efecto secundario es peor que el desfase. Una documentación que se ve vieja deja de leerse, y en cuanto deja de leerse todo el mundo asume que el resto también miente. Un manual que nadie abre es exactamente igual de útil que no tener manual, pero encima hay que mantenerlo.
El grafo te dice qué hace el flujo. No te dice por qué. Y el porqué no está en ninguna parte salvo en la cabeza de quien lo montó.
El bus factor: si solo una cabeza sabe el porqué, ese es tu riesgo real
El bus factor de un sistema es cuánta gente se puede ir antes de que ese sistema quede sin nadie capaz de entenderlo. En automatización de empresa el número casi siempre es uno. Una persona montó el flujo, esa persona sabe por qué el umbral son 48 horas y no 72, y esa persona es a la que se llama cuando pasa algo raro.
No hace falta un autobús. Basta con unas vacaciones, un cambio de equipo, una baja larga o una oferta mejor. Y lo incómodo es que el flujo no se rompe —eso sería fácil de detectar—: sigue ejecutándose puntualmente todos los días. Lo que se rompe es la capacidad de cambiarlo.
Se nota mucho antes de que llegue el desastre. Los síntomas de bus factor uno son siempre los mismos cinco:
- Nadie toca el flujo. Los cambios se pegan por fuera, en un flujo nuevo, porque modificar el original da miedo.
- Cada cambio de negocio abre una discusión arqueológica. «¿Y esto por qué está así?». Nadie lo sabe, así que se deja como está.
- Aparece un duplicado. Alguien monta otro flujo que hace casi lo mismo porque salía más barato empezar de cero que entender el que había.
- No se puede explicar una decisión. Llega la pregunta de un cliente o de un auditor sobre por qué el sistema hizo lo que hizo, y la respuesta honesta es que no se sabe.
- El flujo se congela. Cuando la persona se va, se queda encendido y nadie se atreve ni a cambiarlo ni a apagarlo.
Fíjate en que ninguno de esos cinco síntomas se cura con una captura de pantalla del editor.
Lo único que hay que escribir: la regla de negocio
Una regla de negocio es la decisión humana que el flujo toma en tu nombre mientras nadie mira. No es «si el campo estado es igual a pendiente, enviar correo». Es: «al cliente que lleva 48 horas sin contestar le insistimos una vez, porque el contrato tipo promete respuesta en dos días laborables y no queremos incumplirlo; salvo que sea cuenta grande, y entonces avisa la persona de cuentas en lugar del sistema».
Todo lo demás —el módulo, el orden, el mapeo de campos— es implementación. Cambia el día que cambies de herramienta y no pasa nada. La regla sobrevive a la herramienta: si mañana migras de Zapier a n8n, la regla es lo único que tienes que llevarte contigo, y es justamente lo único que no está escrito en ningún sitio.
Por qué esa condición y no otra
Cada número que aparece en un flujo salió de algún sitio: un compromiso de servicio, una promesa comercial, un requisito legal o —lo más habitual— una reunión de hace dos años. Escribe cuál. «48 horas porque es el plazo que promete el contrato tipo» es una condición revisable el día que cambie el contrato. «48 horas» a secas es un número intocable que nadie se atreverá a mover nunca.
Qué excepción cubre
Las ramas raras de un flujo casi nunca son un capricho: son cicatrices. Ese filtro que descarta los pedidos por debajo de cierto importe está ahí porque un día entró una tanda de pruebas y ensució la facturación. Escribir la cicatriz evita las dos cosas que pasan cuando no está escrita: que alguien quite el filtro por «limpieza» y el incidente vuelva, o que nadie se atreva a tocarlo aunque el motivo original desapareciera hace años.
A quién avisa y qué pasa si nadie contesta
Lo que revienta en producción no suele ser la lógica: es el final abierto. Un flujo que escala a una persona tiene que decir a quién, por qué canal, con qué plazo — y qué hace si esa persona no responde. Si la respuesta es «se queda esperando indefinidamente», eso también es una decisión y hay que escribirla, porque el día que un pedido lleve una semana colgado alguien preguntará si es un fallo o el diseño.
Pegados a la regla van tres datos que no son negocio pero se pierden con la misma facilidad: el dueño —una persona con nombre y apellidos, no un departamento—, las credenciales que usa —qué cuenta, de quién y con qué permisos— y los sistemas que toca, separando lo que lee de lo que escribe. Lo que escribe es lo que te puede desordenar el CRM un martes por la tarde.
Aquí esta guía roza la gobernanza y el control de la automatización sin ser lo mismo. La gobernanza pone permisos, auditoría y freno de mano: es control. Esto es conocimiento. Puedes tener control perfecto sobre un flujo que nadie entiende, y entonces lo único que puedes hacer con precisión es apagarlo.
La ficha mínima: una página por flujo, ocho campos
Si la ficha no cabe en una página, no se va a mantener. Ese es el criterio de diseño entero. Ocho campos, respuestas de dos líneas, y se acabó:
- Qué produce. La salida concreta, no la categoría. «Deja una fila por pedido en la hoja de logística», no «gestiona pedidos».
- Dueño. Una persona. Si el nombre que aparece ya no trabaja aquí, la ficha está caducada y eso se ve de un vistazo.
- Regla de negocio. El porqué de cada condición, con su origen. Es el campo largo y el único que justifica que la ficha exista.
- Excepciones. Qué caso raro cubre cada rama y qué incidente la puso ahí.
- A quién avisa. Persona o cola, canal, plazo, y qué pasa si nadie contesta.
- Credenciales. Qué cuenta usa, de quién es y con qué permisos. Ningún secreto dentro de la ficha, obviamente: solo el nombre de la cuenta.
- Sistemas que toca. Qué lee y qué escribe, en dos listas separadas.
- Qué NO hace. El límite explícito del flujo.
El octavo campo es el que nadie pone y el que más discusiones ahorra. «No toca facturas ya emitidas», «no escribe en el ERP», «no responde fuera de horario». Sin ese campo, cada incidente empieza con veinte minutos de descartar si fue este flujo — y en cuanto pasa un año, todo el mundo le atribuye poderes que nunca tuvo.
Dónde vive la ficha para que no envejezca
Aquí está la parte incómoda, y la digo sin rodeos: si la ficha vive en un Confluence, un Notion o una carpeta de Drive aparte, va a envejecer. No es culpa de la herramienta, es la distancia. Quien cambia el flujo está dentro del editor, con prisa, arreglando algo; si actualizar la ficha significa abrir otra pestaña, buscar la página y editar, no lo va a hacer. Una vez no pasa nada. Al décimo cambio, la ficha miente.
La ficha tiene que vivir donde vive el flujo. Tres sitios que funcionan de verdad, de menos a más esfuerzo: el campo de descripción o las notas del propio escenario —lo tienen Make, n8n, Power Automate y casi todas—, que es donde menos fricción hay porque ya estás dentro; un README junto al JSON exportado si versionas los flujos en un repositorio, que además te regala historial de cambios; y una nota fijada en el canal donde el flujo publica, cuando su salida es una notificación.
El wiki no desaparece: cambia de papel. Deja de ser donde vive la documentación y pasa a ser el índice —qué flujos existen, quién es el dueño de cada uno y dónde está su ficha—. Eso sí aguanta, porque es una lista corta que cambia poco. Lo que no aguanta es el detalle lejos del sitio donde se toca.
Actualizar la ficha es parte de cambiar el flujo, no una tarea aparte
Toda la documentación que se muere se muere igual: alguien la escribe en un esfuerzo puntual y, a partir de ahí, mantenerla es «una tarea» que compite con el trabajo real. Compite y pierde, siempre, porque nunca es urgente y nunca hay nadie esperándola.
La única forma de que no pase es sacarla de la lista de tareas y meterla dentro de la definición de terminado. Cambiar un flujo no está terminado cuando el flujo funciona: está terminado cuando el flujo funciona y su ficha dice lo que hace ahora. Son dos minutos si la ficha está a un clic, y son dos minutos que solo aparecen si nadie los trata como opcionales. Lo demás —recordatorios trimestrales, campañas de documentación, auditorías internas— es teatro con calendario.
Con eso cierra el círculo el resto del cluster. Un flujo con ficha y con dueño es un flujo que se puede mantener vivo sin adivinar nada, y es un flujo que no acaba convertido en una de esas automatizaciones zombis que nadie apaga porque nadie sabe qué se rompe. Documentar no mantiene ni retira: hace que mantener y retirar sean decisiones en vez de apuestas. Si estás montando todo esto desde cero, el mapa completo está en la guía de automatizar con IA.