Durante años, quedarse en una versión antigua del programa de gestión fue una decisión sin consecuencias. El sistema seguía facturando, la contabilidad cuadraba y la empresa se ahorraba el trastorno de actualizar.
Las normas que regulan la factura electrónica han terminado con esa comodidad. Ahora el programa no solo tiene que funcionar: tiene que cumplir requisitos concretos sobre cómo genera, encadena y conserva los registros de facturación. Un sistema que no los cumple no es un sistema anticuado, es un sistema que no se puede usar. Antes, actualizar era una inversión que podía esperar indefinidamente; ahora hay una obligación y hay un calendario.
Qué se configura y qué se desarrolla a medida
La buena noticia es que este escenario se decide en gran parte al principio.
Durante cualquier implantación aparecen peticiones que el producto no cubre de serie: un informe con un formato concreto, una automatización que replica un flujo interno, una integración con el sistema de un cliente importante. Algunas aportan valor real y merecen desarrollarse. Otras solo reproducen una costumbre que nadie se ha parado a revisar.
Distinguir entre ambas es el trabajo más valioso de un buen consultor, y el que más se nota años después. Una empresa que desarrolla lo que de verdad la diferencia y configura el resto con las opciones estándar actualiza con facilidad. Una que convierte en código cada hábito heredado se encuentra con que cada versión nueva exige revisar todo lo construido encima.
No es casualidad que cualquier guía seria que explique cómo abordar la implantación de un ERP dedique más espacio al análisis previo que a la instalación en sí. Esa fase es donde se separa lo que aporta ventaja competitiva de lo que solo es inercia, y esa decisión determina el coste de los años siguientes.
Los plazos normativos son fijos; los proyectos, no
Las fechas que marca la normativa no se mueven, y los proyectos de software tienden a alargarse. Cuando ambas cosas coinciden, la empresa que va justa resuelve con lo que tenga, y eso suele significar decisiones caras tomadas con prisa.
Las organizaciones que llegan holgadas a un cambio normativo no son las que empezaron antes, sino las que mantuvieron el sistema al día durante todo el recorrido. Actualizar con regularidad convierte cada salto en algo menor; acumular versiones convierte el primero en un proyecto.
El conocimiento tiene que quedarse en la empresa
Quien configura un sistema conoce el motivo de cada decisión, y ese motivo rara vez queda documentado por defecto. Si esa persona cambia de trabajo —y en este sector se cambia con frecuencia—, la organización se queda con un sistema que funciona y sin nadie que sepa por qué funciona así.
Las empresas que lo llevan bien piden documentación desde el primer día y un contrato de soporte con horas asignadas. También preguntan cuánta gente del proveedor conoce el proyecto, porque un despliegue sostenido por una sola persona es frágil por buena que sea. Implantadores oficiales de Odoo especializados en pymes, como Sirtek, resuelven esto trabajando en equipo y dejando documentado el porqué de cada configuración.
El código abierto reparte la dependencia
Parte del mercado ha ido migrando hacia soluciones de código abierto por una razón que tiene que ver con todo lo anterior. Es el caso de Odoo, que se ha convertido en la alternativa más extendida entre pymes frente a los sistemas propietarios clásicos: empresas que hace cinco años ni sabían para qué sirve Odoo hoy lo tienen en la lista corta cuando renuevan sistema. Y el motivo de fondo no es el ahorro en licencias —la diferencia entre la versión Community gratuita y la Enterprise de pago es menor de lo que suele creerse—: es que el cliente conserva el acceso al código y puede cambiar de proveedor sin cambiar de sistema.
Con software propietario, si una norma obliga a adaptarse y el fabricante tarda, no hay alternativa posible. Con un sistema como Odoo, si el proveedor deja de convenir se busca otro partner que trabaje sobre la misma base.
Un sistema que envejece bien
Al final, cuánto cuesta implantar un ERP importa menos de lo que parece. Lo que pesa es cómo estará ese sistema dentro de unos años, cuando la normativa haya vuelto a cambiar y la empresa sea más grande.
Un calendario de actualizaciones acordado con el proveedor, la documentación al día y adaptaciones solo donde aportan. Con esos deberes hechos, cada cambio normativo se queda en lo que debería ser: un trámite más, no una crisis.
