Una implementación puede fallar por alcance, gestión, datos, adopción o problemas técnicos y de adecuación del software. Esta guía revisa ocho riesgos organizativos y operativos frecuentes; no exime al proveedor de comprobar capacidades, integraciones, migración y rendimiento.
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 varias áreas a la vez exige coordinación, pruebas y capacidad de acompañamiento; si eso no está preparado, aumenta el riesgo operativo.
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: definir qué datos activos e históricos necesita la operación y qué debe conservarse accesible; limpiar y verificar lo que se migra. 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 prueba planificada en entorno controlado, con casos representativos y excepciones. Si se acuerda convivencia operativa, definí reglas para evitar movimientos o comprobantes duplicados. 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?
Pueden combinarse alcance mal definido, falta de responsables, datos, capacitación y defectos técnicos o de adecuación. Investigá la causa del proyecto concreto antes de responsabilizar solo a la empresa o al software.
¿Cuánto tiempo debe reservar el equipo para implementar un ERP?
Depende de las decisiones, datos y pruebas que deba realizar cada área. Armá un calendario con horas asignadas y responsables para relevamiento, validación, capacitación y puesta en marcha. Si esas tareas no tienen disponibilidad real, el cronograma técnico tampoco representa una fecha de entrega viable.
¿Conviene migrar todo el histórico?
Definí qué datos y relaciones necesita la operación, el análisis y la conservación aplicable. Limpiá antes de migrar y acordá cómo consultar el archivo; que un dato no esté activo no significa que pueda descartarse o quedar inaccesible.
¿Cuándo conviene dejar de operar en el sistema anterior al migrar un ERP?
Acordá un corte cuando datos, saldos, circuitos y contingencias estén validados. Puede requerirse una convivencia controlada según el riesgo, con reglas que eviten cargar dos veces. Conservá acceso al histórico necesario y verificá la recuperación antes de desactivar servicios o permisos.
¿Qué revisar después de una implementación fallida de ERP?
Reconstruí alcance, decisiones, pruebas, problemas técnicos y datos pendientes con evidencia del proyecto. Identificá qué funcionó y qué debe corregirse antes de reiniciar. No atribuyas el fracaso automáticamente a un responsable: el nuevo plan debe resolver causas verificadas y definir criterios de aceptación.
¿Qué prueba demuestra que un ERP está listo para la puesta en marcha?
Un conjunto de circuitos completos y excepciones acordadas, con datos, saldos y responsables verificados. Incluí migración de ensayo, permisos y contingencia. Una demostración del proveedor no sustituye que el equipo pueda operar; registrá incidencias y su resolución antes de aceptar el corte.
Preguntas y respuestas revisadas el 19 de octubre de 2026 por Equipo Olpa Group.
Para cerrar
Antes de elegir sistema y proveedor, definí responsables y tiempo interno, y verificá adecuación funcional y técnica. El proyecto necesita ambas cosas: una empresa preparada y una solución bien implementada.
Agendá un diagnóstico gratuito de 30 minutos y evaluamos si tu empresa está en condiciones de encarar una implementación.
Más sobre sistemas de gestión