Las implementaciones de ERP fracasan casi siempre por razones organizativas, no técnicas: nadie de la empresa toma la responsabilidad del proyecto, se intenta poner todo en marcha el mismo día, se migran datos sucios y se pide que el sistema nuevo funcione exactamente como el viejo. El software rara vez es el problema. Estos son los ocho errores que más se repiten y qué hacer con cada uno.
1. No asignar un responsable interno
El error número uno. Se contrata al implementador y se asume que va a resolver todo. Pero el implementador no puede decidir cómo va a trabajar tu empresa.
Qué pasa: cada pregunta frena el proyecto días. El cronograma se estira sin que nadie sepa bien por qué.
Qué hacer: designar una persona con tiempo asignado (varias horas semanales, no “cuando pueda”) y capacidad de decidir. Idealmente alguien que conozca la operación y tenga peso interno.
2. Querer implementar todo el mismo día
Poner en marcha ventas, compras, stock, producción y contabilidad simultáneamente garantiza caos.
Qué pasa: el equipo tiene que aprender cinco cosas nuevas a la vez mientras sigue trabajando. Cuando algo falla, nadie sabe si es el sistema, el proceso o el usuario.
Qué hacer: implementar por fases. Primero el circuito principal, después el resto. Se ve valor antes y los ajustes de la fase 1 mejoran las siguientes.
3. Migrar datos sucios
Se traen diez años de historia con duplicados, códigos inconsistentes y stock que no coincide con el depósito.
Qué pasa: el sistema nuevo nace desordenado. El equipo desconfía desde el día uno y vuelve a sus planillas.
Qué hacer: migrar solo lo activo y limpio. El histórico se archiva aparte. Es el momento ideal para ordenar: aprovechalo en vez de arrastrar el desorden.
4. Pedir que funcione igual que el sistema viejo
Se pide replicar exactamente los circuitos anteriores, incluidas sus limitaciones.
Qué pasa: se pagan desarrollos a medida para reproducir algo que era un defecto, no una necesidad. Y se pierden las ventajas del sistema nuevo.
Qué hacer: distinguir entre “así lo necesitamos” y “así lo veníamos haciendo porque el otro sistema no permitía otra cosa”. Son cosas distintas y no siempre es evidente.
5. No hacer pruebas antes de salir en vivo
Se salta la etapa de pruebas para ganar una semana.
Qué pasa: los problemas aparecen con la operación real corriendo, cuando el costo de cada error es máximo.
Qué hacer: una o dos semanas donde el equipo carga operaciones reales en paralelo. Ahí aparecen los casos que nadie previó: la nota de crédito rara, el cliente con condición especial, el producto que se vende por peso.
6. Capacitar a todos en todo
Se hace una capacitación general de ocho horas donde todos ven el sistema completo.
Qué pasa: nadie retiene nada. La capacitación general es la menos efectiva.
Qué hacer: formación por rol. El de depósito aprende recepción y despacho. El de ventas, presupuesto y facturación. Y una segunda sesión a las dos semanas, cuando aparecieron las dudas reales.
7. Mantener el sistema viejo demasiado tiempo
Se deja el anterior “por las dudas” durante meses.
Qué pasa: se duplica el trabajo, los datos divergen y nadie adopta el nuevo. Ante cualquier dificultad, el equipo vuelve a lo conocido.
Qué hacer: fecha de corte clara, comunicada con anticipación. El sistema viejo queda solo como consulta de histórico, sin cargar operaciones.
8. No medir la adopción
Se implementa, se capacita y se asume que está funcionando.
Qué pasa: meses después se descubre que la mitad del equipo lleva un Excel paralelo.
Qué hacer: medir las primeras 8 semanas. ¿Se cargan todas las operaciones? ¿Los saldos cuadran? ¿Aparecen planillas paralelas? La aparición de un Excel paralelo es la señal más clara de que algo del sistema no está resolviendo una necesidad real.
Diagnóstico: ¿tu proyecto está en riesgo?
| Señal | Riesgo |
|---|---|
| No hay un responsable interno con nombre | 🔴 Alto |
| El alcance creció desde que empezó | 🔴 Alto |
| Se va a salir en vivo sin pruebas | 🔴 Alto |
| El equipo no participó del relevamiento | 🟡 Medio |
| Se migra todo el histórico | 🟡 Medio |
| No hay fecha de corte del sistema viejo | 🟡 Medio |
Tres o más señales en rojo: conviene frenar y replantear antes de seguir.
Lo que sí funciona
- Alcance chico en la primera fase, y crecer después
- Un responsable interno con tiempo real asignado
- Datos limpios, aunque sean menos
- Pruebas con casos reales antes de salir en vivo
- Capacitación por rol, en dos instancias
- Fecha de corte clara
- Medición de adopción las primeras semanas
Dónde entra la IA
- Limpieza de datos para la migración: deduplicar y normalizar a escala.
- Carga automática de documentos, que reduce la resistencia del equipo porque elimina tipeo.
- Detección de uso irregular: identificar qué circuitos no se están usando, que es la señal temprana de abandono.
Cómo lo encaramos en Olpa
Somos Partner oficial de Odoo y el primer punto que negociamos en cada proyecto no es técnico: es que haya un responsable interno con horas asignadas. Sin eso, preferimos no arrancar, porque sabemos cómo termina.
Trabajamos por fases, con pruebas obligatorias y capacitación por rol. Y medimos adopción las primeras ocho semanas, porque un ERP que no se usa es peor que no tener ERP: cuesta igual y además genera desconfianza.
Preguntas frecuentes
¿Por qué fracasan las implementaciones de ERP? Por razones organizativas más que técnicas: falta de un responsable interno, alcance demasiado grande, datos sucios y ausencia de pruebas. El software rara vez es la causa.
¿Cuánto tiempo tiene que dedicarle mi equipo? El responsable interno, varias horas semanales durante todo el proyecto. El resto, unas horas para capacitación y pruebas.
¿Conviene migrar todo el histórico? No. Migrá lo activo y archivá el resto. Arrancar con datos sucios hace que el equipo desconfíe del sistema desde el primer día.
¿Cuánto tiempo mantengo el sistema viejo? Solo durante las pruebas. Después, fecha de corte clara y queda únicamente como consulta. Mantener ambos en paralelo frena la adopción.
Ya tuvimos una implementación fallida, ¿qué hacemos distinto? Revisar cuál de estos ocho errores ocurrió. En la mayoría de los casos es el primero: nadie de la empresa tomó la responsabilidad del proyecto.
Para cerrar
Un ERP no fracasa por el software: fracasa porque nadie adentro lo hace propio. Antes de elegir sistema o proveedor, conviene resolver quién va a ser el dueño del proyecto y cuánto tiempo va a poder dedicarle.
Agendá un diagnóstico gratuito de 30 minutos y evaluamos si tu empresa está en condiciones de encarar una implementación.