Software a medida, estándar o modular: cómo elegir sin arrepentirte

Elegir el software de gestión se parece a elegir casa: puedes construirla desde cero, comprar un piso tal cual o reformar uno con buena estructura. Las tres opciones funcionan. Las tres pueden salir muy caras si eliges la que no te toca.

Aquí tienes las diferencias reales, los riesgos de cada camino con casos documentados y un cambio legal que llega el 12 de enero de 2027 y que conviene conocer antes de firmar nada.

Las tres opciones, en una frase cada una

• Software estándar: un producto igual para todos los clientes, que se configura pero no se reescribe.
• Software a medida: un desarrollo hecho desde cero para tu empresa, que reproduce tus procesos tal y como son.
• Software modular: una base común sobre la que activas solo los módulos que necesitas y adaptas los que te diferencian.

La idea modular no es una moda reciente. Eurostat describe el ERP como un software que se entrega en «módulos» que integran planificación, compras, marketing, ventas, relación con clientes, finanzas y recursos humanos, y lo cita como una de las formas habituales de integrar la información interna de una empresa.

Tabla comparativa

El riesgo del software a medida: el proyecto que nunca termina

Un desarrollo a medida te da exactamente lo que pides, siempre que sepas pedirlo y el proyecto llegue a buen puerto. Lo segundo es menos frecuente de lo que se cree.

Un análisis de McKinsey con la Universidad de Oxford sobre más de 5.400 proyectos de TI concluyó que los grandes proyectos, con un presupuesto inicial superior a 15 millones de dólares, superaban de media su presupuesto en un 45 % y su plazo en un 7 %, y entregaban un 56 % menos de valor del previsto. Es un estudio de 2012 y de proyectos grandes, pero el patrón se reconoce a cualquier escala: cuanto más hay que construir, más cosas pueden torcerse.

Hay un segundo coste menos visible: el mantenimiento. El software a medida envejece. Cada cambio legal, cada integración nueva y cada actualización de seguridad es trabajo adicional, y suele depender del mismo equipo que lo construyó.

El riesgo del estándar: ¿adaptas el software o adaptas la empresa?

El software estándar es rápido y está probado, pero tiene una regla no escrita: si lo quieres usar tal cual, tus procesos tienen que parecerse a los suyos. Cuando no es así empiezan las adaptaciones, y con ellas los problemas.

El caso más citado en Europa es el de Lidl. La cadena trabajó desde 2011 en eLWIS, un sistema de gestión de mercancías basado en SAP, y lo paró en julio de 2018. La prensa especializada alemana, citando a observadores del sector, estimó el gasto en unos 500 millones de euros; Lidl no lo confirmó.

Según Consultancy.uk, uno de los choques era de fondo: Lidl valoraba su inventario a precio de compra, mientras que el software estándar de SAP para distribución trabajaba con precios de venta. Lidl no quiso cambiar su forma de trabajar, así que se adaptó el software. Con esa y otras adaptaciones, el rendimiento bajó y los costes subieron.

La frase que mejor lo resume la dijo entonces Jean-Claude Flury, al frente del grupo de usuarios de SAP DSAG: «If a company wants to use the standard software, it has to adapt its own processes». Es decir, si una empresa quiere usar el software estándar, tiene que adaptar sus propios procesos.

Modular: el punto medio, con condiciones

El enfoque modular intenta quedarse con lo mejor de ambos mundos: una base estándar que no hay que reinventar y capacidad para adaptar lo que te hace distinto. Pero no todo lo que se vende como modular lo es de verdad. Comprueba cuatro cosas:

1. Una sola base de datos. Si cada módulo guarda sus datos por separado, solo has comprado varios programas con el mismo logotipo.
2. Adaptaciones que sobreviven a las actualizaciones. Pregunta qué pasa con tus cambios cuando el proveedor publica una versión nueva.
3. Módulos que se activan sin migrar. Crecer debería ser encender algo, no mudarse.
4. Una salida clara. Formatos de exportación y plazos, por escrito.

Es el planteamiento de la solución de NTLABS: un ERP modular construido sin código en el que cada empresa elige sus módulos, los requisitos específicos se implementan en días o incluso horas, y se pueden activar módulos nuevos o rediseñar procesos sin migrar a otra plataforma. Sobre esa base existen versiones por sector, como ObraSuite para constructoras.

Lo que cambia el 12 de enero de 2027

El Reglamento europeo de Datos (Reglamento (UE) 2023/2854), aplicable desde el 12 de septiembre de 2025, regula cómo cambiar de proveedor de servicios de tratamiento de datos, una categoría que incluye los servicios en la nube. A fecha de noviembre de 2026, estos son los puntos que más afectan a quien elige software de gestión:

• Cambiar de proveedor sin coste por el cambio. Desde el 12 de enero de 2027, el proveedor no podrá cobrarte costes por el proceso de cambio (artículo 29). Hasta esa fecha solo puede repercutir costes reducidos, que no superen lo que le cuesta directamente el cambio.
• Plazos fijados en el contrato. El contrato debe incluir un preaviso máximo de dos meses, un periodo transitorio de hasta 30 días naturales y al menos 30 días para extraer tus datos (artículo 25).
• Información antes de firmar. El proveedor debe explicarte los costes estándar y las penalizaciones por resolución anticipada.

El detalle que casi nadie menciona está en el artículo 31: la eliminación de los costes por cambio no se aplica a los servicios cuyas características principales se han desarrollado a medida para un cliente concreto y que no se ofrecen a gran escala en el catálogo del proveedor. Traducido: cuanto más a medida es tu software en la nube, menos te cubre esta protección. Pregunta por la salida antes de entrar.

Cómo elegir: cinco preguntas

1. ¿Este proceso me diferencia o es igual en todas las empresas? La contabilidad se parece mucho entre empresas; la forma en que planificas tus proyectos o tus rutas, quizá no.
2. ¿Cuánto cambiarán mis procesos en los próximos tres años? Si la respuesta es «mucho», necesitas algo que se adapte rápido.
3. ¿Quién mantendrá el sistema cuando el proyecto termine? Pon un nombre, no un «ya veremos».
4. ¿Qué pasa con mis datos si quiero irme? Pide formatos, plazos y costes por escrito.
5. ¿Puedo empezar por una parte y crecer por fases? Los saltos pequeños se corrigen mejor que los grandes.

Una regla práctica para cerrar: estándar para lo que es igual en todas partes, adaptación para lo que te hace distinto y desarrollo a medida solo cuando no exista nada que se acerque a lo que necesitas.