El coste real de una automatización

Cuando se evalúa una automatización, la conversación gira casi siempre alrededor de una sola cifra: lo que cuesta construirla. Es la parte más visible del coste y, con frecuencia, la más pequeña. La decisión que trata este artículo es cómo aprobar —o descartar— una automatización mirando lo que costará a lo largo de su vida, no solo el presupuesto inicial. No vas a encontrar números aquí, porque cada caso tiene los suyos; vas a encontrar la estructura del coste, que es lo que permite hacer las preguntas correctas antes de firmar.

El presupuesto mide la construcción; el coste llega después

Una automatización no es un gasto puntual, es un compromiso: desde el día que entra en marcha, forma parte de tu operación, y todo lo que forma parte de la operación hay que sostenerlo. El presupuesto que apruebas mide las semanas de construirla; el coste real se reparte por los años de tenerla funcionando. Esa asimetría no es un defecto de los proveedores ni una letra pequeña: es la naturaleza de cualquier pieza que se integra en un negocio vivo. El problema no es que exista, sino decidir como si no existiera.

Lo que viene a continuación son las cuatro partidas de ese coste que casi nunca aparecen en la propuesta.

Las dependencias que crea

Toda automatización conecta piezas: el correo con la hoja de cálculo, el ERP con el banco, el formulario web con el CRM. Cada conexión es una apuesta silenciosa: presupone que la pieza de al lado seguirá comportándose igual. Y las piezas no se están quietas. El proveedor del ERP actualiza su sistema, alguien renombra una columna en la hoja compartida, cambia el formato de un fichero que llega de fuera, caduca una credencial. Ninguno de esos cambios es culpa de la automatización, y cualquiera de ellos puede romperla.

El efecto práctico es sutil y caro: a partir de ahora, cada cambio en los sistemas vecinos tiene un coste añadido que antes no existía —comprobar que la automatización sigue funcionando y adaptarla si no—. La automatización convierte cambios ajenos en trabajo propio. Cuantas más piezas toque y más ajenas sean esas piezas, más frentes quedan abiertos. Por eso dos automatizaciones que hacen «lo mismo» pueden tener costes de vida radicalmente distintos: una toca dos sistemas estables de la casa; la otra, cinco sistemas de terceros que cambian cuando quieren.

El conocimiento: quién la entiende dentro

Quien la construyó —proveedor o empleado— tiene el mapa en la cabeza: qué hace, en qué orden, por qué se decidió así y qué atajos se tomaron. Si ese mapa no se traslada a nadie más, el día que algo falle tendrás una situación peor que la del proceso manual que sustituiste: un proceso que nadie sabe ejecutar a mano y que nadie sabe arreglar. Es la versión operativa de la dependencia de una persona clave, con un agravante: el proceso manual al menos lo entendía alguien.

Este coste se paga sí o sí; la única elección es cuándo y a qué precio. Se puede pagar barato al principio —documentación mínima, una sesión de traspaso, una persona interna que entienda el qué aunque no domine el cómo— o caro después, en forma de urgencias, de dependencia total del proveedor o de tener que rehacer la pieza porque salía más barato que descifrarla. Al evaluar una propuesta, «¿qué queda documentado y quién de mi equipo lo va a entender?» vale más que la mayoría de las preguntas técnicas.

La operación: el trabajo no desaparece, cambia de forma

«Se hace sola» es una descripción del caso bueno. Alrededor del caso bueno hay excepciones: el pedido con un formato raro, el cliente que no existe todavía en el sistema, el aviso que hay que mirar. Automatizar no elimina el trabajo humano; lo transforma —de ejecutar la tarea a vigilar el proceso y resolver lo que no encaja—. Ese trabajo transformado es menor que el original si el proceso era estable y las reglas claras; puede ser mayor si se automatizó algo lleno de excepciones. Conviene preguntarlo antes: ¿cuántos casos van a caer fuera de la regla, y quién los va a atender?

La salida: qué pasa si hay que apagarla

Es la partida que nadie presupuesta. Lo que se automatiza, se olvida: al cabo de un tiempo, nadie recuerda del todo cómo se hacía a mano, la persona que lo hacía cambió de puesto y el conocimiento operativo se ha evaporado. Si un día hay que apagar la automatización —el proveedor desaparece, un sistema del que depende se sustituye, el proceso cambia de arriba abajo—, volver al manual no es volver: es reconstruir. No hace falta un plan de contingencia formal; hace falta haberse hecho la pregunta y que la respuesta no sea «no lo sé»: si mañana no estuviera, ¿qué haríamos esa semana?

Cómo usar esta estructura para decidir

Nada de esto es un argumento contra automatizar. Es un argumento contra presupuestar solo la construcción. Una buena automatización aguanta la cuenta completa sin despeinarse: proceso estable, pocas dependencias y bien elegidas, conocimiento dentro de la casa, excepciones acotadas. Una mala solo parece rentable mientras se ignoran cuatro preguntas:

1. ¿Qué sistemas toca, de quién son, y qué pasa cuando cambien?
2. ¿Quién de dentro la entenderá, y qué queda documentado?
3. ¿Cuántas excepciones va a generar y quién las atenderá?
4. Si mañana hubiera que apagarla, ¿qué haríamos?

Si el ahorro prometido solo sale a cuenta ignorando estas cuatro respuestas, no sale a cuenta. Y hay una forma de que toda esta estructura de coste juegue a favor en lugar de en contra: automatizar procesos que ya están entendidos y ordenados, porque casi todo lo anterior se encarece cuando se automatiza desorden. Ese orden previo tiene su propio criterio, y lo contamos en antes de automatizar.