ERP a medida o ERP estándar: cuándo compensa Odoo, Holded, SAP Business One o una solución propia

Si vuestros procesos encajan bien en un ERP del mercado, empezar desde cero casi nunca es una buena inversión: estaríais pagando por construir algo que ya existe, que otros han probado y que otros mantienen. Un ERP a medida empieza a tener sentido cuando adaptar la empresa al software cuesta más —en trabajo manual, excepciones, hojas paralelas y personalizaciones que nadie se atreve a tocar— que construir alrededor de cómo trabajáis de verdad.

Entre esos extremos hay más caminos de los que parece: configurar bien un ERP estándar, conectarlo con lo que ya tenéis o construir solo la parte que ninguna herramienta cubre. Esta guía explica los cuatro escenarios, qué necesidad resuelven productos tan distintos como Odoo, Holded o SAP Business One, cuándo deja de compensar personalizar y qué preguntas responder antes de decidir.

El criterio que ordena todo lo demás: la mejor solución es la más sencilla que resuelva bien el proceso.

No son dos opciones, son cuatro

El debate suele plantearse como un binario, software del mercado contra desarrollo propio. En la práctica hay cuatro escenarios.

1. ERP estándar casi sin tocar. Se configura lo básico —impuestos, series, usuarios— y la empresa trabaja como la herramienta propone. Es lo más rápido y lo que menos mantenimiento propio exige.
2. ERP estándar configurado y con integraciones. Sigue siendo estándar, pero se ajusta a fondo con lo que ya trae (campos, flujos, permisos, informes) y se conecta con la tienda online, el banco, el CRM o un programa del sector.
3. ERP estándar muy personalizado. Módulos de terceros, desarrollos y scripts para que haga lo que no hace de serie. Sigue siendo «el ERP de siempre», pero una parte creciente es código vuestro que hay que mantener.
4. ERP o sistema de gestión a medida. El núcleo de la operación vive en un sistema construido para vuestra forma de trabajar, conectado con las herramientas estándar que sigan teniendo sentido.

Muchas empresas están en el 2 o en el 3, y ahí se toman las decisiones más difíciles.

Qué aporta un ERP estándar, y dónde se queda corto

Un ERP del mercado tiene ventajas difíciles de replicar:

• Producto probado: muchas empresas han pasado antes por los mismos procesos de facturación, compras o inventario.
• Puesta en marcha potencialmente más rápida: se configura e implanta, no se construye.
• Actualizaciones y cambios normativos que llegan sin desarrollarlos.
• Ecosistema: módulos, integraciones hechas, documentación y empresas que lo conocen.
• Menor inversión inicial en muchos escenarios.

Los límites aparecen cuando el negocio no se parece al proceso que la herramienta da por supuesto:

• El proceso se adapta al software. A veces es una mejora, porque la herramienta trae buenas prácticas; otras obliga a trabajar peor.
• Pagáis funciones que no usáis y os faltan las que necesitáis.
• Las personalizaciones no salen en la cuota: hay que desarrollarlas, probarlas y mantenerlas en cada actualización.
• Dependéis del roadmap del fabricante.
• Las integraciones con sistemas poco comunes pueden ser más complejas que el propio ERP.
• Los workarounds se acumulan: el Excel «solo para esto», el campo de notas que hace de estado, el correo que sustituye a una aprobación.

Cuánto pesan depende del producto y del caso: no es lo mismo una herramienta de facturación ampliada que un ERP modular pensado para personalizarse.

Qué aporta un ERP a medida, y qué exige

Un sistema construido para vuestra operación puede:

• encajar en el proceso real, con vuestras reglas, estados y excepciones;
• dar a cada rol la pantalla que necesita;
• integrarse a fondo con maquinaria, APIs, el ecommerce o un software sectorial;
• automatizar lo específico;
• evolucionar al ritmo del negocio, sin esperar a un fabricante;
• ser vuestro, en la medida en que el contrato deje clara la propiedad del código y de los datos.

Y exige cosas que conviene mirar de frente:

• más inversión inicial: análisis, diseño, desarrollo, pruebas e infraestructura;
• mantenimiento y evolución continuos: un sistema propio no se actualiza solo;
• responsabilidad tecnológica: seguridad, copias y documentación pasan a ser asunto vuestro y de vuestro proveedor;
• un proveedor competente, porque el riesgo principal no es técnico: es construir con precisión el proceso equivocado.

Un ERP a medida no es la versión «premium» de un ERP. Es lo que aparece cuando la forma de operar deja de parecerse a la de los demás y eso tiene valor.

Tres herramientas que no son lo mismo: Odoo, Holded y SAP Business One

Sirven de ejemplo precisamente porque resuelven necesidades distintas. Esto no es un ranking: compararlas casilla a casilla sería engañoso. Lo que sigue se basa en lo que publica cada fabricante en su web y su documentación (consultadas en octubre de 2026), y no es una recomendación: Bolmia no implanta ni revende ninguno de estos productos.

Odoo: una plataforma modular que crece por aplicaciones

Odoo se define como un conjunto de aplicaciones empresariales de código abierto: contabilidad, ventas y CRM, inventario, fabricación, proyectos, recursos humanos o ecommerce se activan como aplicaciones sobre la misma base, en una edición Community abierta o una Enterprise con licencia.

Lo relevante aquí es su escalera de personalización. Con Studio se añaden campos, vistas, automatizaciones, informes o aplicaciones sencillas sin programar; más allá, se desarrollan módulos propios. La diferencia entre ambas cosas la documenta la propia Odoo:

• Su página de planes explica que el plan Estándar se aloja en su nube «sin módulos personalizados», que instalar Studio lleva al plan Personalizado y que el mantenimiento de código personalizado y la implantación no están incluidos en los planes.
• Su documentación de actualización advierte de que una base de datos con módulos propios no se puede actualizar hasta que esos módulos estén disponibles para la nueva versión, y que adaptarlos es responsabilidad de quien los mantiene.

Odoo puede ser exactamente la decisión correcta: si vuestras áreas encajan en sus aplicaciones y lo que falta se resuelve con configuración y Studio, tenéis una plataforma amplia mantenida por otros. La señal a vigilar es que la implantación pida cada vez más desarrollo propio: entonces el proyecto deja de ser «usar Odoo» y pasa a ser mantener un software vuestro dentro de Odoo, a su calendario de versiones.

Holded: gestión administrativa sencilla para autónomos y pymes

Holded se presenta como «el software de gestión para pymes y emprendedores» y como ERP en la nube. Su centro es la gestión administrativa de una empresa española —facturación, contabilidad, tesorería e impuestos—, con módulos de CRM, proyectos, inventario o equipo, algunos como complementos de pago.

Su filosofía está en su web: «Se configura, no se programa». Para ampliarla propone integraciones hechas, complementos y su API, y aclara que la API exige que alguien con perfil técnico escriba la integración. Lo específico se construye fuera y se conecta.

No conviene medirla con la vara de Odoo o SAP Business One. Es una herramienta mucho más sencilla y, para una empresa que necesita facturar bien, llevar la contabilidad al día y organizar clientes y proyectos con procesos habituales, esa sencillez es una ventaja. Sus límites razonables aparecen con operativas muy particulares —reglas de negocio propias, flujos con muchos estados y roles, producción o logística fuera de lo estándar—: ahí la conversación es qué se construye alrededor, o si el núcleo debe vivir en otro sistema.

SAP Business One: un ERP integral para pequeñas y medianas empresas

SAP describe SAP Business One como una solución ERP para pequeñas y medianas empresas: contabilidad y finanzas, compras, inventario, ventas y clientes, informes y analítica, además de producción y planificación de materiales, en servidores propios o en la nube. Dos rasgos importan aquí:

• Se implanta a través de partners. SAP indica que se vende, implanta y soporta a través de su red de partners, que aportan también soluciones sectoriales. No publica precios cerrados: remite a pedir cotización.
• Se extiende sobre un núcleo estándar, con campos y tablas definidos por el usuario, herramientas de desarrollo e interfaces de integración. Se adapta, no se reescribe.

En su formación sobre la metodología de implantación, SAP advierte de que no hay que subestimar el tiempo de analizar requisitos y de que la migración de datos suele llevar más de lo previsto. Vale para cualquier proyecto, estándar o a medida.

Las tres permiten, en distinta medida, configurar, ampliar e integrar. Cambia cuánto proceso cubren de serie, por dónde se amplían y quién mantiene lo añadido. Esa es la pregunta útil, no cuál es «mejor».

Una tabla para situar vuestro caso

No compara marcas, sino situaciones. Es orientativa: el producto concreto y cada proyecto pueden cambiar la respuesta.

Situación	Suele encajar mejor
Procesos habituales del sector y pocas excepciones	ERP estándar
Hay que arrancar pronto y con poca inversión inicial	ERP estándar
Integraciones habituales: banco, tienda online, asesoría	ERP estándar con integraciones
Reglas propias que caben en la configuración	ERP estándar bien configurado
Personalizaciones que crecen con cada versión	Revisar: puede costar más que construir la parte propia
El ERP funciona, pero la operación vive fuera	Capa propia conectada al ERP
Proceso propio que da margen, con muchas excepciones y roles	Desarrollo a medida de ese núcleo
Necesidad de controlar cómo evoluciona el sistema	Desarrollo a medida
Proceso todavía sin definir	Nada todavía: definirlo primero

Cómo leerla:

• La fila de las personalizaciones es la más incómoda: suma la dependencia del fabricante y el mantenimiento de un código propio que debe seguir funcionando en cada versión.
• Muchas integraciones no implican a medida. Un estándar bien integrado funciona; decide si cada integración es habitual (hay conector mantenido) o propia.
• A medida no significa sin dependencia: pasáis a depender de quien mantiene el sistema, y por eso importan la documentación y la propiedad del código.

Señales de que un ERP estándar puede ser suficiente

• Facturáis, compráis, vendéis y controláis stock como la mayoría de vuestro sector.
• Las excepciones son pocas y se gestionan a mano sin esfuerzo.
• El equipo es pequeño o mediano y las funciones están claras.
• Necesitáis algo que funcione pronto.
• Las integraciones son habituales: banco, tienda online conocida, asesoría.
• Podéis adoptar un proceso conocido sin perder lo que os diferencia.

Si os reconocéis aquí, no hay mérito en desarrollar por desarrollar: configurad bien la herramienta, formad al equipo y guardad el presupuesto para un problema que lo justifique.

Señales de que empieza a tener sentido algo a medida

• Varios Excel paralelos cubren lo que el ERP no hace.
• El mismo dato se teclea en varios sitios y nadie sabe cuál es el bueno.
• ERP, CRM y ecommerce conviven sin una fuente de verdad para clientes, precios o stock.
• Partes del proceso pasan por WhatsApp o por correo.
• Cada mes aparece una personalización nueva y cada actualización da miedo.
• Las reglas comerciales —tarifas, condiciones, aprobaciones— son propias y cambian a menudo.
• La operación es sectorial, con roles y permisos que no encajan en los perfiles estándar.
• Los informes de dirección exigen exportar y cruzar a mano.
• Clientes, proveedores o técnicos externos necesitan su propio acceso.
• Hay que integrar maquinaria, APIs de terceros o sistemas propios.

Una sola señal no justifica un desarrollo; varias a la vez, sobre todo en el proceso que da margen, justifican analizarlo. Si lo que se escapa del sistema vive en hojas de cálculo, cuándo dejar Excel amplía estas señales.

La zona gris: seguir personalizando o construir lo propio

La decisión real de muchas empresas no es «Odoo o programar un ERP». Es esta: ¿seguimos añadiendo módulos, plugins, scripts y personalizaciones al sistema que tenemos, o ha llegado el momento de construir una capa propia?

No hay un umbral universal, pero sí criterios que ayudan a verlo:

1. Qué parte del valor está en lo personalizado. Si las personalizaciones tocan detalles, el estándar sigue mandando. Si el proceso que os diferencia vive ya en código propio, el ERP es el soporte de un desarrollo vuestro.
2. Cuánto cuesta cada actualización. Cuando cada versión obliga a revisar, adaptar y probar desarrollos, quedarse empieza a costar como construir.
3. Si las personalizaciones luchan contra el modelo de datos. Ampliar un campo es sencillo; obligar a la herramienta a tratar un pedido o un servicio de una forma que su estructura no contempla suele ser frágil.
4. Quién entiende el conjunto. Si solo una persona o un proveedor sabe cómo encajan módulos, scripts y automatizaciones, el riesgo ya no está en la herramienta.
5. Si el workaround es ya el proceso. Cuando el procedimiento real incluye «exportar, corregir en Excel y volver a importar», el sistema no gobierna la operación.
6. Qué pasaría si hubiera que cambiar de proveedor de implantación. Si la respuesta es «no sabríamos por dónde empezar», primero hace falta documentación.

Construir lo propio no significa tirar el ERP. Muchas veces la salida es dejar en la herramienta lo que hace bien y sacar a una capa propia la parte que la estaba forzando.

Integrar sin sustituir: construir alrededor del ERP

Una alternativa que suele quedar fuera del debate: mantener el ERP y construir software a su alrededor. Funciona cuando el ERP resuelve bien el núcleo administrativo y fallan las piezas que lo rodean:

• ERP + portal de clientes, para consultar pedidos, documentos o incidencias sin llamar.
• ERP + ecommerce, decidiendo quién manda en el stock y en el precio entre la web y el ERP.
• ERP + aplicación operativa para técnicos, almacén o planta.
• ERP + automatización de avisos, aprobaciones y traspasos que hoy son manuales.
• ERP + cuadro de mando que junte varias fuentes sin exportaciones.
• ERP + software sectorial, conectados para que el dato entre una sola vez.

El ERP sigue mandando en contabilidad, facturación y lo que ya hace bien, y lo propio se limita a lo que no existe. Es la idea de fondo de las soluciones de software a medida bien planteadas: conectar sistemas, no necesariamente reemplazarlos.

Cuatro situaciones habituales

Son escenarios inventados para ilustrar el razonamiento; no son clientes de Bolmia.

Una empresa de servicios de unas quince personas con presupuestos, facturación, CRM y proyectos gestionados como en su sector. Lo más probable es que la resuelva una herramienta del mercado bien configurada; el mismo razonamiento, aplicado a cualquier herramienta SaaS y no solo al ERP, está en SaaS del mercado o software a medida.

Una empresa con ERP en marcha cuya operación vive en Excel, WhatsApp y correo. El ERP factura, pero partes, incidencias y planificación van por fuera. Antes de cambiar de ERP, conviene estudiar una capa propia conectada a él que recoja esa operación.

Una empresa con un flujo sectorial muy específico: varios roles que intervienen en orden, reglas propias y accesos externos. Aquí sí tiene sentido estudiar un sistema a medida para ese núcleo, conectado con la contabilidad y lo estándar.

Una empresa que todavía no tiene claro cómo quiere trabajar. Ni estándar ni a medida: primero hay que definir el proceso. Una herramienta sencilla durante unos meses enseña más que cualquier desarrollo, y lo aprendido sirve para preparar los requisitos si después hay que construir.

Qué cuesta cada camino, sin quedarse en la cuota

Un error frecuente es comparar la cuota mensual de un ERP con el presupuesto de un desarrollo. Un ERP estándar cuesta licencias, implantación, configuración, personalizaciones, integraciones, formación y soporte; un ERP a medida, análisis, desarrollo, pruebas, infraestructura, mantenimiento y evolución.

Para compararlos se usa el coste total de propiedad: lo que cuesta cada opción durante varios años, no el primer mes. En los dos lados hay que sumar:

• implantación y consultoría;
• personalización y su mantenimiento en cada versión;
• integraciones y su mantenimiento;
• licencias, que crecen con usuarios y módulos;
• soporte, mantenimiento y evolución;
• las horas internas del equipo durante el proyecto;
• el trabajo manual que seguirá existiendo, que es el coste que menos aparece y el que más dura.

Para poner cifras a cada camino, cuánto cuesta un ERP a medida separa lo que cuesta implantar, personalizar, integrar o construir, con rangos orientativos del mercado español. Si el desarrollo es la opción que estáis valorando, el artículo sobre cuánto cuesta un software a medida da rangos orientativos de mercado y explica qué se paga después del lanzamiento.

Errores frecuentes al decidir

• Desarrollar porque «queremos algo nuestro». La propiedad vale cuando el proceso vale.
• Elegir ERP por la cantidad de funciones, en vez de por cómo cubre vuestros procesos.
• Personalizar sin límite. Cada personalización parece pequeña; juntas convierten el estándar en un desarrollo propio difícil de actualizar.
• Olvidar la migración de datos, que nunca está tan ordenada como se cree.
• No decidir quién manda en cada dato cuando conviven varios sistemas.
• Copiar el proceso actual sin cuestionarlo: es pagar dos veces por un procedimiento que ya no tenía sentido.
• Decidir solo por el precio mensual, la parte más visible del coste y casi nunca la más grande.

Diez preguntas antes de decidir

1. ¿Nuestro proceso es realmente diferente, o solo lo hacemos de una forma particular por costumbre?
2. ¿Qué parte de lo que necesitamos resuelve ya una herramienta existente?
3. ¿Qué tendríamos que cambiar de nuestra operativa para usarla, y estamos dispuestos?
4. ¿Qué personalizaciones necesitaríamos, y cuáles son imprescindibles?
5. ¿Qué integraciones son obligatorias, y existen ya o habría que construirlas?
6. ¿Cuánto trabajo manual seguiría existiendo con cada opción?
7. ¿Quién mantendrá las personalizaciones o el sistema dentro de tres años?
8. ¿Esperamos que el proceso cambie mucho en los próximos años?
9. ¿Tenemos volumen suficiente para que automatizarlo compense?
10. ¿Este proceso es una ventaja competitiva, o simplemente algo que hay que hacer bien?

Si las respuestas a la 1, la 6 y la 10 apuntan a «sí, es nuestro y nos diferencia», el desarrollo merece estudiarse. Si apuntan a «no», probablemente el camino es una herramienta estándar bien implantada.

Cómo lo planteamos en Bolmia

Primero entendemos el proceso: quién interviene, qué datos se mueven, dónde están las excepciones y qué herramientas ya funcionan. Después decidimos si conviene configurar lo que ya tenéis, integrar lo que necesita hablarse o construir solo la parte que no existe. A veces la conclusión es que no hace falta desarrollar nada, y lo decimos.

Cuando la respuesta es construir el núcleo de la operación, eso es un desarrollo de ERP a medida, casi siempre conectado con las herramientas estándar que tienen sentido. Cuéntanos cómo trabajáis hoy y vemos qué camino encaja.