Cuando una automatización sale mal, la conversación posterior casi nunca es sobre tecnología. Es sobre una excepción que nadie mencionó, un paso que dos personas hacían distinto o una decisión que se tomaba «a criterio» y resultó que el criterio no estaba escrito en ningún sitio.
Todo eso se descubre documentando. Y documentar cuesta dos horas, mientras que descubrirlo después cuesta rehacer el trabajo.
Qué significa documentar, en concreto
No es escribir un manual bonito. Es responder por escrito a seis preguntas:
| Pregunta | Qué respuesta sirve |
|---|---|
| ¿Qué lo dispara? | Un hecho observable: llega un mensaje, se envía un formulario, son las 8:00 del lunes. No «cuando hace falta». |
| ¿Qué pasos tiene? | En orden, con verbos. Cada paso, una acción. |
| ¿Dónde se decide algo? | Los «si pasa esto, entonces aquello», con la regla explícita. |
| ¿Qué información entra y sale? | Qué datos se necesitan al empezar y qué queda al terminar, y dónde. |
| ¿Quién hace cada paso? | Un rol por paso. Si son dos, hay que dividir el paso. |
| ¿Qué pasa cuando algo falla? | Falta un dato, el cliente no responde, el sistema no está disponible. |
Cómo sacarlo de la cabeza del equipo
La persona que hace la tarea a diario es la que menos capaz es de describirla, y no por falta de ganas: lleva tanto tiempo haciéndola que la mitad de los pasos se le han vuelto invisibles. Tres técnicas que funcionan:
-
Míralo en vivo, sin interrumpir
Siéntate al lado mientras lo hace con un caso real y anota. Vas a ver tres cosas que no estaban en ninguna descripción previa.
-
Pide que lo explique a alguien que no sabe
Explicárselo a una persona nueva obliga a nombrar lo que se da por supuesto. Graba esa explicación, con permiso.
-
Pregunta por la última vez que salió mal
Es la pregunta más productiva de todas. Las excepciones no aparecen describiendo el caso normal: aparecen recordando el caso raro.
«¿Y si viene un caso distinto, qué haces?» Repítela hasta que la respuesta sea «entonces ya pregunto». Ahí está el límite real del proceso, y ahí es donde debe entrar una persona en el flujo automatizado.
Qué hacer con las excepciones
Aparecerán muchas. El error es intentar automatizarlas todas: cada excepción cubierta multiplica la complejidad y las posibilidades de fallo.
Clasifícalas en tres grupos:
- Frecuentes y con regla clara. Entran en el flujo como condición.
- Poco frecuentes o sin regla clara. El flujo las detecta, se detiene y avisa. Las resuelve una persona.
- Excepciones que no deberían existir. Aparecen porque alguien saltó un paso en su momento. No se automatizan: se corrigen.
Ese tercer grupo es uno de los beneficios menos comentados de este ejercicio: documentar saca a la luz procesos que se estaban haciendo mal sin que nadie lo hubiera notado.
El formato: una hoja, no veinte
Si el documento no cabe en una página, el proceso es demasiado grande para ser una sola automatización. Divídelo.
Una hoja con: nombre del proceso, disparador, pasos numerados, condiciones, punto de revisión humana, qué hacer si falla, responsable y fecha de última revisión. Con eso, cualquier persona técnica puede estimar el trabajo, y cualquier persona nueva puede ejecutarlo a mano.
El beneficio que aparece aunque no automatices
Vale la pena decirlo claro: el documento tiene valor por sí solo, incluso si el proyecto de automatización se pospone.
- Una persona nueva se incorpora en días en lugar de semanas.
- Las vacaciones de alguien dejan de ser un problema.
- Se puede delegar sin supervisar cada paso.
- Se ve dónde se pierde el tiempo, que casi nunca está donde uno creía.
Cómo empezar mañana
Elige el proceso que más se repita en tu semana. Bloquea dos horas: una para observarlo en vivo, otra para escribirlo. Pásaselo a quien lo ejecuta y pídele que señale lo que falta o lo que está mal.
Esa revisión es la parte más valiosa. Y cuando el documento esté corregido, tendrás lo único que de verdad hace falta para que una automatización salga bien a la primera.
