En casi todos los proyectos llega el mismo momento. Alguien del equipo mira la pantalla durante la demo o la capacitación y suelta la frase: "es que nosotros no trabajamos así". Y detrás de esa frase viene el pedido: que el sistema se modifique para funcionar exactamente como la empresa opera hoy. Personalizar Odoo es posible —y a veces es justo lo que el negocio necesita—, pero pedir personalizaciones para no cambiar nada es, con diferencia, el error más caro que puede cometer una empresa al implementar un ERP. En este artículo te contamos cuándo una personalización vale la pena, cuándo no, y por qué en Oz insistimos en que cada personalización pase primero por un debate.
Configurar no es lo mismo que personalizar Odoo
Antes de discutir si conviene, aclaremos de qué hablamos, porque en el mercado se mezclan los términos.
Configurar es ajustar lo que Odoo ya trae: activar módulos, definir flujos de aprobación, crear listas de precios, diseñar formatos de impresión, ajustar permisos por usuario. No se escribe código nuevo; se aprovecha la flexibilidad del estándar. La gran mayoría de necesidades de una empresa peruana se resuelve aquí.
Personalizar es otra cosa: es desarrollo a medida. Un programador escribe código que no existe en el producto —un módulo nuevo, un campo con lógica propia, un proceso que Odoo no contempla— y esa pieza pasa a ser tuya: tú la pagas, tú la mantienes y tú la migras en cada actualización.
La diferencia importa porque el costo de cada camino es radicalmente distinto. Una configuración también cuesta —hay horas de implementación detrás—, pero es un costo menor y, sobre todo, más estable: estás usando piezas que miles de empresas ya probaron, con un objetivo claro y un retorno conocido. Y cuando Odoo cambia de versión, el propio proceso de actualización de Odoo se encarga del estándar; habrán ajustes pero serán menores. Una personalización, en cambio, se cotiza, se desarrolla, se prueba, se documenta… y es tuya para siempre: se vuelve a tocar, por tu cuenta, cada vez que el sistema evoluciona. Es más, se vuelve a debatir si vale la pena migrarla.
El error más caro: personalizar para no cambiar nada
Hay una verdad incómoda que preferimos decir de frente: si tu plan es implementar un ERP y que nada en tu empresa cambie, ¿para qué quieres un ERP?
Un ERP como Odoo trae dentro las buenas prácticas de miles de empresas que ya recorrieron el camino. Cuando una empresa exige replicar "como trabajamos hoy" a punta de desarrollos, en realidad está pagando por blindar sus vicios operativos. Y lo paga tres veces:
- En la implementación, porque cada desarrollo suma horas de levantamiento, programación y pruebas al proyecto.
- En el mantenimiento, porque el código a medida es tuyo: cada error, cada ajuste y cada mejora corre por tu cuenta. Y hay un costo que casi nadie presupuesta: el conocimiento. Un sistema a medida exige que alguien —en tu empresa y en tu partner— sepa cómo y por qué funciona. Cada persona que rota se lleva una parte de ese conocimiento, y cuando se pierde, la funcionalidad se abandona y la inversión nunca llega a tener un retorno claro.
- En cada actualización futura, porque las personalizaciones no migran solas: hay que revisarlas y reprogramarlas versión tras versión. Mientras más personalizaste, más caro y lento es cada salto.
Por eso nuestra regla es simple: acomódate al ERP, configura todo lo posible y personaliza solo lo crítico. Ya lo adelantamos cuando explicamos qué esperar al implementar Odoo: las personalizaciones son un paso opcional del proyecto, no el proyecto.
¿Y qué es "lo crítico"? Aquello sin lo cual tu negocio no puede operar, facturar o diferenciarse, y que el estándar de Odoo —configurado con criterio— realmente no cubre. Esa definición es exigente a propósito: una personalización crítica merece presupuesto y tiempo asignados; una personalización "porque así estamos acostumbrados" no merece ninguna de las dos cosas.
Personalizar tiene que ser un debate, no un pedido
Aquí va nuestra postura más firme: una personalización nunca debería ser una transacción donde el cliente pide, paga y se ejecuta. Un partner serio no vende desarrollos por catálogo; abre un debate en tres frentes antes de escribir una sola línea de código.
El debate técnico. ¿Esto ya existe en el estándar y solo hay que configurarlo? ¿Hay un camino nativo que resuelve el 90% del caso? ¿El desarrollo compromete futuras actualizaciones o toca partes sensibles del sistema, como la facturación electrónica?
El debate operativo. ¿Tu equipo tiene la capacidad real de sostener el proceso que la personalización habilita? ¿La información que el módulo necesita existe, está a la mano y alguien la va a alimentar todos los días? Un desarrollo perfecto sobre un proceso que nadie puede sostener es dinero enterrado; más abajo te contamos un caso real.
El debate presupuestal. ¿El beneficio justifica el costo total —desarrollo, mantenimiento y migración futura— o solo el costo visible de hoy? ¿Hay presupuesto y tiempo asignados, o la personalización va a canibalizar el cronograma del proyecto?
Y una advertencia: si tu partner no está en capacidad de darte este debate, el problema no es solo que quiera cobrarte y ya. Es que te está metiendo en un problema futuro del cual no podrá sacarte. Un ERP se implementa pensando en un horizonte de 7 a 10 años —nadie implementa un ERP para que viva 2 o 3—, y las decisiones de personalización que tomes hoy las vas a cargar (o disfrutar) durante todo ese camino.
El debate también es interno. Lo hemos visto de cerca: empresas donde, con las herramientas técnicas que Odoo deja a la mano, alguien del equipo va modificando formularios e insertando automatizaciones por su cuenta, cambio tras cambio, muchas veces solo por complacer un pedido de gerencia sin cuestionarlo. Cada uno de esos cambios parece inofensivo; la suma convierte el sistema en uno más difícil de entender y de soportar. Personalizar por querer también es personalizar de más — el filtro del debate aplica igual cuando el pedido viene de adentro.
Cuando un proyecto llega con muchas personalizaciones en la lista, este debate merece un espacio formal propio: para eso existe el Odoo Discovery, un diagnóstico previo donde se evalúa cada requerimiento antes de comprometer alcance y presupuesto. Si son una o dos, el debate se da dentro del mismo proyecto, con una prevalidación por cada requerimiento.
Si de este debate la personalización sale viva, adelante: es crítica y vale la pena. Si no sobrevive al debate, acabas de ahorrarte miles de dólares.
Una personalización que sí valió la pena: el taller automotriz
Un caso real, del rubro automotriz. Nuestros clientes de ese sector necesitaban gestionar su taller: "check-in" (registro de ingreso) de los vehículos, registro de tiempos de trabajo, cotizaciones que combinan repuestos y mano de obra, facturación al cliente y facturación de siniestros a las aseguradoras. Nada de eso existe como tal en el estándar de Odoo, y era el corazón de su operación de posventa: sin taller no hay negocio.
Ahí sí se justificaba desarrollar, y se hizo con método: levantamiento de información para entender cómo funciona un taller automotriz, mapeo de cada paso del proceso y prototipos que el cliente validó antes de construir la versión final. El resultado fue un módulo de Taller a la medida del rubro y un ERP verdaderamente integral: el cliente vende los vehículos, atiende la posventa en el taller y vende repuestos, todo dentro de Odoo.
Nota lo que hizo la diferencia: la personalización pasó el debate en los tres frentes. Era técnicamente necesaria (el estándar no lo cubría), operativamente sostenible (el proceso del taller ya existía y tenía dueños claros) y presupuestalmente justificada (habilitaba la línea de negocio completa).
Y una que no: el módulo de garantías que quedó tirado
El contraste. Un cliente que vendía maquinarias nos pidió una personalización para llevar el control de las garantías de sus equipos. Se trabajó igual de bien que el caso anterior: se levantó el proceso, se diseñó el módulo, se desarrolló y se entregó funcionando. Técnicamente, impecable.
¿Qué pasó? El cliente no tenía la capacidad de llevar ese control en el día a día. La información que el módulo necesitaba no estaba a la mano, nadie la alimentaba con disciplina, y el personal dejó la funcionalidad tirada en cuestión de semanas. El desarrollo no falló; falló el debate operativo que debió darse antes de aprobarlo. Esa pregunta —"¿quién va a alimentar esto todos los días y de dónde va a sacar la información?"— valía más que todo el código que se escribió.
Ese caso nos marcó. Hoy preferimos incomodar al cliente con ese debate antes de cotizar, aunque signifique vender menos desarrollo. Nos ha tocado decir "esto no te lo recomendamos personalizar" más veces de las que hemos dicho que sí, y es una de las razones por las que nuestros proyectos llegan a producción sin sorpresas.
¿Y Odoo Studio? Personalizar sin escribir código también es personalizar
Aquí conviene detenerse en una herramienta que genera confusión: Odoo Studio. Viene dentro del paquete de Odoo (en el plan Custom) y permite modificar pantallas, crear campos y automatizaciones arrastrando y soltando, sin programar. Por eso muchas empresas lo tratan como si fuera configuración.
No lo es. Studio escribe el código por ti: cada cambio que haces se guarda en un módulo de personalizaciones que modifica el comportamiento de Odoo, exactamente igual que un desarrollo a medida — solo que sin que nadie lo haya debatido, documentado ni diseñado para durar. Y ese módulo sufre en las migraciones. Lo hemos visto en carne propia: al migrar a un cliente de la versión 14 a la 18, sus personalizaciones de formato hechas en Studio se perdieron y hubo que rehacerlas. No es un caso aislado; los foros oficiales de Odoo acumulan reportes similares en cada salto de versión.
Que quede claro el punto: Studio no es una mala herramienta, pero no es la bala de plata de la personalización, y sobre todo no te exime del debate. Si un requerimiento pasa el debate y es crítico, suele merecer código formal, documentado y pensado para migrar. Si no pasa el debate, tampoco lo hagas en Studio: la personalización que no convenía no se vuelve buena porque fue barata de hacer.
Cómo lo hacemos en Oz
Nuestra metodología pone las personalizaciones donde deben estar: como un paso opcional, después de configurar el estándar al máximo. Cada requerimiento a medida pasa por una prevalidación —el debate técnico, operativo y presupuestal en un documento concreto— y solo se desarrolla lo que sale aprobado, con presupuesto y cronograma propios. Así funciona nuestro servicio de personalización de Odoo: desarrollos que resuelven lo crítico, documentados y pensados para sobrevivir a las actualizaciones del producto.
El resultado de esta disciplina es un sistema más simple, más barato de mantener y mucho más fácil de actualizar cada año. Tu ERP crece contigo, en lugar de convertirse en un museo de desarrollos que nadie se atreve a tocar.
Preguntas frecuentes
¿Cuál es la diferencia entre configurar y personalizar Odoo?
Configurar es ajustar las opciones que Odoo ya trae (flujos, permisos, formatos, listas de precios) sin escribir código; personalizar es desarrollar a medida algo que el producto no contempla. Configurar tiene un costo menor y estable, y en cada actualización requiere a lo mucho ajustes menores; personalizar se paga en el desarrollo, en el mantenimiento y en cada salto de versión.
¿Cuánto cuesta una personalización de Odoo?
Depende del alcance, y por eso se cotiza recién después de la prevalidación: primero se define si conviene, luego cuánto cuesta. Ten presente que las personalizaciones no están incluidas en el precio base de una implementación; en nuestra guía de cuánto cuesta implementar Odoo en Perú explicamos qué cubre cada concepto.
¿Necesito un plan especial de licencia para personalizar Odoo?
Sí. El plan Standard de Odoo solo permite trabajar en Odoo Online, sin módulos a medida. Para personalizaciones necesitas el plan Custom, que habilita desarrollos propios y el alojamiento en Odoo.sh — el mismo plan que se requiere para la localización peruana. Confirma las condiciones vigentes en odoo.com y pídele a tu partner que te las explique con transparencia.
¿Qué pasa con mis personalizaciones cuando Odoo saca una versión nueva?
No migran solas: cada desarrollo a medida debe revisarse y adaptarse a la nueva versión. Por eso mientras menos personalizaciones tengas, más simple y económico es cada salto de versión. Es una de las razones de fondo para personalizar solo lo crítico (y el tema del próximo artículo de esta serie).
¿Y si mi proveedor me dice que sí a todas las personalizaciones?
Es una señal de alerta seria. Un partner que acepta todo requerimiento sin debatirlo no solo está priorizando facturar horas de desarrollo: te está construyendo un problema del que después no podrá sacarte, y con el que vas a convivir años — porque un ERP bien elegido no se cambia cada 2 o 3 años; con Odoo y su evolución anual, la relación es de largo plazo. Si tu proveedor no te habla claro hoy, imagina la conversación en la migración de dentro de cuatro años. En nuestra guía de cómo elegir un partner de Odoo en Perú te damos las preguntas exactas para detectarlo a tiempo.
En resumen
Personalizar Odoo no es bueno ni malo en sí mismo: es una herramienta poderosa que se vuelve carísima cuando se usa para no cambiar nada. La regla que defendemos en Oz es acomodarse al estándar, configurar todo lo posible y personalizar únicamente lo crítico — y someter cada requerimiento a un debate técnico, operativo y presupuestal antes de aprobar un solo desarrollo, venga de donde venga el pedido y se haga con código o con Odoo Studio. Un módulo de taller que habilita toda una línea de negocio vale cada dólar; un módulo de garantías que nadie alimenta no vale ninguno.
¿Estás evaluando Odoo y tienes una lista de "cosas que el sistema debería hacer como nosotros trabajamos"? Conversemos: te ayudamos a separar lo crítico de lo costoso antes de que firmes por ello. Escríbenos aquí y lo debatimos juntos — es literalmente lo que mejor sabemos hacer.