En este artículo
Los proyectos de automatización que fracasan casi nunca fracasan por la tecnología. Fallan por decisiones que se tomaron antes de escribir la primera línea. Estos son los siete errores que más veces hemos visto, con lo que hay que hacer en su lugar.
1. Automatizar un proceso que estaba mal
Es el error número uno con diferencia. Un proceso lento y lleno de excepciones no mejora porque lo haga una máquina: se vuelve un proceso malo y rápido, y encima ahora es opaco, porque nadie ve lo que pasa por dentro.
Qué hacer: antes de automatizar nada, dibuja el proceso tal como es hoy. No como debería ser: como es. Casi siempre aparecen pasos que no sirven para nada y que se hacen porque siempre se han hecho. Quítalos primero. A veces el proyecto se acaba ahí, y es un buen resultado.
2. Empezar por lo más difícil
La tentación es atacar el proceso que más duele. Y el que más duele suele ser el más enrevesado, el que tiene más excepciones y el que depende de más gente. Resultado: tres meses de proyecto, mucha frustración y nada funcionando.
Qué hacer: el primer proyecto tiene que estar funcionando en semanas, no en meses. Elige algo aburrido, frecuente y predecible. Su valor real no es el tiempo que ahorra, es que el equipo vea que esto funciona.
Un primer proceso pequeño que sale bien genera más automatización dentro de la empresa que cualquier presentación. La gente empieza a proponer ideas por su cuenta.
3. Dejar al equipo fuera
Se decide arriba, se contrata fuera y un día aparece el sistema nuevo. La reacción previsible de quien lleva ocho años haciendo esa tarea es defenderse, porque lo lee como «te vamos a sustituir».
Qué hacer: habla con quien hace el trabajo antes de diseñar nada. Conoce todas las excepciones que tú no conoces, y su información es la diferencia entre un sistema que funciona y uno que se cae el primer día raro. Y sé explícito con el objetivo: quitar de en medio lo mecánico para dedicar el tiempo a lo que sí requiere una persona.
4. No medir el antes
Si no sabes cuánto se tardaba, no vas a poder demostrar que ha mejorado. Y sin esa prueba, el segundo proyecto se decide por intuición o simplemente no se decide.
Qué hacer: apunta dos números antes de empezar. Cuántas veces ocurre al mes y cuántos minutos se tarda cada vez. Una semana de anotarlo basta. Es el trabajo más aburrido del proyecto y el que más sirve después.
5. Construir sobre una plataforma de la que no puedes salir
Muchas herramientas son cómodas para empezar y difíciles de abandonar. Si dentro de dos años suben el precio, cambian las condiciones o cierran, y tus procesos no se pueden exportar, estás obligado a rehacerlo todo.
Qué hacer: antes de firmar, pregunta tres cosas. ¿Puedo exportar los flujos? ¿Dónde se guardan los datos? ¿Qué pasa si dejo de pagar? Si las respuestas son incómodas, ya sabes el riesgo que asumes. Es una de las razones por las que trabajamos con n8n autoalojado.
6. Quitar a la persona demasiado pronto
El sistema lleva una semana funcionando bien y alguien decide que ya no hace falta revisar. Dos semanas después aparece un caso raro, nadie lo detecta y el error se propaga durante días.
Qué hacer: retirar la supervisión de forma escalonada. Revisión total al principio, luego solo los casos que el sistema marque como dudosos, luego un muestreo periódico. Y siempre, siempre, un aviso automático cuando algo se salga de lo normal.
7. Montarlo y desentenderse
Una automatización no es un mueble: está conectada a servicios que cambian. Una herramienta actualiza su interfaz, una credencial caduca, un proveedor modifica su formato de factura. Un flujo sin mantenimiento acaba fallando en silencio, y lo peor de fallar en silencio es que nadie se entera hasta que el daño ya está hecho.
Qué hacer: que todo flujo avise cuando falla, por correo o por el canal que uséis. Y que alguien tenga asignada la responsabilidad de mirarlo. Puede ser interno o externo, pero tiene que tener nombre.
Señales de que un proyecto va mal
- Llevas más de un mes en reuniones y no hay nada funcionando.
- Nadie sabe decirte cuántas horas ahorra esto exactamente.
- El proveedor habla de tecnología y no de tu proceso.
- El equipo que va a usarlo no ha participado en ninguna conversación.
- La propuesta empieza por la herramienta y no por el problema.
- No hay forma de probar una parte pequeña antes de comprometerse con todo.
Si reconoces tres o más, para y replantea. Sale mucho más barato que terminarlo.
Nuestra forma de evitar estos siete errores está descrita en la página de proceso: diagnóstico primero, alcance y precio cerrados después, y un primer proceso funcionando antes de comprometer nada más.