
[21/11/2022] Dado que las aplicaciones de planificación de recursos empresariales (ERP, por sus siglas en inglés) y de gestión de las relaciones con los clientes (CRM, por sus siglas en inglés) son el núcleo de las operaciones de muchas empresas, las consecuencias de un fracaso en la implantación del software pueden ser graves, incluidas las demandas de los accionistas y el colapso financiero.
Sin embargo, tras una serie de fracasos de gran repercusión, hay indicios de que los proveedores y los clientes están trabajando duro para garantizar el éxito de sus proyectos de ERP. Panorama Consulting Solutions, que encuesta regularmente a las empresas sobre los resultados de sus proyectos de ERP, muestra en su informe del 2022 que el 81% de los proyectos cumplieron las expectativas de retorno de la inversión un año o más después de la puesta en marcha.
[Reciba lo último de CIO Perú suscribiéndose a nuestro newsletter semanal]
Sin embargo, la medida del éxito ha estado históricamente en desacuerdo con el número de proyectos que se dice que están sobrepasados o con un rendimiento inferior, ya que Panorama ha observado que las organizaciones han bajado sus estándares de éxito.
También puede ser que las empresas deseen evitar el daño a la reputación que conlleva el fracaso, y en su lugar prefieran redefinir el éxito como cualquier cosa que consigan. A veces, la única señal de que algo ha ido mal es cuando las partes se dirigen a los tribunales, y rara vez se conocen todos los detalles de la disputa.
Pero, independientemente de cómo se defina el éxito, hemos reunido aquí algunos fracasos dramáticos de la planificación de recursos empresariales a lo largo de los años y hemos tratado de extraer sabiduría de los restos.
1. Mission Produce: Esta palta se autodestruye en cinco días
Mission Produce envasa, madura y distribuye paltas por todo el mundo, y se enorgullece de su capacidad para entregarlas recién maduras durante todo el año. En noviembre del 2021 puso en marcha un nuevo sistema de planificación de recursos empresariales (ERP) destinado a apoyar el crecimiento internacional con una mayor visibilidad operativa y capacidad de elaboración de informes financieros.
Entonces, todo se vino abajo y, de repente, Mission ya no sabía con certeza cuántas paltas tenía a mano, ni su grado de madurez, y muchos de ellas acabaron no siendo aptas para la venta. Tuvo que comprar fruta a otros proveedores para cumplir sus compromisos de entrega, lo que supuso un golpe en los márgenes. Además, se produjeron retrasos en la facturación automática a los clientes.
"A pesar de las innumerables horas que dedicamos a la planificación y preparación de esta conversión, experimentamos importantes desafíos en la implementación", señala el director general, Stephen Barnard, a los inversores con una deliciosa subestimación. "Aunque no éramos ingenuos en cuanto al riesgo de interrupción del negocio, el alcance y la magnitud fueron mayores de lo que habíamos previsto".
La empresa se vio obligada a desarrollar nuevos procesos para que la información siguiera fluyendo por el negocio y a contratar a un consultor externo para que solucionara el sistema ERP, con un coste de 3,8 millones de dólares en los nueve meses siguientes.
Sin embargo, eso no es nada comparado con el golpe que sufrió Mission en sus ganancias. Es difícil atribuir un costo exacto a la falla del ERP, ya que la empresa se enfrentó a otros problemas derivados de una mala cosecha de palta en México en la misma época. Sin embargo, dijo que la caída interanual de 22,2 millones de dólares en el beneficio bruto para el trimestre siguiente a la puesta en marcha se debió principalmente al problema del ERP.
2. Invacare se enfrenta a una larga espera y a un aumento del costo de la intervención del ERP sanitario
Invacare, fabricante de dispositivos médicos, ha puesto en coma su maltrecha actualización de SAP, deteniendo temporalmente el proyecto, pero no las facturas.
La unidad de negocio norteamericana de la empresa, que representa el 40% de sus ingresos, fue la primera en pasar al nuevo sistema en octubre del 2021. No fue bien, limitando inicialmente los pedidos en línea y provocando retrasos en las cuentas por cobrar, aunque las cosas estaban volviendo a la normalidad al final del trimestre.
Los dolores del ERP son una enfermedad recurrente para Invacare, que también tuvo problemas con una actualización anterior entre el 2005 y el 2009.
La empresa está ocupada reestructurándose tras la pandemia, simplificando sus líneas de productos y adaptando su cadena de suministro a la nueva realidad. Esto ha hecho que el equipo que trabaja en la actualización del ERP no pueda seguir el ritmo, por lo que a principios de 2022 Invacare decidió poner el proyecto en pausa.
"Queríamos hacer una pausa en la inversión en la huella actual, que solo se reharía en función de cómo se revise la huella. Y creemos que eso tardará un par de trimestres en resolverse", sostuvo a los inversores en agosto del 2022, el presidente y consejero delegado, Matt Monaghan. "Una vez que tengamos esa plantilla creada en Norteamérica, se desplegará a nivel mundial".
Aunque el trabajo en el proyecto de ERP se ha detenido, la compañía todavía tiene que seguir pagando a su integrador de sistemas la misma cuota mensual, anota.
Los continuos retrasos y costos parecen no haber gustado al consejo de administración de Invacare, que dos semanas después echó a Monaghan diciendo que la empresa necesitaba "un cambio de liderazgo para supervisar la ejecución con éxito de la transformación empresarial de Invacare".
Si hay algo que los CIO pueden sacar de la experiencia de Invacare, es asegurarse de que los contratos de los integradores de sistemas no requieren que se les pague cuando no hay nada que hacer.
3. Los beneficios de la empresa de embalaje de protección se ven afectados por el ERP
La migración a SAP de la empresa de embalajes Ranpak no fue ni mucho menos un desastre (tardó menos de un año y se entregó a tiempo y dentro del presupuesto); pero, sin embargo, al principio produjo resultados decepcionantes.
El paso a un sistema ERP basado en la nube se produjo varios años después de una transformación digital más amplia en Ranpak.
La empresa puso en marcha el nuevo ERP en enero del 2022, coincidiendo con su nuevo año fiscal. Tras un periodo de inactividad planificado, "experimentamos ineficiencias a medida que ascendíamos en la curva de aprendizaje del nuevo sistema", sostuvo el director general, Omar Asali, en una presentación de los resultados del primer trimestre.
El despliegue del software coincidió con el ataque de Rusia a Ucrania, lo que dificultó la respuesta de la empresa a la interrupción de la cadena de suministro y el aumento de los costos de los insumos. Esto se tradujo en un descenso de las ventas en general, ineficiencias en el procesamiento y el envío, y una incapacidad para aumentar los precios en línea con los costos, lo que llevó a una caída de cinco millones de dólares en el beneficio neto del trimestre.
Algunos de los problemas de software siguieron sin resolverse en el segundo trimestre, y a finales del tercero la empresa había acumulado 6,5 millones de dólares en costos de implantación. Sin embargo, a principios de noviembre, Asali afirmó que el nuevo sistema ERP había empezado a proporcionar una medición mejor y más rápida de la productividad y los indicadores clave de rendimiento.
4. El fabricante de aperitivos muerde más de lo que puede masticar con el cambio de ERP
Los problemas de ERP de J&J Snack Foods no provienen de un sistema moderno, sino de uno más antiguo: JD Edwards de Oracle.
J&J ha utilizado durante mucho tiempo JD Edwards en su división de bebidas congeladas y decidió trasladar toda la empresa a la misma plataforma. De manera inusual, la empresa decidió no cambiar de sistema ERP después de cerrar sus libros para el año, sino en la mitad de su segundo trimestre fiscal. En el caso de J&J, fue en febrero, un periodo normalmente tranquilo para la venta de aperitivos.
Febrero del 2022 resultó ser más activo de lo habitual, aunque no por las mejores razones.
"La implementación creó desafíos temporales, operativos, de fabricación y de la cadena de suministro imprevistos que afectaron al rendimiento de nuestros segmentos de servicios de alimentación y de venta al por menor durante el trimestre", comentó el director general, Daniel Fachner, a los inversores en mayo. Para entonces, sin embargo, los problemas se habían resuelto en gran medida y la empresa estaba "afinando algunas piezas", dijo.
Estos problemas hicieron que J&J perdiera 20 millones de dólares en ventas y 4,5 millones de dólares en ingresos operativos. Habría sido un trimestre de bandera si no fuera por la interrupción del ERP: El segmento de bebidas congeladas de la empresa, que ya funciona con JD Edwards, vio aumentar sus ventas en un 50%.
5. Leaseplan: Un monolito no apto para el mundo digital emergente
Tras un despliegue de SAP inicialmente exitoso en su filial australiana, en el 2016 la empresa de gestión de vehículos Leaseplan encargó a HCL Technologies el desarrollo de un nuevo Core Leasing System (CLS) basado en SAP, que iba a ser el corazón de la transformación informática del grupo en 32 países.
A principios del 2018, los auditores advirtieron de las excepciones con respecto al acceso de los usuarios y la gestión de cambios en CLS, y recomendaron mejoras en los controles de TI y la gobernanza, ya que se esperaba que más países migraran a CLS ese año. En marzo del 2019, las cosas estaban fallando. Los auditores señalaron que el despliegue de "las primeras fases" de CLS se esperaba ahora ese mismo año, y añadieron recomendaciones sobre la gestión del riesgo de externalización a sus advertencias anteriores.
Leaseplan abandonó el CLS meses después, cancelando 92 millones de euros (100 millones de dólares) en costos del proyecto, y millones más en gastos de reestructuración y consultoría. Solo consiguió salvar 14 millones de euros que había gastado en módulos informáticos desarrollados por separado y que esperaba que generaran beneficios económicos en el futuro.
El problema, señaló Leaseplan en sus resultados del segundo trimestre, era que CLS "no sería apto para el mundo digital emergente en el que [operaba]". La naturaleza monolítica del sistema SAP "obstaculizaba su capacidad para introducir mejoras incrementales en los productos y servicios en un momento de cambio tecnológico acelerado", según Leaseplan.
En su lugar, la empresa planeó construir un sistema modular utilizando los mejores componentes de terceros junto con sus sistemas existentes de mantenimiento predictivo, reclamación de seguros y gestión de contratos. Esperaba que esto fuera más escalable y permitiera el despliegue y las actualizaciones incrementales del producto.
6. MillerCoors: Peleando en público, luego haciendo las paces
En el 2014, MillerCoors estaba ejecutando siete instancias diferentes del software ERP de SAP, un legado de los años de consolidación de la industria de la bebida que había producido el gigante del alcohol. La empresa fusionada contrató a la empresa india de servicios informáticos HCL Technologies para que pusiera en marcha una implementación unificada de SAP que sirviera a toda la empresa. Las cosas no salieron bien: El primer despliegue estuvo marcado por ocho defectos de gravedad "crítica", 47 defectos de alta gravedad, y miles de problemas adicionales registrados durante un largo período de "hipercuidado de la puesta en marcha". En marzo del 2017, el proyecto había ido tan mal que MillerCoors demandó a HCL por 100 millones de dólares, alegando que HCL había dotado de personal inadecuado al proyecto y no había cumplido sus promesas.
Pero la empresa de servicios informáticos no lo aceptó. En junio del 2017, HCL contrademandó, alegando que MillerCoors estaba, en esencia, culpando a HCL de su propia disfunción de gestión, que, según HCL, era la verdadera causa del fracaso. Los observadores externos señalaron que la redacción de los contratos, tal y como se describía en las demandas, parecía basarse en un contrato de servicios generales preexistente entre las dos empresas, y dejaba mucho margen de error. Luego, en diciembre del 2018, las dos empresas resolvieron la disputa "amistosamente", habiendo aparentemente utilizado los tribunales como un lugar para una sesión de negociación pública de alto riesgo.
7. Revlon: Metiendo la pata lo suficiente como para enfurecer a los inversores
El gigante de los cosméticos Revlon fue otra empresa que se encontró con la necesidad de integrar sus procesos en todas las unidades de negocio después de una fusión -en este caso, había adquirido Elizabeth Arden, Inc. en el 2016. Ambas empresas habían tenido experiencias positivas con los despliegues de ERP en el pasado: Elizabeth Arden con Oracle Fusion Applications, y Revlon con Microsoft Dynamics AX. Pero la empresa fusionada tomó la fatídica decisión de optar por un nuevo proveedor, SAP HANA, en diciembre del 2016.
¿Era HANA un producto poco cocido y condenado al fracaso? Puede ser. Lo que está claro es que el despliegue fue lo suficientemente desastroso como para sabotear la propia planta de fabricación de Revlon en Carolina del Norte, lo que supuso una pérdida de millones de dólares en ventas. La compañía culpó a la "falta de diseño y mantenimiento de controles efectivos en relación con la ... implementación" por el fiasco en marzo del 2019. También señaló que "estas interrupciones relacionadas con el ERP han causado que la compañía incurra en tarifas de envío acelerado y otros gastos no anticipados en relación con las acciones que la compañía ha implementado para remediar la disminución de los niveles de servicio al cliente, que podrían continuar hasta que se resuelvan los problemas de los sistemas ERP." La crisis hizo que las acciones de Revlon cayeran en picada; lo que, a su vez, llevó a los propios accionistas de la empresa a demandar.
8. Lidl: Un gran problema para el gigante alemán de los supermercados
Se suponía que era la unión de dos grandes empresas alemanas: SAP, la superestrella del ERP/CRM, y Lidl, una cadena de supermercados de ámbito nacional con unos ingresos anuales de 100 mil millones de euros. Ambas empresas empezaron a trabajar juntas en una transición para dejar atrás el deficiente sistema de inventario interno de Lidl desde el 2011. Pero en el 2018, tras gastar casi 500 millones de euros, Lidl desechó el proyecto.
¿Qué ocurrió? El rumor se centró en una peculiaridad en el registro de Lidl: Siempre han basado sus sistemas de inventario en el precio que pagan por los productos, mientras que la mayoría de las empresas basan sus sistemas en el precio de venta al público de los productos. Lidl no quería cambiar su forma de hacer las cosas, así que la implementación de SAP tuvo que ser personalizada, lo que desencadenó una cascada de problemas de implementación. Si a esto le sumamos la excesiva rotación de personal en el departamento de TI de Lidl, y el señalamiento de la consultora encargada de guiar la implantación, tenemos la receta para el desastre del ERP.
9. National Grid: Una tormenta perfecta
National Grid, una empresa de servicios públicos que da servicio a clientes de gas y electricidad en Nueva York, Rhode Island y Massachusetts, se enfrentaba a una situación difícil. La implementación de un nuevo SAP llevaba tres años de trabajo y ya se había retrasado. Si no se cumplía la fecha de puesta en marcha, habría sobrecostos por valor de decenas de millones de dólares, y tendrían que obtener la aprobación del gobierno para subir las tarifas para pagarlos. Si ponían en marcha su nuevo sistema SAP antes de tiempo, sus propias operaciones podrían verse comprometidas. Ah, y la fecha de entrada en funcionamiento era el 5 de noviembre del 2012, menos de una semana después de que la supertormenta Sandy devastara el área de servicio de National Grid y dejara a millones de personas sin electricidad.
En medio del caos, National Grid tomó la fatídica decisión de cambiar de sistema, y los resultados fueron aún más desastrosos de lo que los pesimistas temían: algunos empleados recibieron nóminas demasiado abultadas, mientras que a otros se les pagó de menos; no se pudieron procesar 15 mil facturas de proveedores; y los informes financieros se colapsaron hasta el punto de que la empresa ya no podía obtener el tipo de préstamos a corto plazo del que solía depender para el flujo de caja. La demanda de National Grid contra Wipro, su integrador de sistemas, se resolvió finalmente fuera de los tribunales por 75 millones de dólares, pero eso no llegó a cubrir las pérdidas.
10. Worth & Co: Un despliegue interminable lleva a una demanda en el origen
Worth & Co. es una empresa manufacturera con sede en Pensilvania que solo quería un nuevo sistema ERP, y después de escuchar varios lanzamientos en el 2014, decidió contratar a EDREi Solutions para implementar E-Business Suite de Oracle. La primera fecha de entrada en funcionamiento era noviembre del 2015. Pero las cosas empezaron a torcerse. El plazo se retrasó hasta febrero del 2016. En ese momento, Oracle exigió a Worth & Co. que aportara 260 mil dólares para cursos de formación y contratos de asistencia. Pero el 2016 llegó y pasó y todavía no hubo despliegue. En el 2017, Worth & Co. abandonó EDREi por otro integrador, Monument Data Solutions. Se pasó otro año intentando, sin éxito, personalizar la suite de Oracle para los fines de Worth & Co.
Finalmente, tras el abandono del proyecto, Worth & Co. hizo algo novedoso en febrero del 2019: no demandó a su proveedor de TI, sino a Oracle, citando específicamente los 4,5 millones de dólares que pagaron al gigante del software por licencias, servicios profesionales y formación. La demanda sigue en curso.
11. Target Canada: Basura que entra, basura que sale
Muchas empresas que despliegan sistemas ERP se topan con obstáculos a la hora de importar los datos de los sistemas heredados a su nueva y reluciente infraestructura. Sin embargo, cuando Target se lanzó en Canadá en el 2013, supusieron que evitarían este problema: no habría datos que convertir, solo nueva información que introducir en su sistema SAP.
Pero tras el lanzamiento, la cadena de suministro de la empresa se colapsó, y los investigadores no tardaron en rastrear la falla hasta estos datos supuestamente nuevos, que estaban plagados de errores: los artículos estaban etiquetados con dimensiones, precios y fabricantes incorrectos, de todo. Resulta que miles de entradas fueron introducidas en el sistema a mano por empleados de nivel básico, sin experiencia que les ayudara a reconocer cuándo habían recibido información incorrecta de los fabricantes, y que trabajaban con plazos muy ajustados. Una investigación descubrió que solo un 30% de los datos del sistema eran realmente correctos.
12. PG&E: Cuando los datos "de muestra" no son
Algunas implantaciones pretenden atajar este tipo de problemas probando los nuevos sistemas con datos de producción, generalmente importados de las bases de datos existentes. Esto puede garantizar que los errores de los datos se corrijan antes de la puesta en marcha, pero los datos de producción son un material valioso que contiene mucha información confidencial y de propiedad, y deben protegerse con el mismo cuidado que en la producción real.
En mayo del 2016, Chris Vickery, analista de riesgos de UpGuard, descubrió una base de datos expuesta públicamente que parecía ser el sistema de gestión de activos de Pacific Gas and Electric, que contenía detalles de más de 47 mil computadoras, máquinas virtuales, servidores y otros dispositivos de PG&E, completamente abiertos a la vista, sin necesidad de nombre de usuario o contraseña. Aunque PG&E negó en un principio que se tratara de datos de producción, Vickery afirma que sí lo eran, y que fueron expuestos como resultado de un despliegue de ERP: un proveedor externo recibió datos reales de PG&E para llenar una base de datos "de demostración" y probar cómo reaccionaría en la práctica de producción real. Luego no proporcionaron ninguna de las protecciones que necesitaría una base de datos de producción real.
Sobrevivir a la implantación de un ERP
¿Qué hemos aprendido? Pues que hay que evitar caer en la trampa de los reguladores, asegurarse de que los datos están seguros y limpios, y documentar los procesos antes de pasar a una nueva plataforma.
Basado en el artículo de Josh Fruhlinger (CIO) y editado por CIO Perú
Puede ver también: