Vendor lock-in: el odio no aparece en la factura

Hay dos formas de retener a un cliente: que quiera quedarse o que no pueda irse. El vendor lock-in es la segunda, y el software libre existe, en buena parte, para desmontarla.

Vendor lock-in: el odio no aparece en la factura

Vendor lock-in: la frase que se atribuye a un fundador de SAP

En 2011, Hasso Plattner, cofundador de SAP, cerró la conferencia anual de la compañía ante miles de sus propios clientes. El documental del canal fatdev sobre la historia de SAP le atribuye esta declaración: puedes odiar el producto todo lo que quieras, porque un cliente que lo odia y no puede irse seguirá pagando cada año. Y el odio, añade, no aparece en la factura.

La cita circula sin fuente primaria verificable, así que tómala como se cuenta, no como acta notarial. Pero se cuenta por algo: describe con precisión el vendor lock-in o bloqueo de proveedor, la situación en la que tu empresa depende tanto de un sistema que la pregunta “¿seguimos con él?” deja de plantearse. No porque funcione bien, sino porque salir cuesta más que quedarse.

Fidelidad o cautividad: dos maneras de retenerte

Un cliente puede seguir veinte años en tu sistema por dos motivos muy distintos. La fidelidad: se queda porque le funciona, porque actualizar no duele y porque el soporte responde. O la cautividad: se queda porque su forma de trabajar está escrita con la forma del software, porque sus datos viven en formatos que solo ese producto entiende y porque la alternativa es parar el negocio para “demoler la ciudad” y rehacerla.

El vendor lock-in no es un accidente técnico. Es un modelo de negocio: la cautividad también factura, y muchas veces factura más que la fidelidad.

Las salidas que lo intentaron (y lo que costaron)

Si el bloqueo fuera una exageración de los defensores del software libre, habría empresas que lo hubieran roto sin drama. La prensa recogió justo lo contrario.

Hershey, 1999. La fabricante de chocolate encendió a la vez tres sistemas (SAP, Manugistics y Siebel) en un calendario comprimido, justo antes de Halloween y Navidad, su temporada crítica. El resultado fueron unos 100 millones de dólares en pedidos que no consiguió servir teniendo el producto en el almacén. Siguió con el sistema.

Lidl, 2011-2018. Siete años de proyecto para sustituir su gestión de mercancías (eLWIS, sobre SAP), unos 500 millones de euros según Computer Weekly, y en julio de 2018 cancelación y vuelta al sistema antiguo que quería jubilar. El motivo profundo: la empresa quiso adaptar el software a su forma de trabajar y cada concesión encareció el proyecto hasta el final.

National Grid, 2012. La eléctrica del noreste de Estados Unidos puso en marcha su nuevo SAP y lo primero que se rompió fueron las nóminas. Dos meses después del estreno acumulaba más de 15.000 facturas de proveedores sin pagar y su cierre financiero mensual pasó de 4 días a 43, según la demanda que presentó contra su integradora, Wipro. Una auditoría de 2014 estimó el coste total en cerca de 1.000 millones de dólares y, siendo honestos, también reprochó a la propia eléctrica presentarse “sin preparación”. El asunto acabó en 2018 con un acuerdo de 75 millones. ¿Y el sistema? Siguió en marcha.

Tres sectores, tres décadas, un patrón: el desastre no abrió la puerta de la jaula. Ni siquiera un desastre de mil millones.

De qué está hecha la jaula

El bloqueo de proveedor se sostiene en cuatro barrotes que se refuerzan entre sí:

  • Licencias por usuario y módulo: pagas por existir en el sistema, no por el valor que recibes. La factura crece con la plantilla, quieras o no.
  • Código cerrado: solo el fabricante puede arreglarlo o extenderlo. Si tu problema no está en su hoja de ruta, tu problema no existe.
  • Datos en formatos propietarios: extraer tu propia información cuesta dinero, tiempo y a menudo un proyecto de consultoría.
  • Ecosistema que factura la complejidad: cuanto más enrevesado el despliegue, más horas facturadas. El efecto 2000 llenó de este negocio a las grandes consultoras durante años.

Cada barrote, por separado, se puede justificar como “cómo funciona el sector”. Juntos construyen un coste de salida que ninguna empresa quiere pagar dos veces.

Por qué el código abierto cambia la ecuación

Un ERP de código abierto como Odoo Community desmonta los barrotes uno a uno. La licencia LGPLv3 no tiene coste por usuario. El código está disponible: si algo no te gusta, cualquier implantador con la capacidad puede arreglarlo o extenderlo, no solo el fabricante. Los datos viven en PostgreSQL, una base estándar que no pertenece a nadie, y puedes exportarlos o copiarlos cuando quieras. Y hay mercado: decenas de empresas implantan Odoo en España, así que cambiar de proveedor no implica cambiar de sistema.

En la consultora donde trabajo llevamos años recibiendo empresas “secuestradas” por su sistema anterior: programas a medida que ya nadie mantiene, ERPs cuyo fabricante desapareció o los abandonó, datos inextraíbles. Buena parte de nuestro trabajo es literalmente liberarlos: sacar sus datos, migrarlos a una herramienta abierta y devolverles la llave. Con un ERP propietario esa llave no existe; con uno libre, sí. Y que el cliente liberado también pueda dejarnos a nosotros no es un riesgo: es justo lo que nos obliga a que las cosas funcionen.

No es un caso teórico ni nuevo: ya contamos en este blog cómo Danone reemplazó SAP por OpenERP (el nombre anterior de Odoo) en Argentina, Colombia y Australia.

Lo que el software libre no arregla

La jaula también se la construye uno. Eric Kimberling, de la consultora Third Stage Consulting, que trabaja como perito cuando estos proyectos acaban en los tribunales, lo resumió en una entrevista: el desastre no sale del software, sale de una reunión, la de alguien que dice “es que nosotros lo hacemos así de toda la vida” y consigue que el sistema se retuerza para parecérselo. Cada personalización de esas se convierte en una pieza que nadie se atreve a tocar cuando toca actualizar.

El código abierto te da la llave de la puerta. No te quita la reunión, ni te limpia los datos maestros, ni elige por ti el calendario de puesta en marcha. Una implantación libre fracasa igual que una propietaria si esos frentes se descuidan. La diferencia es a quién sirven los incentivos del modelo: en uno, retener al cliente aunque lo odie es negocio; en el otro, la única retención posible es que funcione.

Siguiente paso

Si estás evaluando ERP, antes de comparar funcionalidades pregúntate cuánto costaría irte. Hemos detallado cómo evitar el bloqueo de proveedor con Odoo Community y por qué el ERP es tuyo cuando el código es abierto. Y si quieres ver el panorama completo, tienes la comparativa de otros ERPs libres y cuál conviene. Tus datos y tu forma de trabajar son de tu empresa; el sistema que los gestione debería devolverte esa libertad en lugar de cobrarte por ella.