Los errores que vemos al implantar Dolibarr en pymes (y cómo los evitamos)

Llevamos desde 2019 poniendo Dolibarr en marcha en empresas pequeñas y medianas, y los proyectos que salen mal casi nunca fallan por lo que la gente teme. No fallan por el software: fallan por decisiones que se toman en las dos primeras semanas y que no se ven hasta el sexto mes.

Estos son los errores que más repetimos ver. Van sin adornos, porque en varios de ellos nos hemos equivocado nosotros antes de aprenderlos. Si quieres el detalle de cómo trabajamos hoy, está en nuestros servicios sobre Dolibarr; aquí van los tropiezos.

1. Migrar el desorden en vez de arreglarlo

Es el error más caro y el más frecuente. La empresa lleva años con un maestro de artículos lleno de duplicados, clientes repetidos con tres razones sociales distintas y precios que solo entiende quien los puso. Y la decisión por defecto es «lo pasamos todo tal cual y ya lo limpiamos dentro».

No se limpia nunca. Lo que ocurre es que el ERP nuevo hereda el desorden y encima carga con la culpa: «desde que cambiamos de sistema no encontramos nada».

Migrar es la única oportunidad real de hacer limpieza, porque es el único momento en que alguien va a mirar los datos uno por uno. Nosotros preferimos entrar con menos datos y limpios que con todo el histórico y sucio.

2. Personalizar antes de haber trabajado con el estándar

Dolibarr es muy moldeable, y esa es justo la trampa. En la reunión de arranque siempre hay una lista de «esto lo necesitamos como lo teníamos». Si se programa toda esa lista antes de que nadie haya usado el sistema, se acaba pagando desarrollo para replicar costumbres que venían de las limitaciones del programa anterior.

La secuencia que funciona es la contraria: montar el estándar, trabajar con él unas semanas y entonces decidir qué falta de verdad. Suele desaparecer la mitad de la lista. Y lo que sobrevive, ya viene con un motivo concreto detrás en lugar de «es que siempre lo hemos hecho así».

3. Tocar el núcleo

Este es técnico, pero se paga en dinero. Cuando algo no encaja, la vía rápida es editar directamente los ficheros del núcleo de Dolibarr. Funciona esa tarde. El problema llega con la siguiente actualización: o pierdes el cambio, o te quedas sin poder actualizar.

Y quedarse sin actualizar no es un problema estético. Es quedarte fuera de las correcciones de seguridad y, con lo que viene en materia fiscal, quedarte fuera de los cambios normativos. Todo lo que hacemos va como módulo, sin tocar el núcleo, precisamente para que actualizar siga siendo posible.

4. Confundir la formación con una demo

Una sesión de dos horas enseñando pantallas no es formación: es una demo. La gente asiente, toma notas y a la semana siguiente hace las cosas como antes, porque nadie ha practicado con sus propios casos.

La formación que sirve es corta, por perfiles y con los datos reales de la empresa delante. El de almacén no necesita ver la contabilidad. Y conviene repetirla a las dos o tres semanas, cuando ya han chocado con dudas de verdad y las preguntas dejan de ser genéricas.

5. No designar a nadie responsable dentro de la empresa

Si el proyecto no tiene un dueño interno —alguien de la casa que decide, resuelve dudas y arbitra cuando dos departamentos quieren cosas incompatibles—, el proveedor acaba tomando decisiones de negocio que no le corresponden.

No hace falta que sea informático. Hace falta que conozca cómo funciona la empresa y que tenga autoridad para decir «esto se hace así». Los proyectos con esa figura van bastante mejor, y esto se nota desde la primera semana.

6. Arrancar por enero, y encima con la contabilidad

Hay una tentación lógica de hacer coincidir el estreno con el cambio de ejercicio. Y en el papel tiene sentido. En la práctica, enero es cuando más trabajo administrativo hay y menos margen existe para que algo salga regular.

Si se puede elegir, mejor arrancar en un mes tranquilo y en fases: primero facturación y clientes, luego compras y almacén, y la contabilidad cuando lo anterior ya sea rutina. Un arranque por fases da margen para corregir; un arranque total el 2 de enero, no.

7. Dejar el cumplimiento fiscal para el final

Este es reciente y ya lo hemos visto varias veces. Se planifica la implantación entera y se deja «lo de VeriFactu» como un flequillo del final, cuando resulta que condiciona cómo se numeran las facturas, qué se puede modificar después de validarlas y qué certificado hace falta tener.

Con las fechas encima —1 de enero de 2027 para sociedades y 1 de julio de 2027 para autónomos, según el Real Decreto-ley 15/2025—, lo lógico es que entre en el diseño desde el principio. Lo contamos aparte en la página del módulo VeriFactu Dolibarr de EasySoft Tech S.L., que es donde está el detalle técnico.

Lo que sí funciona

Resumido en una frase: implantar poco, pronto y con datos limpios, y ampliar cuando lo anterior ya sea costumbre.

Casi todos estos errores comparten la misma raíz, que es querer llegar al final el primer día. Un ERP no se estrena, se adopta, y eso lleva unos meses en los que la empresa sigue facturando y vendiendo mientras aprende. Contar con eso desde el principio es lo que separa un proyecto tranquilo de uno que se recuerda mal.

¿Estás pensando en dar el paso o tienes un Dolibarr a medio arrancar? Cuéntanos en qué punto estás y te decimos con franqueza qué haríamos nosotros.