Hay una decisión que toman las empresas que más rápido capturan valor de Odoo, y ocurre antes de escribir una sola línea de código: se dan el tiempo de conocer la herramienta antes de pedirle que cambie.
En las implementaciones que mejor salen, hay un momento identificable: el equipo usa Odoo nativo el tiempo suficiente para distinguir entre dos preguntas muy distintas. ¿Esto es diferente a como lo hacíamos? y ¿esto realmente no funciona para nuestro negocio? La primera casi siempre tiene respuesta dentro del sistema. La segunda es la que justifica un desarrollo.
Qué significa ”familiarizarse”, en la práctica
No es esperar pasivamente ni resignarse a usar lo que venga. Es un ejercicio con método:
• Operar un ciclo completo del proceso en Odoo nativo, no una prueba de dos días, sino el tiempo real que toma para esa área (un ciclo de ventas completo, un mes de cierre contable, una temporada de producción).
• Documentar cada punto de fricción con una pregunta simple: ¿esto me impide operar, o solo me obliga a operar distinto?
• Involucrar a quien realmente usa el proceso todos los días, no solo a quien lo aprueba. La resistencia al cambio y la limitación real se sienten parecido desde arriba, pero son evidentes desde la operación.
Ese ciclo suele tomar entre cuatro y ocho semanas, dependiendo del proceso. Es tiempo corto comparado con el costo de construir, mantener y luego descartar un desarrollo que no era necesario.
Los falsos positivos más comunes
En diagnósticos con distintos clientes hemos visto el mismo patrón repetirse en tres frentes:
• Reportes. Se pide replicar exactamente el Excel o el reporte que usaban antes, cuando Odoo ya permite construir esa misma vista con filtros, agrupaciones y tableros nativos con la ventaja de que se actualiza en tiempo real.
• Flujos de aprobación. Se solicitan cadenas de aprobación que copian una jerarquía interna heredada, sin cuestionar si esa jerarquía sigue siendo necesaria o si fue diseñada para un problema de control que ya no existe.
• Vistas por área. Cada departamento pide su propia pantalla personalizada, cuando el mismo dato, bien configurado con permisos y filtros, resuelve la necesidad de todos sin duplicar mantenimiento.
Ninguno de estos tres es un error técnico. Son decisiones tomadas antes de tener suficiente información y en realidad ahí está el costo.
Lo que realmente cuesta adelantarse
El desarrollo en sí es apenas el primer gasto. Los que casi nunca se cuentan en la cotización inicial son:
• Mantenimiento indefinido. Cada actualización de Odoo, cada upgrade de versión, ahora tiene que validar si rompe esa personalización. Es un costo que se paga cada año, no una sola vez.
• Tiempo de arranque. Mientras el equipo construye algo que no era esencial, el ERP que ya se pagó no está generando valor. El retorno de la inversión se retrasa por una decisión que pudo evitarse.
• Deuda de complejidad. Un sistema con desarrollos innecesarios es un sistema más difícil de entender, de soportar y de escalar, para el equipo interno de TI, y para cualquier consultor que llegue después.
Pero hay brechas que sí son reales desde el primer día
Nada de esto significa que todo desarrollo deba posponerse. Hay procesos donde, desde el primer diagnóstico, es evidente que Odoo nativo no cubre una necesidad crítica del negocio: integraciones con sistemas de planta o control de piso, estructuras de comisión con reglas propias del sector, requisitos normativos locales que ninguna configuración estándar resuelve. En esos casos, esperar no es prudencia sino que es un retraso sin ningún beneficio.
Lo que cambia con anticipación
La diferencia entre ambos escenarios rara vez es evidente para quien no hace este diagnóstico todos los días. Distinguir una brecha real de una costumbre operativa disfrazada de necesidad es el resultado de contrastar, proceso por proceso, lo que el negocio necesita contra lo que Odoo ya resuelve de forma nativa, antes de que el proyecto empiece a construirse.
Esa es la diferencia entre anticipar una brecha y descubrirla. Cuando el contraste se hace en la fase de discovery (antes de escribir una sola línea de código) cada brecha real se identifica con su impacto, su costo y su esfuerzo ya dimensionados, y se aprueba con esa información completa. Cuando ese contraste no se hace a tiempo, la brecha aparece igual, pero ahora en medio del proyecto: con el cronograma ya comprometido, el presupuesto ya definido, y la decisión tomada bajo presión en lugar de con criterio.
No es que el desarrollo se vuelva innecesario. Es que se aprueba en el momento correcto, con la información correcta, en lugar de aparecer como un imprevisto a mitad de camino.
La pregunta que debería estar en cada aprobación
Antes de firmar un desarrollo a medida, vale la pena que quien aprueba el proyecto se haga una pregunta distinta a la habitual. No ¿Odoo lo hace de fábrica?, sino: ¿este proceso, tal como lo estamos pidiendo, existe porque el negocio lo necesita así, o porque siempre lo hicimos así?