Icono del sitio BI-Spain.com

12 proyectos ERP fallidos y cómo evitarlo tú

Nuestros amigos de Techtarget.com han publicado recientemente un muy interesante artículo sobre 12 proyectos ERP fallidos que reproducimos aquí en español. Puedes ver el artículo original en inglés aquí. 

Consultores de ERP comparten su análisis y aprendizajes de fallos espectaculares de ERP como los de Nike, National Grid, Revlon y MillerCoors, y ofrecen consejos para evitar escollos en ERP.

Existen muchas formas en las que los sistemas ERP pueden fallar. Muchas empresas se apresuran a implementar nuevas funciones sin considerar cuidadosamente los detalles, o sin conocer las razones comunes de los fallos en la implementación de ERP.

«Se necesita tiempo, capacitación dedicada y una gestión adecuada para que el ERP prospere como una herramienta eficiente dentro de su negocio», dijo Jenny Chua, gerente de desarrollo de negocios en The World Management, una consultora de ERP en Singapur.

John Belden, jefe de estrategia e investigación en UpperEdge, una consultora de negociaciones de TI con sede en Boston, suele observar tres características clave en estos proyectos que a menudo contribuyen al fallo en la implementación de ERP:

«Un programa tendrá problemas cuando las empresas no reconozcan estos problemas e intenten mitigar estos riesgos», afirmó Belden.

Estos 12 casos bien publicitados de fallos en la implementación de ERP ilustran algunas de las principales razones por las que estas operaciones fracasan y cómo evitarlos.

## 1. Los objetivos poco realistas de Nike

Nike pensó que podía «Simplemente hacerlo» cuando se embarcó en una actualización de $400 millones de su sistema ERP en el año 2000. Pero el nuevo sistema resultó en $100 millones en ventas perdidas y una caída del 20% en el precio de sus acciones al no poder cumplir con los pedidos de calzado Air Jordan.

«Nike fue demasiado optimista en sus objetivos y no verificó que los procesos de negocio satisficieran las necesidades operativas antes de implementar el sistema», dijo Alex Sharpe, fundador de Sharpe Management Consulting, con sede en Bridgewater, N.J.

**La lección:** Es importante establecer objetivos realistas en el plan de implementación, especialmente en lo que respecta a la funcionalidad del ERP y los cronogramas del proyecto. Sharpe también recomienda definir los requisitos operativos y de negocio desde el principio y tenerlos en cuenta al desarrollar los sistemas.

«Asegúrese de tomarse el tiempo suficiente para probar el sistema en busca de cualquier falla que deba corregirse antes de ponerlo en producción», afirmó.

## 2. MillerCoors contrató a las personas equivocadas para el trabajo

MillerCoors, que cambió su nombre a Molson Coors Beverage Co. en enero de 2020, se embarcó en un ambicioso plan para consolidar sus finanzas en un único sistema ERP con el fin de reducir costos y mejorar la eficiencia operativa. En 2014, contrató a HCL Technologies para implementar el proyecto, que se vio estancado por numerosos defectos. MillerCoors terminó demandando a HCL por $100 millones, y la demanda se resolvió finalmente en 2018.

Deepak Lalwani, director y consultor de gestión en Deepak Lalwani & Associates, una consultora de TI, dijo que el problema surgió porque las fases de planificación y arquitectura no recibieron la consideración adecuada. Además, se identificaron muchos defectos críticos y otros problemas adicionales, pero no se solucionaron.

La competencia principal de HCL era generalmente considerada la implementación, no la planificación y la arquitectura.

**La lección:** Asegúrese de contar con la experiencia adecuada en ERP para el proyecto en particular. «La TI es a menudo la parte más difícil y costosa de integrar múltiples empresas, y se apresuraron en la fase de planificación y arquitectura solo para lamentarlo más tarde», afirmó Lalwani.

## 3. Revlon subestimó el impacto operativo

Revlon intentó integrar sus procesos ERP en todas las unidades de negocio después de una fusión con Elizabeth Arden en 2016. El nuevo sistema falló espectacularmente después de su puesta en marcha en 2018, lo que resultó en una pérdida de $64 millones en ventas, una caída del 6.4% en el precio de las acciones y una demanda de inversores.

Un problema clave fue que Revlon había intentado consolidar sistemas de Microsoft y Oracle en una nueva implementación de SAP, pero carecía de experiencia práctica con SAP. También decidió lanzar el sistema sin asegurarse de que los procesos de negocio del ERP funcionarían según lo previsto.

«Lanzar un sistema que no cumple con las necesidades y requisitos operativos a menudo conduce a impactos comerciales adversos», afirmó Lalwani.

**La lección:** Tenga en cuenta tanto el lado operativo como el lado de negocio de la ecuación ERP.

## 4. La falta de pruebas de desastre de National Grid

La implementación de ERP de National Grid fue esencialmente arrasada por el huracán Sandy en 2012 cuando la empresa de servicios públicos intentó consolidar sus operaciones en EE. UU. en un sistema SAP común. Finalmente, el proyecto tardó dos años en resolverse, con un costo de $585 millones.

La empresa matriz había trabajado con éxito con la consultora Wipro en una consolidación ERP similar en Europa, pero el equipo del proyecto ERP tuvo dificultades con las grandes diferencias en los entornos regulatorios de EE. UU. Wipro sugirió que el proyecto SAP ERP estaba listo para salir en vivo basándose en los resultados de las pruebas, pero el sistema real no resistió la carga de trabajo aumentada. Se requirieron procesos de negocio de emergencia para reparar la red eléctrica después del huracán, lo que implicó procedimientos especiales para traer trabajadores y materiales de otras empresas de servicios públicos para las extensas reparaciones.

Belden dijo que el equipo de implementación se había centrado en pruebas de «ruta feliz», que implicaban probar funciones en circunstancias ideales, pero no había habido suficientes pruebas del sistema en escenarios de emergencia. National Grid decidió salir en vivo mientras el huracán avanzaba por la costa.

**La lección:** Es vital evaluar todos los factores que pueden afectar la preparación antes de lanzar una gran implementación de ERP.

## 5. Waste Management no verificó las afirmaciones del proveedor

Waste Management se encontró con grandes obstáculos cuando intentó una instalación masiva de SAP en 2005. Después de numerosos problemas y retrasos, la empresa terminó en una demanda de $500 millones contra SAP que finalmente se resolvió fuera de los tribunales.

SAP había sugerido que Waste Management podría lograr entre $106 millones y $220 millones en beneficios anuales con un sistema ERP consolidado que podría implementarse en 18 meses.

Lalwani dijo que un gran problema fue que Waste Management no verificó las afirmaciones de SAP antes de tomar una decisión ejecutiva. La empresa descubrió rápidamente que existían brechas significativas entre lo prometido y lo entregado en el software.

**La lección:** Verifique las afirmaciones del proveedor con equipos internos de negocio y técnicos. «Realizar una prueba de concepto sobre la funcionalidad crítica… puede reducir un riesgo significativo», afirmó Lalwani.

## 6. La Universidad de Washington tiene dificultades para pagar a los proveedores

La Universidad de Washington planeó inicialmente una migración a una plataforma financiera basada en la nube en 2022 como parte de su proyecto de Transformación Financiera de UW de $340 millones y cinco años. La implementación se retrasó un año, pero finalmente comenzó a avanzar en 2023. Muchos procesos centrales para recibir pagos y pagar al personal se incorporaron al nuevo sistema. Sin embargo, los pagos a proveedores y la canalización de subvenciones de investigación se retrasaron masivamente.

Gaurav Joshi, director de la firma global de consultoría de gestión y tecnología AArete, con sede en Chicago, ha visto muchos casos en los que grandes sistemas ERP diseñados para mejorar el rendimiento financiero terminaron creando interrupciones para los equipos de RRHH, adquisiciones y cuentas por pagar, así como para la base de proveedores. Como resultado, una organización podría no obtener los beneficios esperados de eficiencia y visibilidad de datos del proyecto, ya que a veces puede pasar varios años luchando contra errores, tensiones organizacionales y disrupciones operativas.

La gestión proactiva del cambio debe comenzar reconociendo y aceptando que una actualización de ERP es uno de los proyectos más complejos que emprenderá la organización. También requiere la participación de tomadores de decisiones clave que abarquen todas las funciones importantes y grupos de usuarios.

También es importante considerar a todos los interesados afectados por el proyecto. Esto incluye no solo a los usuarios de negocio y funcionales, sino también al ecosistema más amplio que abarca a clientes y proveedores.

**La lección:** «Mantener a todos los interesados al tanto de los impactos que el proyecto tendrá en sus trabajos diarios es fundamental», afirmó Joshi.

## 7. La solución ERP de Invacare «pesca un resfriado»

El proyecto ERP del fabricante de dispositivos médicos Invacare sufrió un revés clave al implementar una importante actualización de SAP en 2021. Desafortunadamente, la empresa tuvo que pagar una tarifa de mantenimiento mensual al integrador del sistema mientras el proyecto se prolongaba hasta 2022, y la junta, harta, salió en busca de un nuevo CEO en agosto de 2022.

«Las implementaciones de ERP son uno de los proyectos que más recursos consumen que una empresa puede emprender; la mala gestión del presupuesto y del cronograma puede descarrilar un proyecto ERP o detenerlo por completo», dijo Joshi.

Los proveedores de software y soporte que una empresa elige pueden marcar la diferencia. Joshi ha encontrado importante llevar a cabo un proceso de solicitud de propuestas que incluya un análisis comparativo de ofertas, demostraciones de proveedores y un cuadro de mando completado por los principales interesados.

**La lección:** Es importante estimar con precisión el costo total de propiedad, tener un cronograma que considere todos los servicios y socios, y desarrollar un plan para evitar sobrecostos debido a órdenes de cambio o retrasos.

## 8. Fuga de datos de producción de PG&E

En 2016, Pacific Gas and Electric se enfrentó a una importante brecha de seguridad cuando un proveedor externo contratado para crear una nueva plataforma de gestión de activos copió datos en vivo de PG&E a su propia red sin implementar las medidas de seguridad necesarias durante las pruebas del ERP de Oracle. Esto llevó a que más de 30,000 elementos de datos estuvieran en línea y accesibles durante casi 70 días.

Un investigador de seguridad «white-hat» alertó a PG&E sobre la brecha, lo que llevó a la empresa de servicios públicos a iniciar esfuerzos de recuperación. Estos esfuerzos incluyeron costos sustanciales y una multa de casi $3 millones. Además de los gastos financieros, la reputación de PG&E y la confianza de los clientes en cómo la empresa gestiona los datos sensibles resultaron dañadas.

**La lección:** Asegúrese de que los equipos del proyecto posean la experiencia técnica requerida y utilice un entorno de pruebas dedicado que no maneje datos en vivo.

## 9. El proyecto desproporcionado de Cover Oregon

Los proyectos más grandes tienden a poner a una organización en una posición en la que no está preparada para el volumen y la magnitud de las decisiones requeridas. Como resultado, los equipos abrumados terminan acumulando una mala decisión tras otra.

Belden dijo que un ejemplo clásico fue el intento de 2012 por parte del mercado estatal de atención médica en línea, Cover Oregon, de implementar simultáneamente Obamacare y reemplazar sus sistemas de procesamiento de transacciones de soporte. Finalmente, gastó más de $300 millones y fue incapaz de procesar una sola solicitud de seguro a través del intercambio.

«Crearon un escenario en el que el proyecto se volvió tan enorme que no pudieron cumplir con las fechas de entrega», dijo Belden, ni tomar las decisiones necesarias. Los problemas se agravaron por la necesidad de cumplir con el plazo estricto impuesto por Obamacare. Belden dijo que cree que el proyecto habría funcionado si Cover Oregon hubiera mantenido el proyecto ERP más pequeño y lo hubiera restringido a lo que habría sido requerido para Obamacare.

**La lección:** Limite el alcance del proyecto ERP al marco de tiempo apropiado.

## 10. El enfoque limitado de Israel Chemical Limited

Los problemas generacionales pueden ocurrir cuando nadie en el equipo de gestión del programa comprende dónde están los problemas.

«Pueden tener experiencia previa, pero fue hace 10 o 15 años y las personas que aprendieron las lecciones están en otro lugar de la organización o se han ido», dijo Belden.

Un buen ejemplo es el fallido proyecto de implementación de SAP ERP de Israel Chemical Limited (ICL) en 2014. El costo del proyecto se disparó de $120 millones a más de $500 millones. Finalmente, el CEO de ICL renunció y toda la implementación fue cancelada.

El CEO había asignado el proyecto a una persona relativamente nueva en la oficina del CFO, según Belden. Este líder del proyecto se centró principalmente en asegurar que las finanzas se incorporaran correctamente al proyecto ERP, en lugar de considerar también las necesidades de los lados de fabricación y cadena de suministro del negocio. Los empleados de la primera fábrica se rebelaron después de que se les impusiera el nuevo sistema.

«Se enfocaron más en la integridad financiera que en la integridad operativa», dijo Belden.

**La lección:** Concéntrese en todos los usuarios de la implementación de ERP propuesta y no solo en una parte del negocio.

## 11. Ranpak retrasada por un conflicto global inesperado

La empresa de embalaje Ranpak lanzó un nuevo ERP en enero de 2022 para coincidir con el año nuevo. También ocurrió justo antes del ataque ruso a Ucrania, que ha tensionado las cadenas de suministro y añadido mayor complejidad a las estructuras de costos. Como resultado, las ventas cayeron y los tiempos de envío aumentaron. Todos estos factores combinados ralentizaron la implementación del ERP y aumentaron los costos. La empresa finalmente comenzó a lograr cierto éxito después de superar los desafíos adicionales de implementación de ERP resultantes, mucho más tarde de lo esperado.

«Si bien ciertos riesgos nunca pueden predecirse, un buen plan de proyecto de implementación de ERP siempre tiene cierta flexibilidad incorporada», dijo Joshi.

Por ejemplo, Joshi dijo que AArete trabajó con un cliente que experimentaba un rápido crecimiento y que esperaba tiempos de respuesta acelerados para sus implementaciones de ERP, por lo que desarrolló planes de contingencia en caso de que se anunciaran adquisiciones durante la migración, lo que ocurrió dos veces. Esta planificación agilizó la capacitación para los usuarios funcionales de la empresa adquirida, incorporó las necesidades comerciales y los conjuntos de datos requeridos, y encontró compromisos cuando fue necesario.

**La lección:** Una implementación sustancial de ERP puede llevar tiempo, por lo que es importante identificar y planificar las contingencias que puedan afectar la puesta en marcha.

## 12. Mission Produce subestima las necesidades de la cadena de suministro

En 2022, Mission Produce actualizó su sistema de software empresarial para mejorar la gestión y eficiencia de la cadena de suministro. Cuando el sistema entró en funcionamiento, hubo retrasos en el procesamiento de pedidos, imprecisiones en el inventario y problemas de comunicación entre las unidades de negocio, lo que resultó en el incumplimiento de los plazos de entrega y pérdidas financieras. Al no comprender las necesidades de sus socios globales, Mission Produce no validó adecuadamente los requisitos y subestimó el cronograma de su ERP. Otros factores contribuyentes fueron la falta de capacitación de los empleados en el nuevo sistema y la ausencia de un individuo o equipo al frente del proyecto.

**La lección:** Es importante incluir a todos los interesados en la fase de recopilación de requisitos. Sea realista con el cronograma del proyecto ERP, implemente sólidas prácticas de gestión de proyectos y realice pruebas para detectar cualquier problema antes de que el sistema entre en funcionamiento.

Salir de la versión móvil