Hay una escena que he visto repetirse muchas veces.
El proyecto lleva meses de retraso.
El presupuesto aumentó.
Los equipos están agotados.
Los proveedores aseguran que falta muy poco.
La alta dirección ya anunció la fecha.
Los clientes fueron informados.
El mercado espera el lanzamiento.
Y alguien hace una pregunta incómoda.
”¿Estamos realmente listos?”
Normalmente la respuesta no depende únicamente de la realidad.
Depende del costo político de volver a aplazar el proyecto.
Y ahí aparece una de las decisiones más difíciles de cualquier transformación digital.
Porque retrasar un lanzamiento duele.
Pero lanzar un sistema antes de tiempo puede terminar costando mucho más.
El caso de Revlon demuestra exactamente eso.
No es una historia sobre un software malo.
Es una historia sobre una organización que tenía una visión correcta, pero que terminó descubriendo que una fecha de salida nunca puede ser más importante que la capacidad de operar el negocio al día siguiente.
Una transformación necesaria
Después de adquirir Elizabeth Arden en 2016, Revlon enfrentaba un problema común en muchas compañías que crecen mediante adquisiciones.
Demasiados sistemas.
Demasiados procesos.
Demasiadas formas distintas de operar.
La empresa utilizaba decenas de plataformas ERP en diferentes negocios y necesitaba consolidarlas para ganar eficiencia y tener una operación integrada. Por eso decidió avanzar hacia una implementación corporativa de SAP S/4HANA.
La decisión estratégica era difícil de cuestionar.
Unificar procesos.
Reducir complejidad.
Mejorar la información.
Escalar operaciones.
Todo sonaba razonable.
El problema nunca fue la visión.
Fue la ejecución.
Las pruebas ya estaban mostrando problemas
Según documentos judiciales posteriores, durante la preparación del proyecto aparecieron dificultades importantes en la planta de Oxford, la mayor instalación de manufactura de Revlon.
Los problemas fueron suficientemente relevantes como para que el despliegue completo se aplazara cuatro veces.
La organización evaluó volver a retrasarlo.
Finalmente decidió continuar.
Este punto me parece fascinante.
Porque no estamos hablando de una falla que apareció de manera completamente inesperada.
Existían señales.
Existían riesgos conocidos.
Y aun así el proyecto siguió adelante.
No conocemos todas las discusiones internas.
Pero sí conocemos una realidad que se repite en muchas organizaciones.
Cada aplazamiento hace más difícil aprobar el siguiente.
El costo de llegar a tiempo
SAP entró en operación en febrero de 2018.
Muy pronto comenzaron los problemas.
La planta perdió capacidad para fabricar ciertos productos.
Se retrasaron despachos.
Grandes clientes minoristas dejaron de recibir mercancía.
Revlon tuvo que recurrir a envíos urgentes y acciones extraordinarias para recuperar el nivel de servicio.
En su informe anual, la propia compañía cuantificó parte del impacto:
aproximadamente US$64 millones en ventas que no pudo despachar durante 2018;
US$53,6 millones en costos extraordinarios para mitigar la caída del servicio;
y una debilidad material en los controles internos asociada con la implementación del ERP.
No fueron solamente problemas tecnológicos.
El sistema afectó la operación.
La operación afectó el servicio.
Y el servicio terminó afectando el negocio.
La obsesión por el “go-live”
Creo que muchas empresas siguen midiendo las transformaciones con el indicador equivocado.
Celebran el día en que el sistema entra en producción.
Pero el cliente nunca celebra un go-live.
Solo nota si recibe o no su pedido.
Si la factura llega correctamente.
Si la aplicación funciona.
Si el producto está disponible.
El verdadero lanzamiento ocurre cuando el cliente continúa su vida sin sentir que la empresa acaba de cambiar el corazón de su operación.
Todo lo demás es un hito interno.
El costo hundido también transforma decisiones
Hay otro aprendizaje que me parece todavía más importante.
Cuanto más tiempo lleva un proyecto, más difícil resulta detenerlo o retrasarlo.
Los economistas llaman a esto la falacia del costo hundido.
Ya invertimos demasiado.
Ya contratamos demasiada gente.
Ya comunicamos la fecha.
Ya no podemos devolvernos.
Y, sin darnos cuenta, dejamos de decidir mirando el futuro.
Empezamos a decidir mirando el pasado.
Las inversiones realizadas empiezan a justificar inversiones adicionales.
No porque aumenten la probabilidad de éxito.
Sino porque aceptar la pérdida parece emocionalmente más difícil.
En transformación digital, esa lógica puede ser devastadora.
La tecnología no entiende de calendarios
Hay algo que la tecnología nunca negocia.
No le importa la presión política.
No le importa el cierre del trimestre.
No le importa la presentación a la junta.
No le importa que la campaña comercial ya comenzó.
El sistema está listo.
O no lo está.
Las organizaciones, en cambio, sí sienten esas presiones.
Y muchas veces terminan adaptando la decisión técnica a la necesidad del calendario.
El problema es que los clientes nunca pagan por nuestros cronogramas.
Pagan por recibir un buen servicio.
Lo que este caso significa para otras industrias
Este patrón aparece constantemente.
Un banco cambia su core antes del cierre fiscal porque el contrato vence.
Una aseguradora lanza una nueva plataforma antes del periodo de renovación.
Una universidad cambia el sistema académico justo antes del inicio de clases.
Un retailer implementa un ERP semanas antes de la temporada navideña.
Un hospital migra sistemas sin haber entrenado completamente a sus equipos.
En todos esos casos la conversación suele ser la misma.
“No podemos seguir retrasándolo.”
Quizá la pregunta correcta sea otra.
”¿Podemos permitirnos lanzarlo así?”
Cinco preguntas que cualquier junta debería hacer antes de aprobar un go-live
¿Qué evidencia demuestra que estamos listos, además de cumplir la fecha?
¿Qué riesgos siguen abiertos y quién los aceptó?
¿Cuál sería el costo de retrasar un mes frente al costo de interrumpir la operación?
¿Tenemos un plan real para volver atrás si algo sale mal?
¿Estamos tomando una decisión técnica o una decisión política?
La reflexión que me deja
Cada vez creo menos en los proyectos que llegan puntuales.
Y cada vez creo más en los proyectos que llegan preparados.
Porque el cliente nunca pregunta si cumplimos el cronograma.
Pregunta por qué su pedido no llegó.
Revlon no necesitaba únicamente un ERP nuevo.
Necesitaba proteger la continuidad del negocio mientras cambiaba el corazón de su operación.
Ese sigue siendo el desafío de cualquier transformación.
No instalar tecnología.
Sino cambiarla sin romper aquello que mantiene viva a la empresa.
Y quizá la decisión más valiente que puede tomar un líder no sea decir:
“Salimos el lunes.”
Quizá sea decir:
“Todavía no. Porque el negocio vale más que el calendario.”