La estadística que se repite en la industria es que la mayoría de los proyectos de transformación digital no cumple sus objetivos. El número exacto varía según quién lo mida y qué cuente como fracaso, pero la observación de fondo se sostiene: se gasta mucha plata en sistemas que después nadie usa.
Lo interesante es que las causas casi nunca son técnicas.
Causa 1: el sistema funciona pero nadie lo usa
Es la más frecuente y la más frustrante, porque desde afuera el proyecto parece exitoso. El software anda, cumple lo que decía el contrato, se entregó en fecha. Y seis meses después el equipo sigue con la planilla.
Las razones reales suelen ser tres:
No participaron del diseño. A quien opera el proceso todos los días no se le preguntó nada, y el sistema quedó con la forma que imaginó alguien que nunca lo hizo.
Nadie explicó qué gana cada uno. Se comunicó el beneficio de la empresa —trazabilidad, control, datos— que a la persona que carga los pedidos no le mejora el día en nada.
El sistema no contempla las excepciones. Y como el proceso real está lleno de excepciones, la herramienta no les sirve para trabajar.
Cómo evitarla: involucrá a quien opera desde el relevamiento, no desde la capacitación. Y cuando releves, insistí con las excepciones: "¿y cuándo no pasa así?". Ahí está el proceso de verdad.
Causa 2: el alcance se infló hasta hacerse imposible
Empieza como "un sistema para gestionar pedidos". En la tercera reunión alguien sugiere que ya que estamos podríamos sumar el stock. Después RRHH pregunta si no se podría incluir vacaciones. Al mes, el proyecto es un ERP.
Nadie decidió eso. Se fue acumulando, y cada agregado parecía razonable solo.
El resultado es un proyecto que tarda un año, donde nadie ve nada funcionando hasta el final, y que cuando sale ya no coincide con la empresa que lo pidió.
Cómo evitarla: fijá el alcance de la primera fase y tratá todo lo nuevo como fase dos. No hay que decir que no; hay que decir "después". Y pedí entregas parciales cada una o dos semanas: es el mejor antídoto, porque obliga a que haya algo terminado todo el tiempo.
Causa 3: los datos estaban peor de lo que todos creían
El proyecto avanza bien hasta la migración. Ahí aparece que el mismo cliente está cargado de cuatro formas distintas, que hay fechas en tres formatos, que nadie sabe qué significa la columna "OBS2" y que el 15% de los registros tiene el teléfono en el campo del mail.
La limpieza no estaba cotizada, se come semanas, y el proyecto entra en su primera crisis.
Cómo evitarla: pedí que la migración de datos históricos esté en el presupuesto desde el principio —en un proyecto sano es del 10 al 15% del total— y que alguien mire una muestra real de los datos antes de cerrar el precio. Media hora mirando la planilla de verdad evita el problema entero.
Causa 4: no hay un dueño interno
El proveedor pregunta cómo debería funcionar una regla y nadie contesta, o contestan tres personas cosas distintas. Cada decisión tarda una semana. El proyecto se estira sin que nadie esté haciendo nada mal.
Cómo evitarla: designá a una persona de tu empresa como dueña del proyecto. No hace falta que sea técnica; hace falta que conozca la operación y tenga autoridad para decidir cómo se va a trabajar de acá en adelante. Sin esa autoridad, el proyecto se frena en cada bifurcación.
Causa 5: se automatizó antes de digitalizar
Se compra una herramienta de automatización o se pide un agente de IA para un proceso que todavía vive en papel y WhatsApp. No hay nada que automatizar porque no hay datos estructurados.
Se gasta, no pasa nada, y queda la sensación de que "eso de la IA no sirve para nosotros".
Cómo evitarla: el orden es digitalizar primero, automatizar después. Cuando el pedido ya entra por un sistema en vez de por un mensaje, ahí sí un agente puede clasificarlo, avisar al depósito y armar la factura. Antes de eso, no.
Causa 6: se apagó lo viejo demasiado pronto
Se lanza el sistema nuevo un lunes y se apaga la planilla el mismo día. El martes aparece el primer problema y ya no hay a dónde volver. La operación se resiente, el equipo pierde confianza, y esa confianza no vuelve fácil.
Cómo evitarla: operación en paralelo durante tres o cuatro semanas. Se carga en los dos lados y se comparan los resultados. Es trabajo doble por un mes y es lo que convierte el cambio en algo reversible mientras todavía importa.
Causa 7: el proyecto se trató como un tema de sistemas
Se delega en "el que sabe de computación" y la dirección se desentiende hasta la entrega. Pero digitalizar es cambiar cómo trabaja la gente, y eso no lo puede conducir alguien sin autoridad sobre cómo trabaja la gente.
Cómo evitarla: que el proyecto tenga un patrocinador con peso real. No para asistir a todas las reuniones: para destrabar cuando hay que destrabar y para bancar el cambio cuando genere fricción.
Cinco señales tempranas
Si estás en medio de un proyecto, chequeá esto:
- Pasaron más de tres semanas sin ver algo funcionando. No maquetas: el sistema real, aunque le falten partes.
- En cada reunión aparecen requisitos nuevos y no sale nada a cambio.
- Quienes van a usar el sistema no participaron de ninguna conversación.
- Nadie miró todavía los datos que hay que migrar.
- No hay una fecha ni un criterio definido para apagar lo viejo.
Cualquiera de las cinco es momento de frenar una reunión y recalibrar. Todas juntas es momento de replantear el proyecto.
Si ya salió mal
La primera pregunta es si el problema es técnico o de adopción, porque las soluciones son opuestas.
Si el sistema está mal construido —se cae, es lento, le faltan cosas centrales— hace falta una auditoría técnica honesta para saber qué se salva y qué se rehace. Desde USD 1.500 y te evita reescribir algo recuperable.
Si el sistema está bien pero nadie lo usa, no lo reescribas. El problema está en el proceso y en la gente, y se resuelve volviendo a relevar cómo trabajan de verdad, ajustando el sistema a las excepciones que faltaron y capacitando en serio. Es bastante más barato que empezar de nuevo, aunque sea menos tentador.
Lo que tienen en común los que salen bien
Mirando los proyectos que terminan y se usan, el patrón se repite:
- Empezaron por un proceso, no por todos.
- Quien opera participó desde el principio.
- Hubo entregas parciales que se podían tocar.
- Los datos se limpiaron y migraron en serio.
- Hubo operación en paralelo antes de apagar lo viejo.
- Alguien de la empresa era dueño del proyecto y podía decidir.
Ninguna de esas seis cosas es técnica. Y esa es, en el fondo, la conclusión.
Si tenés un proyecto en marcha que no te está cerrando, o uno que salió mal y no sabés si rescatarlo, una auditoría técnica suele ordenar bastante el panorama. Y si estás por arrancar uno, contanos el caso antes de que se infle.
Preguntas frecuentes
¿Cuál es la causa más común de que un sistema nuevo no se use?+
La adopción, no la tecnología. El sistema funciona pero el equipo sigue trabajando como antes, casi siempre porque no participó del diseño, porque nadie le explicó qué gana, o porque el sistema no contempla las excepciones del proceso real y entonces no les sirve.
¿Cómo se detecta a tiempo que un proyecto va mal?+
Tres señales tempranas: pasaron más de tres semanas sin que veas algo funcionando, aparecen requisitos nuevos en cada reunión sin que nada salga a cambio, o quienes van a usar el sistema no participaron en ninguna conversación. Cualquiera de las tres es momento de frenar y recalibrar.
¿De quién es la culpa cuando un proyecto de software falla?+
Casi nunca de una sola parte. El proveedor suele fallar en no insistir con el alcance acotado y en no involucrar a los usuarios reales. El cliente suele fallar en no asignar un dueño interno con autoridad y en pedir cambios sin aceptar el costo. Lo útil no es repartir culpas sino reconocer las señales temprano.
¿Se puede recuperar un proyecto que ya salió mal?+
A veces sí. Lo primero es entender si el problema es técnico o de adopción, porque las soluciones son opuestas. Si el sistema está bien construido pero nadie lo usa, no hace falta reescribirlo: hace falta trabajar el proceso y la capacitación, que es bastante más barato.
¿Querés que esto funcione en tu empresa?
En Deepyze convertimos procesos manuales en sistemas que trabajan solos: automatización con IA, apps web y móviles, y software a medida. Contanos tu caso y en 24 hs tenés una propuesta concreta.
Sin compromiso · Respuesta en 24 hs · Equipo en tu mismo huso horario