La demo siempre sale bien. Se coge el proceso tal como funciona el día de la reunión, se automatiza, se cronometra y se enseña la cifra: «de 40 horas al mes a 8». Tres semanas después de la puesta en marcha cambia una regla de descuentos, el proveedor rediseña el formato de sus albaranes y alguien de finanzas añade un campo nuevo al informe. La automatización sigue ahí, pero ya no automatiza el proceso: automatiza la versión del proceso que existía el día de la demo.
La tesis en una línea: el criterio que falta en casi todas las listas de «qué automatizar» no es el volumen ni el ahorro, es la estabilidad. Un proceso que cambia cada mes consume en mantenimiento lo que libera en ejecución, y el cálculo de retorno se hace siempre contra una versión congelada que ya no existe. Si el proceso se mueve más deprisa que tu capacidad de reajustarlo, no lo automatices todavía: estabilízalo primero.
Automatizar un proceso que cambia a menudo cuesta más de lo que libera
Las listas de candidatos puntúan tres cosas: cuántas veces se repite la tarea, cuánto tiempo lleva y cuánto cuesta el error. Las tres miden el proceso hoy. Ninguna pregunta cuánto va a parecerse a sí mismo dentro de seis meses, que es precisamente lo que decide si la automatización envejece bien o se convierte en una factura recurrente. Por eso un proceso puede sacar la nota más alta en volumen y la peor en retorno real.
La respuesta corta a la pregunta que nos hacen es esta: sí, se puede automatizar un proceso que cambia a menudo, pero no sale a cuenta si el coste de reajustarlo cada vez que cambia se acerca a las horas que libera. Y el mantenimiento rara vez se presupuesta, porque en el momento de la demo todavía no ha ocurrido ningún cambio.
La aritmética: horas liberadas menos horas de reajuste
La cuenta cabe en una línea: horas netas al mes = horas liberadas al mes − (cambios al año × horas por cambio ÷ 12). Una «hora por cambio» incluye lo que casi nunca se apunta: entender qué ha cambiado, modificar el flujo, volver a probarlo con casos reales y desplegarlo sin romper lo que ya funcionaba. Un ejemplo con cifras inventadas solo para enseñar la cuenta (sustitúyelas por las tuyas), sobre un proceso que consume 40 horas al mes a mano y que una automatización estable deja en 8:
| Cómo se comporta el proceso | Cambios al año × horas por cambio | Horas de reajuste al mes | Horas netas liberadas al mes |
|---|---|---|---|
| Estable | 1 × 10 | 0,8 | 31,2 |
| Cambia cada trimestre | 4 × 12 | 4 | 28 |
| Cambia cada mes, cambios de parámetro | 12 × 20 | 20 | 12 |
| Cambia cada mes, cambios de estructura | 12 × 40 | 40 | −8 |
Fíjate en la última fila: el proceso automatizado cuesta más que hacerlo a mano. No es un caso exótico, es lo que ocurre cuando el cambio no es un valor que se ajusta sino una forma de trabajar que se rehace. Y la cuenta ni siquiera incluye la supervisión, que se resta aparte, como explicamos en por qué las horas liberadas no son ahorro.
Qué significa «cambia» (no todo cambio cuesta lo mismo)
Decir que un proceso «cambia mucho» no sirve: hay cambios que se absorben en minutos y cambios que obligan a reescribir. La diferencia está en qué se mueve:
- Cambian los valores. Un umbral, una tarifa, una lista de excepciones. Si esos valores viven en una tabla fuera del flujo, el cambio cuesta minutos. Si están escritos dentro de la lógica, cuesta una intervención.
- Cambia el formato de lo que entra. Un proveedor que rediseña su factura o un cliente que cambia su plantilla. Cuesta según lo robusta que sea la lectura de entrada, y es el cambio que más rompe en silencio.
- Cambia el sistema por el que pasa. Una migración de ERP, un CRM nuevo, una API que se retira. Es un cambio de estructura: cuesta días, no minutos.
- Cambia el criterio de quien decide. Lo que ayer se aprobaba solo, hoy lo revisa una persona. Es el más caro, porque el flujo sigue funcionando y produce decisiones equivocadas sin que salte ninguna alarma.
Cómo medir la estabilidad antes de automatizar: cuatro preguntas
No hace falta un modelo. Hacen falta cuatro respuestas, y se obtienen en una tarde con la persona que ejecuta el proceso:
- ¿Cuántas veces ha cambiado en los últimos doce meses? Con fecha. Mira el historial de la instrucción de trabajo, los correos de «a partir de ahora se hace así» y las incidencias abiertas. Si nadie recuerda un cambio, probablemente son muchos pequeños.
- ¿Qué se movió cada vez: un valor, un formato o la estructura? Clasifica cada cambio con la lista de arriba. Tres cambios de valor y uno de estructura no pesan igual que cuatro de estructura.
- ¿Quién decide el cambio y avisa antes? Si el cambio llega de fuera (un proveedor, un regulador, un cliente) y sin aviso, el reajuste será siempre urgente y siempre tarde.
- ¿Está escrito el proceso? Un proceso que solo existe en la cabeza de quien lo ejecuta no se puede reajustar: primero hay que extraerlo. Es la razón por la que documentar tus automatizaciones no es burocracia, es lo que hace barato el cambio siguiente.
Qué hacer con el proceso que cambia cada mes
Hay cuatro salidas, y la primera casi nadie la considera porque suena a no hacer nada:
- Estabilizarlo primero. Congelar una versión durante un trimestre, decidir quién autoriza los cambios y acumularlos en una sola ventana. A veces el proceso cambia cada mes porque nadie ha decidido cómo debe ser, no porque el negocio lo exija.
- Automatizar el núcleo estable y dejar la cola variable a una persona. El 80 % de los casos siguen la regla de siempre; el 20 % que cambia lo resuelve alguien. Es menos espectacular en la demo y mucho más barato de mantener.
- Sacar las reglas del flujo. Que los umbrales, tarifas y excepciones vivan en una tabla que el responsable del proceso pueda editar sin tocar la automatización.
- Esperar. Si el cambio grande ya está en camino (una migración, una nueva normativa), automatizar ahora es pagar dos veces.
Sea cual sea la salida, el reajuste necesita una red: cada cambio debería pasar por una prueba antes de tocar producción, porque un proceso inestable con una automatización sin pruebas es exactamente donde nacen las incidencias que descubre el cliente.
Cuándo sí merece la pena automatizarlo aunque cambie
Hay excepciones razonables. Si el volumen es muy alto y los cambios son casi siempre de valor (no de estructura), el reajuste se diluye y la cuenta sale. Si el coste del error es muy grande, puede compensar pagar el mantenimiento por la trazabilidad. Y si el proceso cambia porque el negocio está en plena transformación, automatizar el núcleo estable y dejar lo demás en manos de una persona sigue siendo mejor que esperar a que todo se calme. Lo que no es razonable es descubrir el coste de mantenimiento cuando ya has firmado el proyecto.
Por dónde empezar
Por la lista, antes que por la herramienta: añade una columna de estabilidad a tu criterio de selección y puntúala con las cuatro preguntas. La guía de qué procesos automatizar con IA explica cómo ordenar candidatos por tarea; esta columna decide cuáles entran los primeros. Y si prefieres que alguien lo mida contigo sobre tus procesos reales, es justo lo que hacemos al auditar tus procesos para IA: qué es apto, cuánto cuesta de verdad y en qué orden entra, con la estabilidad como filtro desde el primer día.
La frase para llevarse es la del principio: la demo se hace contra el proceso de hoy, y tú vas a convivir con el de dentro de seis meses. Elige primero el que menos se va a mover.