Por qué fracasan los proyectos de automatización (y cómo evitarlo)

Cuando llego a una empresa a hablar de automatización, más o menos la mitad ya lo intentó antes. Compraron una herramienta, contrataron a alguien, hicieron un piloto. Y quedó ahí: a medias, sin usar, o funcionando tan mal que volvieron al Excel.

Ese antecedente es lo primero que reviso, porque el patrón se repite con una regularidad que ya no me sorprende. Y casi nunca tiene que ver con la tecnología elegida.

Lo escribo desde los dos lados de la mesa. Dirijo el área de TI de una empresa de logística, así que defiendo presupuestos, le explico a operaciones por qué algo tarda y evalúo propuestas de proveedores. También estoy del lado del que construye. Los errores de abajo los he cometido, los he visto cometer y los he tenido que arreglar.

Si estás evaluando automatizar algo —o si ya lo intentaste y no funcionó—, esto es lo que conviene revisar antes de volver a invertir.

Error 1: automatizar un proceso que nadie definió

Este es el más común y el más caro.

Le preguntas a tres personas cómo se aprueba una orden de compra y te dan tres respuestas distintas. Una dice que lo firma el gerente. Otra que depende del monto. La tercera te cuenta que en la práctica se manda por WhatsApp y se regulariza después.

Si automatizas eso, automatizas el caos. Y el caos automatizado corre más rápido, lo cual empeora las cosas: ahora los errores se producen a escala y con sello de aprobación del sistema.

Cómo se detecta a tiempo

Hay una pregunta que lo revela en diez minutos: pídele a tres personas distintas que te describan el proceso, por separado, y compara. Si las tres versiones no coinciden, no tienes un proceso. Tienes una costumbre con excepciones.

Otra señal: cuando preguntas "¿y si pasa X?" y la respuesta es "depende" o "eso lo ve Marta". Un proceso que vive en la cabeza de Marta no se puede automatizar hasta que salga de ahí.

Qué hacer en su lugar

Antes de escribir una línea de código, siéntate con quien ejecuta el proceso —no con quien lo diseñó— y dibuja lo que realmente pasa. Incluidos los atajos. Especialmente los atajos, porque casi siempre existen por una razón válida que el proceso oficial ignora.

Ese ejercicio tiene un efecto secundario incómodo y valioso: en más de una ocasión termina sin automatización. El proceso tenía cuatro pasos innecesarios; los quitas y el problema desaparece. Sale más barato para el cliente y ahí se acaba el proyecto.

Está bien que así sea. Un proveedor que nunca te ha dicho "esto no hace falta automatizarlo" probablemente no te lo va a decir nunca.

Error 2: empezar por lo más complejo

La lógica parece razonable: "si vamos a invertir, ataquemos el problema grande".

El problema es que el proceso grande casi siempre es el más entrelazado, el que toca más áreas y el que tiene más excepciones. Un proyecto así tarda meses en dar su primer resultado visible. Y en esos meses pasan cosas:

• Cambia una prioridad del negocio y el proyecto pierde patrocinio.
• Se va la persona que entendía el proceso.
• El equipo pierde la fe porque no ve nada funcionando.
• Aparece un costo que nadie presupuestó y hay que justificar lo invertido sin resultados que mostrar.

La cuenta que casi nadie hace

Un proyecto de seis meses no cuesta seis veces lo que uno de un mes. Cuesta bastante más, porque además del dinero consume algo que no se repone: la paciencia de la organización.

Cada semana sin resultado visible gasta un poco de esa paciencia. Cuando se acaba, da igual que el proyecto esté técnicamente bien encaminado: se cancela.

Qué hacer en su lugar

Elige el proceso con la mejor relación entre impacto y simplicidad. No el de mayor impacto: el de mejor relación. Que salga a producción en dos a cuatro semanas, con gente real usándolo.

Ese primer resultado hace dos cosas. Prueba que el enfoque funciona, y —más importante— te enseña cómo trabaja de verdad tu operación cuando le cambias algo. Esa información vale más que cualquier plan a seis meses, porque los planes a seis meses se escriben con supuestos y este se escribe con hechos.

Si no sabes por cuál empezar, hay una forma rápida de ordenarlos: calcula lo que te cuesta cada proceso al año y empieza por el que tenga el número más alto con la operación más simple.

Error 3: medir la automatización, no el negocio

"El bot atendió 4.000 conversaciones este mes."

Vale. ¿Y eso qué significa?

Puede significar que resolviste 4.000 consultas sin ocupar a nadie. O puede significar que 4.000 personas se pelearon con un menú y la mitad acabó llamando igual, con el agravante de que ahora están molestas.

El número de interacciones no es un resultado. Es actividad.

Los números que sí dicen algo

Un indicador sirve si se puede medir antes y después, y si su movimiento se traduce en dinero o en tiempo. Por ejemplo:

La diferencia entre las dos columnas es que la primera la puede mover un proveedor sin que tu negocio mejore, y la segunda no.

Mide antes de empezar

Esto es lo que casi nadie hace y lo que más adelante impide saber si el proyecto sirvió. Si no tienes el número de partida, cualquier resultado posterior es una anécdota.

No hace falta un sistema de medición: una semana de conteo a mano, hecho por quien vive el proceso, alcanza para tener una línea base defendible.

Error 4: dejar fuera a quien hace el trabajo hoy

El proyecto lo decide gerencia, lo diseña TI, lo construye un proveedor. Y el día del lanzamiento se le presenta al equipo que lleva cinco años haciendo ese trabajo a mano.

Pasan dos cosas, y las dos son malas.

La primera es técnica: el equipo conoce veinte excepciones que nadie documentó, y aparecen todas en la primera semana. "¿Y cuando el cliente paga en dos partes?" "¿Y cuando viene sin orden de compra porque es urgente?" El sistema no las contempla y hay que parchearlo en caliente.

La segunda es más difícil de arreglar: si nadie les explicó para qué es esto, van a asumir lo peor. Y una persona que cree que un sistema la va a dejar sin trabajo no colabora, no reporta los fallos que encuentra y, cuando algo falla, vuelve al método anterior sin avisar.

Qué hacer en su lugar

Involúcralos desde el levantamiento, no desde la capacitación. Que una persona del equipo operativo sea parte del proyecto, no un receptor del proyecto.

Y sé explícito con el mensaje. En mi experiencia dirigiendo la adopción de IA en áreas que no son de tecnología —contabilidad, ventas, marketing, seguridad y salud en el trabajo—, lo que funciona es enseñar la herramienta como algo que les quita de encima la parte que odian, no como algo que los supervisa. La diferencia no es de discurso: es de a quién le das el control de la herramienta.

Error 5: tratar la adopción como un evento

Se entrega el sistema, se hace una capacitación de dos horas, se manda un manual en PDF y se da por terminado.

Tres meses después, la mitad del equipo volvió a su Excel paralelo. No porque el sistema sea malo, sino porque en la primera semana alguien tuvo una duda, no encontró a quién preguntarle, resolvió como pudo y nunca volvió.

La adopción no es un evento. Es las primeras seis semanas.

Qué funciona

• Alguien a quien preguntar, identificado por nombre, durante el primer mes. No un correo de soporte: una persona.
• Revisión a los quince días mirando el uso real, no preguntando si les gustó. Quién entró, quién no, dónde se atascan.
• Documentación corta y operativa, escrita para quien hace el trabajo. Un manual de cuarenta páginas no lo lee nadie; una página por tarea, sí.
• Arreglar rápido lo pequeño. El primer fallo que se reporta y no se arregla enseña que reportar no sirve, y a partir de ahí dejan de reportar.

Error 6: construir algo que solo el proveedor entiende

Este no duele al principio. Duele al año.

El sistema funciona, pero nadie en tu empresa sabe cómo. No hay documentación, los accesos los tiene el proveedor, y cualquier cambio —por pequeño que sea— pasa por una cotización.

En ese punto ya no tienes una automatización. Tienes una dependencia.

Qué exigir desde el contrato

• Los accesos a tu nombre. El proyecto en la nube, los dominios, las claves: todo en cuentas tuyas, con el proveedor invitado. No al revés.
• El código en un repositorio tuyo, desde el primer día y no al final.
• Documentación técnica y operativa como entregable con fecha, no como promesa.
• Una sesión de transferencia con quien vaya a mantenerlo, aunque hoy no sepas quién será.

Si un proveedor pone problemas con cualquiera de los cuatro, esa es la información más valiosa que vas a conseguir en toda la negociación.

La señal de alarma más fiable

Después de evaluar bastantes propuestas, la que mejor predice un mal proyecto no es el precio ni la tecnología.

Es esta: el proveedor que no te hace preguntas incómodas.

El que llega con la solución antes de entender el problema. El que no te pregunta qué pasa cuando el proceso falla, ni quién lo ejecuta hoy, ni qué pasó con el intento anterior. El que te dice que sí a todo.

Un diagnóstico serio incomoda un poco, porque saca a la luz que el proceso no está tan definido como se creía. Esa incomodidad es la señal de que alguien está mirando de verdad.

El orden que sí funciona

Resumido, y en este orden:

• Entiende el proceso real, hablando con quien lo ejecuta, incluidos los atajos.
• Mide la línea base antes de tocar nada, aunque sea a mano durante una semana.
• Elige lo pequeño con buen retorno, no lo grande. Producción en dos a cuatro semanas.
• Involucra al equipo operativo desde el levantamiento, no desde la capacitación.
• Acompaña seis semanas, con alguien a quien preguntarle.
• Quédate con el control: accesos, código y documentación a tu nombre.
• Mide el número del negocio, no la actividad del sistema.

Ninguno de estos pasos es tecnológico. Esa es justamente la conclusión: los proyectos de automatización no fracasan por la herramienta que se eligió. Fracasan porque se saltaron el método.

Por dónde seguir

Si quieres ver cómo se aplica esto a un sector concreto, estos casos tienen el mismo método aplicado a problemas específicos:

• Dejar de contestar "¿dónde va mi envío?" cuarenta veces al día, en operación logística.
• Bajar las inasistencias de una clínica sin que nadie tenga que llamar.
• Responder leads inmobiliarios en minutos en lugar de horas.
• Qué automatizar primero en un e-commerce que ya factura.

Y si lo que quieres es ponerle número a lo que te cuesta hoy un proceso manual, la calculadora del costo del trabajo manual son cinco preguntas y no pide registro para enseñarte el resultado.