Configurar antes de personalizar: la regla que evita un Odoo imposible de mantener
Cada excepción que se vuelve desarrollo a medida suma deuda. La configuración estándar, bien pensada, suele alcanzar más de lo que el equipo cree.
Hay un miedo legítimo en mesa de dirección y en TI: terminar con un Odoo Frankenstein. Muchos campos custom, reglas que solo entiende quien las programó, reportes que se rompen en cada actualización y un partner que ya no está. El sistema “cumple” el día del go-live y se vuelve caro de vivir.
La regla que más evita ese escenario es aburrida y efectiva: configurar antes de personalizar.
Por qué cada excepción se vuelve deuda
En un proyecto, alguien dice: “en nuestra empresa esto se hace distinto”. A veces es cierto. A veces es un hábito que nadie ha cuestionado. Si la respuesta automática es desarrollar, cada excepción se convierte en código, en Studio, en un módulo a medida.
Ese código:
- Hay que documentarlo (y casi nunca se documenta del todo).
- Hay que probarlo en cada upgrade Odoo.
- Hay que capacitar a gente nueva en reglas que no están en el estándar.
- Hay que pagar mantenimiento ERP cuando el flujo de negocio cambia otra vez.
La personalización Odoo no es el enemigo. El enemigo es personalizar por defecto, antes de agotar lo que la configuración Odoo ya ofrece.
Qué significa “configuración” en la práctica
Configurar no es “dejar los defaults”. Es diseñar el setup con intención:
- Apps y alcance por etapa (qué prende primero, qué espera).
- Tipos de documento, etapas, equipos y permisos alineados al rol real.
- Productos, listas de precios, rutas de inventario y diarios contables coherentes.
- Automatizaciones nativas (acciones de servidor, automatizaciones de marketing, reglas de aprobación) donde bastan.
- Reportes y vistas ajustadas sin tocar el núcleo.
Odoo Studio entra en esta conversación con cuidado: es útil para ajustes ligeros y prototipos rápidos, pero no es licencia libre para construir un segundo producto encima del ERP. Lo que haces en Studio también hay que mantenerlo.
El camino de upgrade que nadie quiere oír en el kickoff
Los equipos que personalizan temprano suelen descubrir el costo en el primer salto de versión mayor. Campos que chocan, vistas rotas, módulos que ya no cargan, integraciones que asumen un modelo viejo. El upgrade deja de ser un plan y se vuelve un proyecto nuevo.
Si el diseño original privilegió estándar + configuración, el upgrade duele menos. Si privilegió “hazme un a medida porque así lo pedí”, el upgrade es una negociación permanente.
Para un CFO o un responsable de TI, esa diferencia es presupuesto y riesgo operativo, no preferencia estética del consultor.
Flujos reales primero, custom solo donde el estándar no alcanza
La secuencia sana se parece a esto:
- Descubrir el proceso y los datos reales (incluyendo las excepciones que importan).
- Diseñar el setup estándar alrededor de esos flujos y prototipar con el equipo.
- Medir dónde el estándar fricciona de verdad (no donde alguien “preferiría otro botón”).
- Personalizar solo el tramo que no se puede resolver con configuración, reglas o un cambio de proceso razonable.
- Documentar y acotar ese custom para que el próximo upgrade no sea una caja negra.
Eso también aplica cuando sumas IA: captura documental, agentes de flujo o copilotos deben apoyarse en el sistema de registro bien configurado. La IA no arregla un modelo de datos hecho a pedazos.
Señales de que vas hacia un Frankenstein
- Cada reunión de seguimiento termina en “lo desarrollamos”.
- Nadie puede listar, en una página, los módulos o Studio changes activos.
- Los usuarios clave piden pantallas “igualitas” a su Excel en vez de adoptar un flujo estándar mejorado.
- El ambiente de prueba y el de producción ya no se parecen.
- Hablar de upgrade genera silencio incómodo.
Si reconoces tres de esas, frena. Revisa qué se puede volver a configuración antes de sumar más custom.
Cómo conversar la excepción sin pelear
Cuando el negocio insiste en una excepción, pregunta en este orden:
- ¿Es regulatoria o contractual (hay que cumplirla sí o sí)?
- ¿Es frecuencia alta o un caso raro que puede manejarse con un procedimiento?
- ¿Se puede cubrir con etapas, campos estándar, automatización nativa o un reporte?
- ¿El costo de mantener el custom supera el beneficio operativo en 12 a 24 meses?
Ese filtro no es burocracia. Es higiene de plataforma. El partner que solo dice “sí” a todo custom te está vendiendo complejidad, no agilidad.
Qué queda del lado de KAI Consulting
En nuestros proyectos la regla se dice en voz alta desde el discovery: configuración sobre personalización. Diseñamos el setup de Odoo (y la capa de IA donde quita fricción real) alrededor de tus flujos, prototipamos con tu equipo y dejamos el desarrollo a medida para donde el estándar no alcanza.
No es dogma. Es cómo se mantiene un ERP vivo después del PowerPoint del go-live.
Cierre práctico
Abre tu backlog de “desarrollos pendientes” de Odoo (o el de tu implementación actual). Marca cada ítem como: configuración posible, cambio de proceso, o custom inevitable. Suele sobrar personalización pedida por costumbre.
Si estás eligiendo partner y te preocupa el Frankenstein, pide que te expliquen su criterio de configurar vs. personalizar con ejemplos de decisiones reales (sin inventar casos). En KAI Consulting esa conversación es parte del trabajo, no un anexo. Odoo al centro, mantenible, con camino de upgrade claro. Cuando quieras revisar cómo está armado el tuyo, empecemos por tus flujos reales.