Hay proyectos de los que uno habla en abstracto —como consultor externo que entrega un sistema y se marcha— y hay proyectos que vives desde dentro, con el P&L encima de la mesa y la responsabilidad de que el negocio no se pare. El caso de Cymit Química es de los segundos. Fui CEO de la empresa durante la transformación tecnológica completa y lo que sigue no es una propuesta comercial: es lo que ocurrió, con sus friccionantes y sus resultados verificables.
Contexto: una empresa química con tres sistemas que no se hablaban
Cymit Química era una distribuidora de reactivos y productos químicos de laboratorio con un catálogo extraordinariamente amplio: más de dos millones de referencias de proveedores nacionales e internacionales. La operativa real se sostenía sobre tres sistemas completamente independientes:
- EuroWin como ERP de gestión: pedidos, albaranes, facturación. Un software de la generación anterior con escasa capacidad de integración y prácticamente sin API.
- Microsoft Access como base de datos de catálogo y referencias: docenas de ficheros Access distribuidos entre distintos equipos, con versiones inconsistentes y sin control de cambios.
- CRM Visual ad hoc para la gestión comercial: contactos, oportunidades y seguimiento de clientes en un sistema que tampoco se sincronizaba con el ERP.
El resultado de esta arquitectura fragmentada era predecible: datos duplicados, errores de stock, catálogo web desactualizado con frecuencia, incapacidad de ofrecer precios en tiempo real a los clientes y un equipo de soporte que dedicaba horas diarias a reconciliar información entre sistemas. La web de comercio electrónico era estática en la práctica: actualizar el catálogo requería intervención manual y los tiempos eran incompatibles con las exigencias del mercado.
«El mayor enemigo del crecimiento no era la competencia. Era nuestro propio ecosistema tecnológico, que consumía energía operativa en lugar de generarla.»
El reto real: no solo tecnología, sino cambio de modelo de negocio
Cuando asumí la dirección ejecutiva, quedó claro desde el primer análisis de P&L que el cuello de botella no era comercial ni logístico: era la plataforma. El catálogo de dos millones de referencias era un activo diferencial brutal —pocas distribuidoras en España podían ofrecer esa profundidad— pero ese activo estaba atrapado en sistemas que impedían explotarlo correctamente.
El reto tenía varias dimensiones simultáneas:
- Dimensión operativa: migrar toda la operativa diaria (pedidos, facturas, stock, proveedores) a un sistema unificado sin interrumpir el negocio.
- Dimensión de catálogo: automatizar la gestión y actualización de más de dos millones de referencias procedentes de múltiples proveedores con formatos de datos heterogéneos.
- Dimensión comercial: dotar al equipo de ventas de una herramienta CRM integrada con el ERP para que la información de cliente y la operativa hablaran el mismo idioma.
- Dimensión de equipo: escalar la capacidad técnica interna para sostener la plataforma y desarrollar nuevas funcionalidades.
La solución: arquitectura Odoo unificada y crawling masivo
Elección de plataforma: por qué Odoo
La decisión de apostar por Odoo como plataforma única no fue trivial. En ese momento existían alternativas más establecidas en el sector de distribución química, con mayor cuota de mercado y más referencias. La razón para elegir Odoo fue estratégica, no tecnológica: necesitábamos una plataforma que pudiera crecer a medida que crecía el negocio, con capacidad de personalización sin depender de un proveedor único, y con una arquitectura técnica lo suficientemente abierta para construir sobre ella el sistema de gestión automática de catálogo que el negocio requería. La naturaleza open source de Odoo era exactamente eso: soberanía tecnológica.
Migración desde EuroWin y Access
La migración desde EuroWin fue el trabajo más delicado del proyecto. EuroWin no tiene una API moderna; extraer los datos históricos de pedidos, clientes, proveedores y albaranes requirió un proceso de extracción directa de la base de datos del sistema con transformación y limpieza intensiva antes de la carga en Odoo. El catálogo en Access presentó una complejidad adicional: los ficheros tenían inconsistencias de nomenclatura, códigos duplicados entre proveedores y campos sin normalizar que necesitaban resolución antes de poder importarse como referencias de producto en Odoo.
La migración se planificó en fases para minimizar el riesgo operativo: primero los maestros (clientes, proveedores, productos), luego el histórico de movimientos, y finalmente el corte operativo con el sistema en producción.
Sistema de crawling masivo para las referencias
El elemento más diferencial de la arquitectura fue el sistema de crawling y scraping para la gestión automática del catálogo. Con más de dos millones de referencias de decenas de proveedores, la actualización manual era inviable. Se diseñó e implementó un sistema de pipelines en Python que:
- Realizaba extracciones automáticas periódicas de los catálogos de proveedores (tanto vía API cuando estaba disponible como mediante scraping web estructurado cuando no).
- Normalizaba los datos con reglas de transformación específicas por proveedor, resolviendo inconsistencias de formato, moneda y unidad de medida.
- Sincronizaba las actualizaciones directamente en el catálogo de Odoo, manteniendo el stock, los precios y la disponibilidad en tiempo real.
- Generaba alertas cuando se detectaban anomalías o referencias que requerían revisión manual.
Este sistema convirtió el catálogo de dos millones de referencias de un lastre operativo a una ventaja competitiva real: la web de Cymit podía ofrecer información de disponibilidad y precio actualizada de forma automática, algo que los competidores sin esa infraestructura no podían replicar fácilmente.
Escalado del equipo técnico
Al inicio del proyecto, el equipo técnico era de una sola persona. Para sostener y desarrollar la plataforma, fue necesario un proceso de construcción de equipo: de 1 a 5 personas, incorporando perfiles de QA, desarrollo frontend, desarrollo backend y arquitectura de datos. Este crecimiento se gestionó de forma gradual, alineado con las fases del proyecto y con la capacidad financiera de la empresa en cada momento.
Resultados: números reales y un exit verificable
Crecimiento de facturación
Durante el período de transformación tecnológica sobre Odoo, la facturación de Cymit Química pasó de 2 M€ a 4 M€. No fue únicamente consecuencia de la tecnología —las decisiones comerciales, la expansión del catálogo accesible y la mejora en la capacidad de respuesta al cliente jugaron un papel conjunto— pero la plataforma fue el habilitador sin el cual ese crecimiento no habría sido posible a ese ritmo.
Exit al Grupo PALEX
El desenlace del proceso fue la adquisición de Cymit Química por el Grupo PALEX, uno de los grupos de distribución de material médico-quirúrgico y de laboratorio de referencia en España. Fue la segunda adquisición consecutiva de la empresa. Una empresa con tres sistemas legacy incompatibles y un catálogo atrapado en ficheros Access no es adquirible a ese nivel. La plataforma construida sobre Odoo fue un activo diferencial en el proceso de due diligence: arquitectura moderna, datos unificados, operativa escalable.
Lo que realmente cambió
Más allá de las cifras, el cambio estructural fue de modelo de operación:
- De actualización manual de catálogo a sincronización automática con proveedores.
- De tres sistemas desconectados a una única fuente de verdad para toda la operativa.
- De un equipo técnico de emergencia a un equipo de producto con capacidad de desarrollo continuo.
- De una empresa dependiente de su infraestructura heredada a una plataforma que un comprador estratégico podía integrar en su ecosistema.
Lecciones para tu proyecto
1. La migración de ERP es un proyecto de negocio, no un proyecto de IT
El error más frecuente en migraciones de ERP es tratarlas como proyectos tecnológicos. En Cymit, cada decisión técnica se evaluó primero desde el impacto en el margen y en la operativa diaria. Qué módulos implantar primero, qué datos migrar con qué prioridad, cuándo hacer el corte: todas esas decisiones se tomaron con criterio de negocio, no de conveniencia técnica.
2. El catálogo como activo estratégico
Dos millones de referencias son un número que parece un problema. Tratado correctamente, con la arquitectura de automatización adecuada, se convierte en una barrera de entrada para la competencia. La pregunta no es «¿cómo gestionamos esto?» sino «¿cómo convertimos este volumen en una ventaja?».
3. La plataforma debe poder ser adquirida
Si en algún momento de tu horizonte temporal existe la posibilidad de una adquisición, la plataforma tecnológica es parte del precio. Una empresa con Odoo bien implantado, datos limpios y arquitectura documentada vale más en un proceso de M&A que la misma empresa con sistemas legacy inauditables. La tecnología es due diligence.
4. Open source no significa barato: significa libre
Odoo Community no es la opción económica de consolación frente a SAP o Dynamics. Es la opción que garantiza que el código es tuyo, que no dependes de renovaciones de licencia para seguir operando y que puedes construir encima sin pedir permiso a nadie. Esa libertad tiene un valor económico real cuando llega el momento de escalar o de vender.
¿Tienes un proyecto similar?
Si estás evaluando migrar de un ERP legacy —EuroWin, Navision, Sage, A3— a Odoo, o si tienes Odoo implantado y no está funcionando al nivel que necesitas, puedo revisar tu situación con la misma perspectiva que apliqué en Cymit: primero el negocio, luego la arquitectura. La auditoría técnica inicial es gratuita para proyectos cualificados.