¿Cómo acabó Lidl gastando 500 millones en un proyecto SAP fallido?

Lidl emprendió en 2011 uno de los mayores proyectos tecnológicos de su historia: sustituir buena parte de su sistema interno de gestión de mercancías por una plataforma basada en SAP. Siete años después, en 2018, la cadena alemana decidió abandonarlo. La factura atribuida al proyecto rondó los 500 millones de euros, según las estimaciones publicadas entonces por medios especializados y observadores del sector; Lidl no hizo pública una cifra oficial detallada.

Ese es el núcleo del caso que ha vuelto a circular en septiembre de 2026: no se trata de un fracaso ocurrido recientemente, sino de una historia empresarial desarrollada entre 2011 y 2018 y recuperada como ejemplo de lo que puede suceder cuando una gigantesca transformación informática choca con la manera real de funcionar de una compañía. Y hubo un detalle aparentemente pequeño que terminó resultando enorme: Lidl gestionaba aspectos esenciales de sus existencias tomando como referencia el precio de compra, mientras la solución estándar que pretendía implantar respondía a una lógica distinta vinculada al precio de venta.

El proyecto con el que Lidl quería cambiar su informática

La iniciativa se llamaba eLWIS, abreviatura de elektronisches Lidl Warenwirtschaftsinformationssystem. Había nacido para suceder a Wawi, el sistema de gestión desarrollado internamente que Lidl llevaba años utilizando y que empezaba a mostrar sus costuras: datos redundantes, procesos poco integrados, limitaciones funcionales y una infraestructura que resultaba cada vez más complicada de escalar.

La apuesta tenía lógica. Lidl crecía internacionalmente y necesitaba que compras, existencias, logística, tiendas y análisis de datos hablasen un idioma más común. SAP ofrecía precisamente eso: un ERP, es decir, una plataforma capaz de conectar diferentes áreas de una empresa dentro de un mismo ecosistema de gestión.

La base tecnológica escogida fue SAP for Retail sobre SAP HANA. Cuando el despliegue internacional estaba en marcha, Lidl explicaba que buscaba dejar atrás un modelo formado por funciones aisladas para trabajar con cadenas de procesos integradas desde el proveedor hasta el cliente. También pretendía reducir el mantenimiento de datos duplicados y disponer de indicadores y existencias prácticamente en tiempo real.

No era, por tanto, comprar un programa y pulsar «instalar». Había que tocar el sistema nervioso de una compañía con miles de supermercados, centros logísticos y procesos conectados. En informática empresarial, cambiar el ERP se parece bastante a sustituir las tuberías de un edificio mientras todos siguen duchándose, cocinando y abriendo los grifos.

El problema del precio de compra y el precio de venta

Ahí apareció la grieta que acabaría atravesándolo todo. Uno de los elementos más citados en los análisis posteriores fue la valoración y gestión de las mercancías. Lidl había construido parte de sus procedimientos alrededor de precios de compra, mientras el modelo estándar de SAP Retail respondía a una lógica basada en precios de venta.

Para quien mira el asunto desde fuera puede parecer una casilla de configuración: cambiar una columna por otra y asunto arreglado. No funciona así.

El precio alrededor del que se estructura un sistema de mercancías puede repercutir en compras, inventarios, márgenes, informes y controles internos, además de afectar a multitud de procesos que consumen esos datos. Al modificar la lógica central aparecen dependencias. Después aparecen excepciones. Luego interfaces que también necesitan cambios. Y después, claro, alguien descubre una excepción de la excepción.

Lidl tenía básicamente dos caminos: alterar determinados procesos internos para acercarlos al funcionamiento estándar del software o personalizar SAP para conservar su propia manera de trabajar. La compañía avanzó por esa segunda vía en buena parte del proyecto. Cuanto más se modificaba la plataforma, más se alejaba de las ventajas que precisamente justifican comprar un programa estándar.

Cuando personalizar el software deja de ser una ventaja

Un ERP comercial tiene una promesa implícita: una enorme cantidad de problemas comunes ya están resueltos. La empresa adapta ciertos procedimientos, configura el producto y evita tener que construir cada pieza desde cero.

Pero existe un punto en que la personalización rompe esa ecuación. Si una compañía modifica cientos de procesos para conseguir que el software nuevo reproduzca exactamente el comportamiento del sistema antiguo, empieza a pagar las dos facturas: la complejidad de la nueva plataforma y la singularidad de la vieja.

Eso es lo que hizo especialmente incómodo el caso Lidl. No había una pequeña empresa improvisando una digitalización a última hora. SAP era uno de los grandes nombres mundiales del software empresarial. Lidl disponía de recursos, personal especializado y consultores. Y el proyecto llegó a funcionar en determinados mercados.

El sistema fue introducido inicialmente en Austria y posteriormente estuvo operativo también en Irlanda del Norte y Estados Unidos, mientras se trabajaba en un despliegue mucho más amplio. En paralelo, Lidl llegó a conectar más de 30 sistemas de su infraestructura existente con eLWIS. Es decir, aquello no era una maqueta olvidada en un ordenador: había una transformación bastante avanzada detrás.

De una promesa de tiempo real a siete años de trabajo

La ambición tecnológica era considerable. Lidl llegó a explicar que algunos indicadores operativos de las tiendas que antes requerían unas 24 horas podían analizarse varias veces durante el día gracias a la nueva infraestructura basada en HANA. La digitalización parecía estar haciendo exactamente lo que debía hacer.

Pero una implantación local que funciona no garantiza que pueda extenderse sin problemas a toda una organización internacional. A medida que el proyecto crecía, también lo hacían sus personalizaciones, integraciones y costes.

En julio de 2018 llegó el frenazo. Lidl comunicó internamente que los objetivos estratégicos originalmente definidos no podían alcanzarse con un esfuerzo razonable y decidió detener eLWIS. La compañía optó por continuar desarrollando su antiguo sistema Wawi. Al mismo tiempo quiso dejar claro que aquello no significaba romper con SAP: mantenía otras soluciones del fabricante en diferentes áreas.

Los 500 millones: una cifra enorme que conviene contar bien

La cantidad que ha convertido el episodio en leyenda empresarial es unos 500 millones de euros. La cifra fue publicada en 2018 a partir de estimaciones de observadores del sector y posteriormente ha sido repetida en multitud de análisis sobre proyectos ERP. No debe presentarse como una auditoría oficial de pérdidas reconocida públicamente por Lidl porque la compañía no detalló cuánto había gastado exactamente.

Hay, además, una curiosidad lingüística importante en la historia que ha vuelto a circular en 2026. Hablar de «medio billón de euros» para referirse a 500 millones es incorrecto en el español habitual de España. En nuestra escala numérica, un billón equivale a un millón de millones, es decir, 10¹². Medio billón serían 500.000 millones de euros, mil veces más que la cantidad atribuida al proyecto de Lidl.

Aquí hubo unos 500 millones, que tampoco es precisamente calderilla. Pero el cero, cuando se multiplica por mil, adquiere cierta importancia.

¿Fue un fracaso de Lidl o de SAP?

Reducir el episodio a «SAP no funcionó» sería demasiado fácil. También sería poco preciso.

La propia Lidl señaló cuando canceló eLWIS que su decisión no era contra SAP, sino a favor de continuar desarrollando un sistema propio. Algunas soluciones SAP siguieron formando parte de su infraestructura. El choque estaba concentrado en aquel gigantesco proyecto de gestión de mercancías y en la dificultad de reconciliar una plataforma estándar con procesos empresariales profundamente arraigados.

Tampoco parece razonable colocar toda la responsabilidad al otro lado y concluir que Lidl simplemente se negó a modernizarse. Las empresas no conservan durante décadas determinados procedimientos por romanticismo informático. Algunos pueden ser ineficientes; otros contienen conocimientos acumulados que les permiten operar de una forma que consideran competitiva.

Ahí está lo incómodo —y útil— del caso. Digitalizar no significa automáticamente estandarizar, y estandarizar tampoco significa automáticamente mejorar. El conflicto aparece cuando nadie decide con suficiente claridad qué debe conservarse y qué debe sacrificarse antes de que empiecen a acumularse años de desarrollo, consultores, interfaces y dinero.

El viejo sistema terminó ganando la batalla

Tras siete años de trabajo, Lidl volvió a apoyarse en Wawi y optó por evolucionar una herramienta que, al comenzar el proyecto, precisamente consideraba próxima a sus límites. Es quizá la paradoja más llamativa de todo el episodio: después de intentar sustituir el sistema heredado mediante una de las plataformas empresariales más potentes del mercado, la compañía terminó decidiendo que modernizar lo que ya tenía ofrecía una relación entre coste y beneficio más razonable.

La historia sigue circulando ocho años después porque no depende realmente de Lidl ni de SAP. Podría ocurrir —y ocurre— en bancos, administraciones, hospitales, aerolíneas o grandes industrias. El software empresarial rara vez fracasa porque un botón tenga el color equivocado. Los problemas aparecen cuando la tecnología obliga a traducir décadas de funcionamiento cotidiano a reglas informáticas y alguien descubre demasiado tarde que cada empresa guarda, detrás de procesos aparentemente banales, una pequeña selva de excepciones.

La pequeña decisión que terminó pesando millones

Los 500 millones de euros atribuidos a eLWIS son la parte espectacular. La parte verdaderamente interesante es bastante menos fotogénica: una diferencia en la forma de tratar las mercancías, personalizaciones que fueron creciendo y siete años intentando encajar dos lógicas distintas. En los grandes proyectos informáticos, a veces el agujero más caro empieza siendo apenas una casilla.