Esta historia combina hechos reales, ampliamente documentados en litigios públicos del sector ERP, con elementos completamente inventados para darle cuerpo narrativo: nombres de empresas, personajes, diálogos, escenas y detalles concretos de esta historia son ficticios. Cualquier similitud con personas, empresas o situaciones reales más allá de los hechos públicamente conocidos es pura coincidencia. Ni el nombre de la empresa cervecera ni el de la consultora aquí utilizados corresponden a los reales, y ningún diálogo reproducido aquí ocurrió tal cual se describe.
Me llamo Lucía y en 1999 tenía veintiocho años, un contrato de consultora junior de SD recién firmado y ninguna idea de lo que significaba la palabra “cutover”. Lo aprendí en una fábrica de chocolate de Pensilvania, rodeada de cajas de bombones que nadie podía enviar.
La empresa la llamaremos Bellmont. Una de esas marcas que forman parte del paisaje de un país. Chocolatinas en cada gasolinera, en cada caja de supermercado, en cada bolsa de caramelos que los niños llevan colgando en Halloween. Más de cien años de historia, fábricas que olían a cacao a dos kilómetros de distancia y una forma de trabajar que, hasta entonces, había funcionado sin necesidad de cambiar casi nada.
Pero estábamos en los noventa y se acercaba el año 2000. Y el año 2000 traía consigo un fantasma que asustaba a todos los consejos de dirección del planeta. El efecto 2000. La posibilidad de que los sistemas antiguos, programados con años de dos dígitos, interpretaran el 1 de enero de 2000 como el 1 de enero de 1900 y se volvieran locos. Nadie sabía muy bien qué iba a pasar. Y cuando nadie sabe qué va a pasar, todo el mundo quiere tener la solución instalada antes.
Bellmont decidió en 1996 renovarlo todo. SAP R/3 para el núcleo, un sistema de planificación de la cadena de suministro de otro fabricante y un CRM de un tercero para la gestión de clientes. Tres sistemas nuevos, conectados entre sí, sustituyendo de golpe décadas de aplicaciones heredadas. Un proyecto de más de cien millones de dólares.
Los que sabían de esto recomendaron cuatro años. Cuarenta y ocho meses para hacerlo bien, con fases, con pilotos, con tiempo para probar y corregir.
Bellmont decidió que no había cuatro años. Había un efecto 2000 esperando en el calendario.
Yo llegué al proyecto en enero de 1999, enviada por la consultora en la que trabajaba como refuerzo para el equipo de ventas y distribución. Me asignaron a Tom, un consultor americano de SD con más canas que paciencia, que en mi primer día me llevó a la ventana de la sala del proyecto y me señaló el aparcamiento de camiones de la planta.
—¿Ves esos camiones? —me dijo—. En septiembre salen trescientos al día. Tres veces más que ahora. Todo lo que hagamos aquí tiene que estar listo antes de que empiecen a salir.
Tardé semanas en entender lo que me estaba diciendo. En Bellmont, Halloween no era una fiesta. Era la temporada. Las tiendas encargaban las chocolatinas para sus expositores de octubre con meses de antelación, y los pedidos empezaban a entrar con fuerza a finales del verano. Luego venía Navidad. Un fabricante de dulces podía hacer una parte enorme de su año en esa ventana de pocas semanas. Y lo que no vendías antes del 31 de octubre no lo vendías después, porque nadie compra calabazas de chocolate el 2 de noviembre.
El plan inicial había sido arrancar en abril, con los almacenes tranquilos. Pero en primavera el proyecto ya iba con retraso. Las pruebas integradas, las que comprueban que los tres sistemas se hablan bien entre ellos con datos de verdad, se estaban comiendo semanas que no existían. Cada vez que encontrábamos algo, había que corregirlo en un sistema, retransportar, volver a probar en los otros dos.
Recuerdo una reunión en mayo en la que Mike, el jefe de proyecto por parte del cliente, presentó el nuevo calendario. Arranque en julio. Todos los módulos a la vez. Big bang.
Tom levantó la mano.
—Julio es tres semanas antes de que empiecen a entrar los pedidos de Halloween. Si algo va mal, no tenemos margen.
Mike le contestó algo que con los años he oído en muchas otras salas, con distintas palabras pero el mismo fondo.
—Si no arrancamos en julio, no arrancamos este año. Y si no arrancamos este año, nos come el 2000. Las pruebas que quedan las haremos con el sistema ya en marcha.
Nadie votó en contra. No porque todos estuvieran de acuerdo, sino porque nadie tenía una alternativa mejor que ofrecer en esa sala. Y así fue como unas cuantas fases de prueba pasaron del plan del proyecto a la categoría de “lo haremos sobre la marcha”.
La formación de los usuarios también se recortó. Los responsables de almacén, los de atención al cliente, los que llevaban veinte años haciendo su trabajo en pantallas verdes, recibieron unos días de curso sobre un sistema que cambiaba por completo su forma de trabajar. Recuerdo a Dolores, una supervisora de almacén de origen mexicano con quien hice buenas migas porque era la única persona del edificio con la que podía hablar en español, saliendo de una de esas sesiones con una carpeta llena de fotocopias.
—Mija, yo sé dónde está cada palé de esta nave con los ojos cerrados —me dijo—. Ahora resulta que lo tiene que saber la computadora.
En ese momento me pareció una frase graciosa. Tres meses después me pareció una profecía.
El arranque fue un fin de semana de julio. Migración de datos, carga de stocks, activación de interfaces. La sala del proyecto llena de pizza fría, café de máquina y gente que no había dormido. El lunes por la mañana el sistema estaba vivo. Los usuarios entraban. Los pedidos se grababan. Mike mandó un correo a toda la empresa felicitando al equipo. Alguien trajo una tarta con el logo de SAP hecho de glaseado.
Las primeras semanas fueron lo que todos esperábamos. Problemas, incidencias, usuarios perdidos, pero con volúmenes de verano, manejables. Se resolvían a base de horas. A mediados de agosto empezaron a entrar los pedidos de la campaña.
Y ahí fue cuando el sistema empezó a enseñar lo que no habíamos probado.
Los pedidos entraban por el CRM, pasaban a SAP y desde ahí tenían que convertirse en entregas, salir al almacén, cargarse en un camión. Pero no salían. Se quedaban atascados en algún punto entre un sistema y otro. Algunos llegaban a SAP incompletos. Otros llegaban duplicados. Otros simplemente no llegaban, y nadie sabía en qué parte del recorrido se habían perdido.
Y luego estaba el almacén.
Durante la migración, los datos de stock se habían cargado. Pero las ubicaciones, dónde estaba exactamente cada palé de cada producto dentro de cada nave, no se habían cargado con la precisión que el nuevo sistema necesitaba. El sistema creía que algunos productos estaban en un sitio y estaban en otro. Creía que había stock donde no lo había, y no lo veía donde sí estaba. Cuando el sistema no encontraba el producto, no generaba la entrega. Y si no había entrega, el camión no salía.
Recuerdo una tarde de septiembre en la nave principal con Dolores. Me llevó por un pasillo de estanterías hasta el techo, llenas de cajas de chocolatinas con envoltorios naranjas y negros, calabazas, murciélagos, fantasmas sonrientes.
—Aquí hay producto para diez tiendas —me dijo—. Y la computadora dice que no hay nada.
Abrí el portátil allí mismo, sentada en un palé. Ella tenía razón. Para SAP, ese pasillo estaba vacío.
Ese fue el mes más absurdo de mi vida profesional. Una de las mayores fábricas de chocolate del mundo, con los almacenes llenos hasta el techo, sin poder enviar chocolate. Los clientes llamaban preguntando por sus pedidos. Las cadenas de supermercados necesitaban sus expositores de Halloween montados en las tiendas a principios de octubre. Los de atención al cliente, con apenas unos días de formación, intentaban contestar a preguntas sobre pedidos que no sabían encontrar en una pantalla que no entendían.
Montamos turnos de día y de noche. Revisábamos pedidos a mano, uno a uno, intentando averiguar dónde se habían quedado. Los equipos de almacén hacían recuentos físicos para corregir las ubicaciones en el sistema, pasillo a pasillo, mientras los pedidos seguían entrando por la puerta de delante. Era como intentar achicar agua de un barco con un vaso mientras el barco seguía navegando hacia la tormenta.
Hubo pedidos que salieron a medias. Pedidos que salieron con el producto equivocado. Pedidos que salieron dos veces. Y muchos, demasiados, que no salieron nunca.
Las cadenas de distribución no esperaron. No podían. Si Bellmont no les servía las chocolatinas para Halloween, el espacio en el expositor se lo daban a la competencia. Y los competidores, que estaban encantados, lo ocuparon sin pensárselo dos veces.
A mediados de septiembre, el presidente de Bellmont tuvo que dar la cara ante los analistas financieros. Recuerdo ver la noticia en la pequeña televisión de la sala de descanso. Dijo que había problemas con el nuevo sistema de pedidos y distribución. No dio detalles técnicos. Dio una cifra. Unos cien millones de dólares en pedidos que no iban a poder servir a tiempo para Halloween.
La acción cayó un ocho por ciento ese día.
Tom, a mi lado, apagó la tele sin decir nada. Luego se levantó, cogió su taza de café y volvió a la sala del proyecto. Yo le seguí. No había mucho más que hacer.
Halloween de 1999 llegó, como llega siempre, el 31 de octubre. Los niños salieron a pedir caramelos. Las bolsas se llenaron de chocolatinas, muchas de ellas de otras marcas. En los almacenes de Bellmont seguían quedando cajas con envoltorios naranjas y negros que ya no valían para nada. Recuerdo a Dolores, el 2 de noviembre, mirando aquellas calabazas de chocolate apiladas.
—El año que viene les cambiamos el papel y las vendemos para Navidad —dijo, con una media sonrisa que no le llegaba a los ojos.
El sistema se estabilizó en los meses siguientes. Poco a poco. Con muchas correcciones, mucha limpieza de datos, muchas horas de gente que nunca salió en ninguna noticia. Los resultados de ese trimestre fueron malos. Muy malos. Hubo cambios en la dirección. Hubo informes, auditorías, reuniones en las que todo el mundo buscaba explicaciones.
Lo curioso es que el software no estaba roto. SAP hacía lo que se le había configurado que hiciera. El sistema de planificación hacía lo que tenía que hacer. El CRM también. Años después, la misma empresa siguió trabajando con SAP sin mayores sobresaltos. El problema nunca fueron los programas. El problema fue arrancar los tres a la vez, sin terminar de probar cómo se hablaban entre ellos, con datos de almacén que no se habían comprobado del todo, con usuarios que apenas habían aprendido a usarlos, tres semanas antes de la época más importante del año.
Tom se jubiló poco después. La última vez que hablé con él, ya con el proyecto estabilizado, le pregunté si alguien podría haber evitado todo aquello.
—Todo el mundo sabía que era mala idea —me dijo—. Lo sabía yo, lo sabía Mike, lo sabían los de arriba. Pero el miedo al año 2000 era más grande que el miedo a Halloween. Y al final el que nos mordió fue Halloween.
El año 2000, por cierto, llegó sin que pasara casi nada en ningún sitio.
Sigo trabajando en SAP. Han pasado muchos años y muchos proyectos. Y cada vez que en una reunión alguien propone un arranque justo antes de una campaña, con las pruebas a medias, “porque no hay otra fecha”, me acuerdo de aquel pasillo lleno de calabazas de chocolate que, para el sistema, no existían.
MORALEJA
La fecha de arranque es una decisión de negocio, no de calendario. Arrancar justo antes de tu campaña más fuerte es apostar todo el año a que nada falle.
Las pruebas que se recortan no desaparecen. Se hacen igual, pero en producción, con clientes reales esperando.
El dato de stock no basta si el sistema no sabe dónde está. Una migración sin ubicaciones fiables convierte un almacén lleno en uno vacío.
Big bang es otra forma de decir que si algo falla, falla todo a la vez.
El miedo a un riesgo no puede hacerte ignorar otro. A veces el fantasma del que huyes no es el que termina mordiendo.
Nota del autor: Esta historia está basada en hechos reales ampliamente documentados sobre la implantación ERP de un gran fabricante de chocolate en 1999, pero combina esos hechos con elementos de ficción para dar cuerpo a la narración. Los nombres de personas y empresas, los diálogos y muchos de los detalles concretos son inventados. Cualquier similitud con personas, empresas o situaciones reales más allá de los hechos públicamente conocidos es pura coincidencia.
¿Te ha gustado esta historia?
¿Quieres enviar la tuya (real o ficticia)?
Envíame un correo a [email protected]

