Implementar Odoo no consiste en instalar módulos y rellenar algunos parámetros. Es un proyecto que afecta a la forma en que la empresa factura, cobra, declara el IVA y, a menudo, paga sus salarios. En Suiza, estos tres temas — contabilidad, IVA, nómina — están regulados por normas precisas, y una configuración que las ignora en el cadraje se paga en el primer cierre, no antes. Es la diferencia entre un integrador que instala un software y una fiduciaria que piensa la implementación a partir de lo que la contabilidad debe producir al final.
Esta página describe el método que seguimos, fase por fase, desde la auditoría previa hasta el soporte posterior a la puesta en producción. También trata, sin rodeos, lo que hace fracasar o descarrilar un proyecto ERP: son causas conocidas, recurrentes y evitables si se anticipan.
Cuándo una empresa está preparada para Odoo — y cuándo todavía no
Odoo tiene sentido en cuanto una empresa gestiona varios procesos que hoy no se comunican entre sí: facturación en una herramienta, existencias en una hoja de cálculo, salarios con un tercero, sin visión de conjunto. La señal más clara es la doble captura manual — la misma información tecleada dos o tres veces en herramientas distintas — y la falta de visibilidad en tiempo real sobre la tesorería o los márgenes.
A la inversa, algunas señales indican que conviene esperar o resolver antes un problema previo:
- Los procesos actuales no están estabilizados. Si la empresa sigue cambiando regularmente su forma de facturar o de gestionar sus compras, informatizar un proceso inestable equivale a fijar el desorden.
- Nadie puede liberarse para pilotar el proyecto por parte del negocio. Sin un referente interno disponible, las decisiones de configuración se toman por defecto, a menudo mal, y se corrigen más tarde a mayor coste.
- Los datos de origen están en muy mal estado (duplicados masivos, plan contable incoherente, ningún historial fiable) y nadie está dispuesto a limpiarlos antes del proyecto.
- La empresa atraviesa una reorganización mayor (fusión, cambio de forma jurídica, reestructuración) que de todos modos cambiará los procesos en los próximos meses.
En estos casos, la mejor decisión a veces es posponer el proyecto unos meses en lugar de emprenderlo sobre un terreno inestable. Una auditoría previa permite decidirlo con objetividad.
La auditoría previa
Antes de cualquier configuración, documentamos la situación existente:
- Procesos vigentes: cómo circulan hoy los presupuestos, pedidos, facturas, pagos y salarios, y quién interviene en cada etapa.
- Herramientas actuales: software de contabilidad, de facturación, de nómina, hojas de cálculo, y cómo se articulan — o no — entre ellas.
- Datos: dónde residen, en qué formato, su grado de limpieza (duplicados, campos incompletos, incoherencias del plan contable).
- Volúmenes: número de clientes, proveedores, referencias de producto, asientos anuales, empleados — estas cifras determinan la complejidad de la migración de datos y de las pruebas.
- Restricciones normativas propias de la actividad: sujeción al IVA (tasas aplicables, método de liquidación), obligaciones sectoriales, convenios colectivos que influyen en la nómina.
Esta auditoría produce una visión clara de lo que existe y de lo que debe cambiar — es la base del cadraje siguiente, no una formalidad.
El cadraje: alcance, módulos, lo que se pospone
El cadraje traduce la auditoría en un alcance de proyecto concreto. Es la etapa donde se juega buena parte del éxito o fracaso posterior del proyecto, porque fija lo que debe funcionar en el arranque y lo que puede esperar.
Definir el alcance de la primera fase
La regla más útil es fácil de enunciar y difícil de respetar: empezar con el alcance más reducido que cubra las necesidades reales de funcionamiento de la empresa, no el alcance más completo posible. Un proyecto que intenta cubrir contabilidad, IVA, nómina, CRM, inventario y desarrollos específicos desde el primer día multiplica los puntos de decisión, las pruebas y las personas a movilizar en paralelo — y retrasa precisamente el momento en que la base financiera resulta fiable.
Elegir los módulos
La elección de los módulos se deriva directamente del alcance definido. Para la mayoría de las pymes, la base inicial cubre la contabilidad, la facturación y las compras básicas. Según la actividad, se añade desde el inicio el CRM y la gestión comercial, la gestión de existencias y compras, o la nómina y los recursos humanos — pero solo si estos módulos son indispensables para el funcionamiento diario, no porque existan en el catálogo de Odoo.
Lo que se pospone deliberadamente
Documentar explícitamente lo que se pospone, y por qué, evita dos escollos: la impresión de que algo se ha olvidado, y la tentación de añadirlo con urgencia en pleno proyecto. Habitualmente se posponen a una fase posterior: las integraciones con herramientas de terceros no críticas, los informes personalizados avanzados, los módulos de comercio electrónico o de gestión de proyectos cuando no condicionan el funcionamiento básico, y cualquier personalización que aún no haya demostrado su necesidad una vez la herramienta estándar esté en uso.
La configuración
Una vez validado el alcance, la configuración establece los cimientos técnicos y organizativos del sistema:
- Sociedad: razón social, forma jurídica, datos de contacto, moneda base, ejercicio contable.
- Plan contable: estructura de cuentas, agrupaciones, cuentas de balance y de resultados adaptadas a la actividad real — no solo el plan por defecto.
- Posiciones fiscales e IVA: vinculación de las cuentas y los productos a las tasas correctas, gestión de las operaciones exentas o en el extranjero, método de liquidación (efectiva o tasa de deuda fiscal neta según elegibilidad).
- Diarios: ventas, compras, banco, operaciones diversas, con las secuencias de numeración y las cuentas de contrapartida correctas.
- Cuentas bancarias: vinculación de las cuentas reales, formatos de importación de los extractos, configuración de la factura QR para la emisión y recepción de pagos.
- Derechos de acceso: quién puede ver, introducir, modificar o validar cada tipo de documento, por perfil de usuario.
- Flujos de validación: circuitos de aprobación de las facturas de proveedores, las notas de gastos, los pedidos de compra, según los umbrales y las responsabilidades internas.
Este trabajo de configuración es la parte menos visible del proyecto y la más determinante para la fiabilidad de las cifras producidas después.
La localización suiza: controlar y completar, no solo instalar
Odoo instala automáticamente el módulo de localización suiza (l10n_ch) en cuanto la sociedad se configura con Suiza como país. Este módulo sienta una base útil: estructura de plan contable adaptada a los usos suizos, tasas de IVA vigentes (8.1 %, 2.6 % y 3.8 %, en vigor desde el 1 de enero de 2024), y soporte de la factura QR, estándar suizo de pago.
El trabajo de implementación no termina ahí — empieza precisamente en ese momento. Esta base genérica debe ser:
- Controlada cuenta por cuenta, para verificar que corresponde a la estructura real de la actividad y no a un modelo genérico.
- Adaptada a las posiciones fiscales efectivas: tasas aplicables según las prestaciones, método de liquidación del IVA, incluida la verificación de la elegibilidad a los umbrales del impuesto a tasa de deuda fiscal neta (cifra de negocio máxima de CHF 5'024'000 e impuesto adeudado máximo de CHF 108'000 al año, en vigor desde el 1 de enero de 2025 según la AFC).
- Completada según los diarios, las cuentas bancarias y los flujos reales de la empresa — la localización de base no conoce ni sus cuentas bancarias ni su organización interna.
Es precisamente en esta etapa donde se nota la diferencia entre un integrador generalista y una fiduciaria: una localización instalada técnicamente pero no controlada en el fondo produce cifras que parecen correctas hasta el primer cierre de IVA, donde aparecen las desviaciones. Para todo lo relativo a la teneduría contable corriente una vez el sistema en marcha, vea nuestra página de contabilidad Odoo.
La migración de datos
La migración de datos responde a tres preguntas distintas, que hay que resolver por separado.
Lo que se migra
En general: las fichas de clientes y proveedores activos, el catálogo de productos, las facturas abiertas (aún no cobradas ni pagadas), los saldos de apertura en la fecha de cambio, y los datos necesarios para la continuidad operativa inmediata (existencias presentes, contratos en curso).
Lo que no se migra sistemáticamente
El historial contable detallado de los ejercicios cerrados normalmente no necesita reproducirse asiento por asiento en Odoo. Sigue siendo accesible en el sistema anterior o archivado en formato PDF, lo que satisface las obligaciones legales de conservación sin sobrecargar la migración. Del mismo modo, las fichas de clientes o proveedores inactivas desde hace tiempo, o los datos cuya fiabilidad es dudosa, a menudo se dejan voluntariamente de lado en lugar de migrarse «por si acaso».
La fecha de cambio
Se elige en función del calendario contable de la empresa — la mayoría de las veces al inicio de un ejercicio o de un período de IVA, para evitar dividir un período entre dos sistemas distintos. Los saldos de apertura en esa fecha se establecen con rigor: son los que garantizan la continuidad contable entre el sistema anterior y Odoo. Para un proyecto donde el sistema de origen ya está identificado y documentado, vea nuestra página dedicada a la migración de datos.
Desarrollos e integraciones, si son necesarios
Odoo estándar cubre la mayoría de las necesidades de una pyme. Un desarrollo específico o una integración con una herramienta de terceros (tienda en línea, caja registradora, software sectorial) solo se justifica cuando el estándar realmente no responde a la necesidad — no por principio. Cada desarrollo añade una dependencia que deberá mantenerse en las futuras actualizaciones de versión; documentamos sistemáticamente qué se desarrolla a medida y por qué, para que esa decisión quede trazable en el tiempo.
Por prudencia metodológica, todo desarrollo no estrictamente indispensable para el funcionamiento de la primera fase se pospone: una personalización prematura, decidida antes de que los equipos hayan usado el sistema estándar, a menudo se basa en un hábito de la herramienta anterior más que en una necesidad real en Odoo.
Las pruebas y la recepción
La recepción valida que el sistema configurado produce resultados correctos antes de que la empresa migre sus operaciones reales.
- Casos de prueba: datos representativos, construidos a partir de casos reales de la empresa, no datos genéricos.
- Escenarios de negocio: recorridos completos — desde el pedido hasta el cobro, desde la recepción de una factura de proveedor hasta su pago, desde el cálculo de un salario hasta su liquidación — probados de principio a fin, no función por función aislada.
- Validación contable: control de los balances, de las conciliaciones bancarias y de una simulación de liquidación de IVA antes del cambio definitivo. Es el control con más valor, porque es el que revela una configuración fiscal o contable mal ajustada antes de que produzca una cifra oficial.
La recepción se realiza con los usuarios que utilizarán realmente el sistema a diario, no solo con el referente del proyecto — son ellos quienes detectan las desviaciones entre la configuración teórica y el uso real.
La formación de los usuarios, por perfil
Una formación genérica, idéntica para todos, deja que cada uno se las arregle con las funciones que no le conciernen y descuida las que realmente necesita. La formación se construye, por tanto, por perfil:
- Contabilidad y finanzas: introducción, conciliación de partidas, conciliación bancaria, cierre periódico, liquidación de IVA.
- Ventas y facturación: presupuestos, pedidos, facturación, seguimiento de cobros.
- Compras y existencias, si este alcance se retiene: pedidos a proveedores, recepciones, inventario.
- Recursos humanos, si la nómina está en el alcance: gestión de los expedientes de empleados, ciclo de nómina, liquidaciones sociales.
- Dirección: lectura de los cuadros de mando y los indicadores, sin necesariamente la introducción operativa.
Descuidar la formación es una causa de fracaso tan frecuente como una mala configuración técnica: un sistema bien configurado pero mal comprendido genera errores de introducción que, a su vez, producen cifras incorrectas. El detalle de nuestro enfoque de formación se presenta en la página de formación Odoo.
El go-live y el período de estabilización
El go-live es el momento en que la empresa traslada definitivamente sus operaciones a Odoo. Va precedido de una congelación de las introducciones en el sistema anterior mientras se finaliza la migración de datos, y seguido de un período de estabilización durante el cual los primeros ciclos reales — primera facturación, primera conciliación bancaria, primer cierre de IVA — sacan a la luz desviaciones que ninguna recepción, por cuidadosa que sea, detecta enteramente de antemano. Este período se planifica como una fase del proyecto, con un acompañamiento reforzado, y no se trata como una sucesión de incidentes imprevistos.
El soporte y la mejora continua
Una vez superada la estabilización, la empresa pasa a un soporte ordinario: preguntas de uso, correcciones menores de configuración, acompañamiento de los cierres periódicos, evoluciones modestas según las necesidades constatadas. Es también el momento en que los módulos y funcionalidades voluntariamente pospuestos en el cadraje inicial pueden reevaluarse y añadirse, sobre una base ya estable. Vea nuestra oferta de soporte Odoo para el detalle de este acompañamiento continuo.
Lo que hace variar la duración y el presupuesto de un proyecto
No damos una horquilla de duración o de coste genérica: dependería de hipótesis que aún no conocemos al escribir esta página. En cambio, los factores que hacen variar un proyecto de implementación de Odoo, al alza como a la baja, son identificables:
- El alcance definido: número de módulos activados desde la primera fase, número de sociedades o entidades legales a configurar.
- El estado de los datos de origen: los datos limpios y estructurados se migran rápido; los datos dispersos, incoherentes o duplicados requieren un trabajo de limpieza previo que puede pesar más que la configuración misma.
- La disponibilidad del referente interno: un proyecto donde las decisiones se toman con rapidez avanza con regularidad; un proyecto donde cada validación espera varias semanas se alarga en la misma medida.
- El volumen de desarrollos específicos: cada personalización añade un ciclo de especificación, desarrollo y prueba que se suma a la configuración estándar.
- La complejidad normativa de la actividad: varias tasas de IVA, actividad internacional, convenios colectivos específicos de la nómina, multisociedades — cada uno de estos elementos añade casos a configurar y probar.
- La edición elegida, Community o Enterprise: esta decisión influye tanto en las funcionalidades disponibles de inmediato como en el modelo de coste recurrente por usuario.
- La versión de Odoo instalada: Odoo 19 es la versión estable actual; una versión reciente se beneficia de un soporte del editor más largo, lo que limita las actualizaciones forzadas a corto plazo.
Precisamente para ponderar estos factores en su situación real, y no en un caso genérico, el proyecto empieza con una auditoría y un cadraje documentados — no con un presupuesto elaborado antes de haber visto sus procesos. Si su empresa tiene sede en Ginebra o la región, vea también nuestro acompañamiento Odoo en Ginebra.