Odoo · ERP · Perú
Errores al implementar Odoo en Perú y cómo prevenirlos
Los proyectos de ERP rara vez fracasan por el software. Fracasan por decisiones tomadas en las primeras semanas, cuando todavía parecía que el problema era técnico.
Última actualización: septiembre de 2026
Avance por fase
Diagnóstico100%
Diseño funcional100%
Configuración78%
Migración45%
Pruebas20%
Capacitación0%
Entregables
1. Fijar la fecha antes del alcance
Cuando el go-live se define primero, lo que se recorta al final son las pruebas y la capacitación, justo lo que sostiene la operación. El plazo debe salir del alcance, no al revés.
2. Configurar sin diseño funcional
Sin un documento aprobado, cada usuario pide lo suyo y el sistema termina reflejando preferencias en lugar de procesos. El diseño escrito también es la referencia contra la cual se miden los cambios posteriores.
Síntoma: cada reunión reabre decisiones ya tomadas. Corrección: congelar un documento de diseño firmado y tratar todo cambio posterior como solicitud formal con impacto en plazo.
3. Dejar la contabilidad al final
Si los documentos se definen sin ver el asiento que generan, el problema aparece en el primer cierre, cuando corregirlo implica reprocesar meses. El asiento se decide antes del circuito que lo emite.
Síntoma: nadie sabe qué cuenta mueve una venta con anticipo. Corrección: definir el asiento de cada tipo de documento antes de configurar el circuito que lo emite, y probarlo con casos reales.
4. Migrar datos sucios
Maestros duplicados, códigos inconsistentes e inventario sin valorizar convierten cada cuadre en una investigación. La limpieza va antes de la carga y la valida quien conoce los datos.
Síntoma: el mismo proveedor aparece tres veces con RUC distinto. Corrección: limpiar en el origen antes de cargar, con un responsable de la empresa que apruebe cada maestro y cada saldo.
5. Subestimar la localización
Series, tipos de documento, detracciones, retenciones, percepciones y registros electrónicos requieren decisiones. Asumir que "ya viene localizado" es el error que más reprocesos genera en Perú.
Síntoma: el primer envío a SUNAT se rechaza por serie o tipo de operación. Corrección: inventariar tipos de comprobante, series por establecimiento y regímenes aplicables en la primera semana del proyecto.
6. No asignar un responsable interno
Un proyecto sin dueño del lado de la empresa se detiene en cada decisión de negocio. Ese rol necesita autoridad para decidir y tiempo asignado, no buena voluntad los viernes.
Síntoma: las decisiones esperan al gerente general. Corrección: nombrar un líder con autoridad y tiempo reservado, y una contraparte por área con capacidad de aprobar su circuito.
7. Capacitar una sola vez
Una sesión antes del go-live no sostiene la operación. El refuerzo va después, con datos reales, y por rol: lo que necesita almacén no es lo que necesita contabilidad.
Síntoma: a las dos semanas del go-live el equipo vuelve al Excel. Corrección: capacitación por rol con datos propios, material que quede en la empresa y un refuerzo a las tres semanas de operación real.
8. Desarrollar por defecto
Cada personalización es mantenimiento permanente y un riesgo en cada actualización. Primero se agota la configuración; el desarrollo se justifica cuando el requisito es real y el proceso no puede cambiar.
Síntoma: la lista de desarrollos crece antes de que exista un ambiente de pruebas. Corrección: exigir que cada desarrollo declare el problema que resuelve, quién lo usará y por qué la configuración no alcanza.
9. Automatizar de entrada
Automatizar un proceso que aún no funciona acelera el error y esconde su origen. Primero se ordena, después se automatiza.
Síntoma: un flujo automático genera cien documentos equivocados en una noche. Corrección: operar el proceso manualmente un ciclo completo, medirlo y recién entonces automatizar.
10. Terminar en el go-live
La operación real destapa lo que ninguna prueba anticipó, y el primer cierre contable es la verdadera prueba de la configuración. Un proyecto que no contempla ese acompañamiento no está terminado.
Síntoma: el proveedor desaparece la semana del primer cierre. Corrección: contratar explícitamente el acompañamiento del primer cierre contable y dejarlo como hito de cierre del proyecto.
si a la tercera semana nadie ha hablado de impuestos, series de documentos ni cuadre de saldos, el proyecto ya está tomando el camino largo.
Los tres momentos donde se decide el proyecto
Los diez errores no se reparten de forma pareja en el tiempo. Se concentran en tres momentos, y saber cuáles son permite poner atención donde sirve.
Semanas uno a tres: el alcance
Aquí se decide casi todo lo que después cuesta caro cambiar: qué módulos entran, cómo está estructurada la contabilidad, qué compañías y establecimientos existen y quién decide del lado de la empresa. Un diagnóstico que no produce un documento firmado en este tramo deja el proyecto sin referencia.
Las pruebas: el momento que siempre se recorta
Cuando el plazo aprieta, lo primero que se sacrifica son las pruebas, y es exactamente lo contrario de lo que conviene. Las pruebas deben recorrer casos reales de la empresa, no funcionalidades sueltas: una venta con anticipo, una compra con detracción, una devolución parcial, una nota de crédito y un cierre de mes completo.
El primer cierre contable: la verdadera prueba
Ninguna demostración sustituye al primer cierre con datos reales. Ahí se ve si los documentos generan los asientos correctos, si el inventario está valorizado, si los impuestos cuadran y si los reportes sirven. Un proyecto que declara el éxito en el go-live está declarándolo una semana antes de poder saberlo.
Checklist de control por fase
Si diriges el proyecto del lado de la empresa, estas son las preguntas que conviene poder responder con un sí en cada fase:
- Diagnóstico: ¿existe un documento con el circuito actual y los problemas concretos que el ERP debe resolver?
- Diseño funcional: ¿está escrito, aprobado y con el detalle contable de cada tipo de documento?
- Configuración: ¿puedo ver el sistema haciendo un caso propio de punta a punta?
- Migración: ¿cuadran los saldos contra la contabilidad anterior y quién firma ese cuadre?
- Pruebas: ¿ejecutaron los usuarios sus propios casos, o solo vieron una demostración?
- Capacitación: ¿quedó material en la empresa y hay alguien capaz de enseñar a un ingresante?
- Go-live: ¿hay plan de contingencia y alguien disponible la primera semana?
- Primer cierre: ¿está contratado el acompañamiento y con qué alcance?
Cómo recuperar un proyecto detenido
Recibimos proyectos que llevan meses sin avanzar. La reacción natural —empezar de cero— suele ser la más cara y casi nunca es necesaria. El orden que funciona es este:
- Inventario del estado real. Qué está configurado, qué datos se cargaron, qué desarrollos existen y quién los mantiene.
- Revisión contable primero. Plan de cuentas, impuestos y asientos de los documentos en uso. Si esa base está mal, todo lo demás se rehace igual.
- Decisión explícita de qué se conserva. Por escrito, con criterio, no por apego al trabajo ya pagado.
- Alcance reducido a lo indispensable. Salir en vivo con el circuito esencial y postergar el resto suele recuperar el impulso del equipo.
- Un responsable interno con autoridad. Sin eso, el proyecto se vuelve a detener en la primera decisión de negocio.
Preguntas frecuentes
¿Cuál es el error más caro?
Descubrir en el primer cierre que los documentos generan asientos incorrectos. Corregirlo implica revisar la configuración y reprocesar los periodos ya registrados.
¿Se puede recuperar un proyecto detenido?
Sí. Se empieza revisando la configuración contable y funcional existente, se define qué se conserva y qué se rehace, y se reordena el proyecto desde ahí.
¿Cuánta dedicación necesita el equipo interno?
Depende del alcance, pero los usuarios clave deben tener tiempo reservado para validar datos, probar casos y aprobar cuadres. Sin eso, el proyecto se alarga por espera, no por trabajo.
¿Cuánto tiempo debería durar una implementación?
Depende del alcance, pero el plazo debe salir del trabajo identificado en el diagnóstico. Desconfía de un plazo ofrecido antes de que alguien haya visto tus datos y tus tipos de comprobante.
¿Qué hago si el proveedor propone desarrollar algo que creo que ya existe?
Pide que lo demuestren en el estándar antes de aprobar el desarrollo. La pregunta útil es: ¿qué configuración se intentó y por qué no alcanzó? Si no hay respuesta concreta, conviene pedir una segunda opinión.