Implementaciones fallidas de ERP: 9 casos de fracasos y decepciones

Puede descubrir cuán crucial puede ser el despliegue de un software de planificación de recursos empresariales (ERP) para una empresa a partir de una sola frase: demandas de miles de millones por implementaciones fallidas de ERP.

Greg Crouse, director general de Navigant Consulting, ha aprendido todo sobre implementaciones fallidas de ERP desde dentro del vientre de la bestia litigante, sirviendo como un experto testigo de la corte o consultor después de pasar 25 años administrando proyectos a gran escala.

El 21% de las empresas que respondieron a una encuesta de Panorama Consulting Solutions describió su lanzamiento de ERP más reciente como parte de las implementaciones fallidas de ERP.

Lo que está en juego en estos proyectos ha hecho que estos escándalos sean menos visibles. Cuando las demandas se hacen públicas, es una señal de que hay una historia jugosa sobre las implementaciones fallidas de ERP, pero las necesidades legales a menudo significan que los detalles completos de la disputa nunca salen a la luz. “Tendría dificultades para encontrar a alguien que lo mencionara; los casos litigarán para siempre o se arreglarán y sellarán”, dice Crouse.

Imagen 1

Los casos resonantes

1. Sistema de colegios comunitarios de Washington: cuando fracasan los terceros

El estado de Washington y la Junta Estatal para Colegios Comunitarios y Técnicos, o SBCTC, firmaron un acuerdo de servicio con la compañía Ciber en enero de 2013 para la entrega de de un software de gestión con una base unificada por valor de U$D 43.95 millones para las 34 escuelas técnicas y universidades comunitarias.

Se debió actualizar a un sistema PeopleSoft ERP que se suponía que se lanzaría en 2012. En cambio, el proyecto sigue rengo.

Una causa de retraso fue interna: los 34 campus del sistema tenían procesos comerciales muy variados que debían estandarizarse, lo que no estaba claro hasta bien avanzado el despliegue (rollout).

Pero surgió otra crisis: la tercera compañía contratada para lanzar el sistema PeopleSoft, Ciber, se declaró en bancarrota en abril de 2015. Otra empresa de Michigan, llamada HTC, que también trabajaba en el proyecto, subcontratada por Ciber, retiró sus activos del proyecto y luego canceló su contrato con el sistema escolar demandando a Ciber.

A su vez, Ciber demandó al estado de Washington por U$D 13 millones, alegando que el lanzamiento fallido se debió a una “disfunción interna” en la parte organizativa de los colegios.
Crouse dice que este tipo de animosidad mutua no es infrecuente. “Uno se mete en casos en los que el cliente no está contento con el trabajo que ha realizado la empresa de implementación y, por lo tanto, los demanda. El cliente no está contento y deja de pagar las facturas. El proveedor de la implementación no se siente responsable del incumplimiento y se produce una situación de demandante o demandado, según quién se enojó primero “.

Mientras tanto, el lanzamiento está atascado en el limbo y el proyecto es parte de las implementaciones fallidas de ERP.

2. Woolworth de Australia: la muerte de la memoria institucional

La cadena de tiendas departamentales, conocido cariñosamente como “Woolies”, también se topó con problemas relacionados con los datos al hacer la transición de un sistema construido hace 30 años en SAP. Una de las mayores crisis que surgieron fue que los informes de ganancias y pérdidas adaptados a las tiendas individuales, que los gerentes estaban acostumbrados a recibir cada semana, no pudieron generarse durante casi 18 meses.

El problema radica en el cambio en los procedimientos de recopilación de datos, pero la causa raíz fue que la empresa no comprendió completamente sus propios procesos. Los procedimientos comerciales cotidianos no estaban debidamente documentados, y cuando el personal superior abandonó la empresa a lo largo del largo proceso de transición de seis años, todo ese conocimiento institucional se perdió, y no se pudo integrar en el nuevo rollout.

“A menudo veo empresas que no toman a las personas que realmente conocen los procesos de negocios y los dedican al despliegue de ERP”, dice Crouse. “Lo convierten en un trabajo a tiempo parcial, o contratan gente nueva para decirle a los chicos del sistema que construir. Nada de eso funciona. Realmente debes asignar a las personas que conocen el proceso que estás tratando de implementar. Y es un tema común que, cuando no dedicas esas personas, te metes en problemas y tu proyecto es parte de las implementaciones fallidas de ERP”.

3. Target Canada: Basura adentro, basura afuera

Muchas compañías que implementan sistemas ERP se topan con inconvenientes cuando se trata de importar datos desde sistemas heredados a su nueva y brillante infraestructura. Sin embargo, cuando Target se lanzó en Canadá, asumieron que evitarían este problema: no habría datos para migrar, sólo información nueva para ingresar en su sistema SAP.

Pero al momento del lanzamiento, la cadena de suministro de la compañía colapsó, y los peritos rastrearon rápidamente la falla hasta llegar a la información supuestamente nueva: estaba plagada de errores.

Los elementos se marcaban con dimensiones incorrectas, precios, fabricantes, lo que sea. Resulta que miles de entradas ingresaron en el sistema a mano por empleados de nivel inicial sin experiencia que no sabían reconocer cuándo los fabricantes les habían dado información incorrecta. Un peritaje encontró que sólo aproximadamente el 30 por ciento de los datos en el sistema eran realmente correctos.

4. PG & E: cuando los datos de “muestra” no son tales

Algunos despliegues tienen como objetivo abordar este tipo de problema probando nuevos sistemas con datos de producción, generalmente importados de bases de datos existentes. Esto puede garantizar que los errores de datos se corrijan antes del despliegue, pero los datos de producción son elementos valiosos que contienen mucha información confidencial y patentada, y deben protegerse con el mismo cuidado que en la producción real.

En mayo de 2016, Chris Vickery, analista de riesgos en 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, con detalles de más de 47,000 computadoras, máquinas virtuales, servidores y otros dispositivos de PG & E, completamente abierta a visualización, sin nombre de usuario o contraseña requerida. Mientras que PG & E negó inicialmente que se tratara de datos de producción, Vickery dice que fue expuesto como resultado de un despliegue de ERP: un proveedor externo recibió datos de PG & E en vivo para llenar una base de datos “demo” y probar cómo reaccionaría en la práctica de producción real. Luego no proporcionaron la protección que necesitaría una base de datos de producción real.

5. Definitivamente no es una experiencia dulce para Hershey

¿Podría una implementación de tecnología fallida (en este caso, el software R / 3 ERP de SAP) derribar una empresa Fortune 500 (en este caso Hershey Foods)?

“Los sistemas de información de Hershey están proporcionando los datos necesarios para respaldar la transformación de la organización y los procesos comerciales. La actualización exitosa a SAP R / 3 4.6 fue un elemento crítico de nuestra estrategia” dijo el VP y CIO de Hershey Foods George David en en un comunicado de prensa del 29 de agosto de 2002.

Los problemas ocultos en su negocio pueden llevarlo a la cárcel, pero revelarlos, incluso si no se trata de un delito deliberado, también puede ocasionarle muchos problemas. Especialmente si los problemas tienen alguna conexión con el software y no se entienden bien. Dentro de las implementaciones fallidas de ERP este caso es curioso por sus consecuencias económicas en el mercado.

Cuando el ex presidente y consejero delegado de Candy Hershey Foods, Kenneth L. Wolfe, dijo a los analistas de Wall Street durante una conferencia telefónica en septiembre de 1999 que la compañía tenía problemas con su nuevo sistema de toma de pedidos y distribución -una combinación de software de 112 millones de dólares del fabricante de ERP SAP, el proveedor de CRM Siebel y el software de la cadena de suministro de Manugistics- no ofreció ningún detalle. Dijo, sin embargo, que los problemas iban a impedir que Hershey entregara $ 100 millones en Kisses and Jolly Ranchers para Halloween de ese año. Si bien Hershey dijo en agosto que Accenture y SAP ayudaron a sus equipos de TI a completar una implementación de R / 3, este error provocó que la acción cayera un 8 por ciento.

Así que supongo que un proyecto de tecnología fallido no puede acabar con una compañía de Fortune 500 para siempre, pero ciertamente puede perjudicarlo un poco.

6. Just Do it: ¡Arregla nuestro sistema de cadena de suministro!

¿Qué consecuencias produjo una actualización de U$D 400 millones a la cadena de suministro de Nike y los sistemas ERP?

Todo esto fue en el año 2000, y los horrendos resultados se debieron a un audaz proyecto que incluía un ERP, software para cadena de suministro y CRM que tenía como objetivo actualizar los sistemas. La historia de Nike es triste y de advertencia.

“Pensé que no íbamos a hablar sobre i2”, dice Roland Wolfram, vicepresidente de operaciones globales y tecnología de Nike, con los ojos deslumbrados en su gerente de relaciones públicas con ira mal ocultada.

Wolfram llama al problema i2, un error de software que le costó a Nike más de $ 100 millones en ventas perdidas, redujo su precio de acciones en un 20 por ciento, desencadenó una serie de demandas colectivas y provocó de su presidente y CEO, Phil Knight, un famoso lamento: “Esto es lo que obtienes por $ 400 millones, ¿eh?”, un “golpe de velocidad”.

UEn el negocio del calzado deportivo, solo Nike, con una participación de mercado mundial del 32 por ciento (casi el doble de Adidas, su rival más cercano) y una capitalización de mercado de $ 20 mil millones, es más que el resto de fabricantes y minoristas de la industria. alrededor de $ 100 millones así.

Esto enloquece a Wolfram que, mientras el resto del mundo conoce a su compañía por su marketing y su asociación con los atletas más famosos del mundo, el mundo de TI piensa en Nike como la compañía que arruinó su cadena de suministro, específicamente la demanda de i2, un motor de planificación que, en el año 2000, creó pedidos de miles de zapatillas Air Garnett más de las que el mercado tenía apetito y pidió miles de Air Jordan menos de lo necesario.

“Para las personas que siguen este tipo de cosas, nos convertimos en un poster de implementaciones fallidas”, dijo Wolfram.

Pero también hubo una lección para las personas que, de hecho, siguen “este tipo de cosas”, específicamente los CIO. La lección de la falla de Nike y su posterior rebote radica en el hecho de que tenía un plan de negocios que fue ampliamente comprendido y aceptado en todos los niveles de la empresa. Dado que, y la capacidad de recuperación que le dio a la empresa, al final la falla i2 resultó ser, de hecho, solo un “aumento de velocidad”.

7. La “tormenta perfecta” de HP con los problemas del ERP

La historia épica de la consolidación de los dispares sistemas ERP de HP América del Norte en un sistema SAP demuestra que uno nunca puede ser demasiado pesimista cuando se trata de la gestión de proyectos ERP.

Verá, en 2004, los gerentes de proyecto de HP sabían todas las cosas que podrían salir mal con su despliegue de ERP. Pero simplemente no planearon que muchas de ellas sucedieran a la vez.

Christina Hanger tenía pocas razones para ser pesimista en mayo de 2004, cuando trasladaba una de las mayores divisiones norteamericanas de Hewlett-Packard a un sistema ERP centralizado de SAP. Como líder de un proyecto de consolidación de TI surgida en la adquisición de HP de Compaq dos años antes, Hanger, vicepresidente senior de operaciones e IT para América, tuvo un récord ininterrumpido de éxito al migrar cinco grupos de productos dentro de las dos compañías anteriores a uno de los dos sistemas SAP.

Hanger tenía todos los motivos para creer que la sexta migración también iría bien. Aun así, sabía que estaba preparada para los problemas. Con aproximadamente U$D 7,500 millones en ingresos anuales, la división involucrada con este último proyecto, Industry Standard Servers (ISS), es mucho más grande que cualquiera de los otros que Hanger migró a SAP hasta ese momento.

Así que Hanger tomó el plan de contingencia que su equipo había desarrollado para las otras cinco migraciones y lo ajustó para acomodar el mayor volumen de ventas de la división ISS. Ella planeó tres semanas de crisis de TI, principalmente enfocadas en lo que podría suceder como resultado de ajustar un sistema de entrada de pedidos heredado para trabajar con el nuevo sistema SAP. El plan de contingencia abordó los impactos comerciales también. HP acumuló tres semanas de servidores adicionales y se apoderó de una parte vacía de una fábrica de HP en Omaha para evitar cualquier desbordamiento de pedidos que necesitaban configuraciones especiales (por ejemplo, una combinación inusual de componentes o software) y no podían acumularse por adelantado. de tiempo.

Pero el plan no era lo suficientemente pesimista.

Cuando el sistema comenzó a funcionar a principios de junio y continuó durante el resto del mes, hasta un 20 por ciento de los pedidos de los clientes para servidores se detuvo bruscamente entre el sistema heredado de entrada de pedidos y el sistema SAP. Algunos problemas de modelado de datos entre el sistema heredado y el sistema SAP impidieron que este último procesara algunos pedidos de productos personalizados. Estos errores de programación se corrigieron en cuatro o cinco semanas. Pero Hanger y sus colegas de la división ISS que formaban parte del comité directivo del proyecto nunca imaginaron el grado en que estas fallas de programación afectarían el negocio.

El proyecto finalmente costó HP U$D 160 millones en pedidos atrasados y pérdida de ingresos. Más de cinco veces el costo estimado del proyecto. Gilles Bouchard, entonces CIO de las operaciones globales de HP, dijo: “Tuvimos una serie de pequeños problemas, ninguno de los cuales habría sido demasiado difícil de manejar, pero juntos crearon la tormenta perfecta”.

8. Un nuevo tipo de novatadas de primer año

Cuando Stefanie Fillers regresó al campus de la Universidad de Massachusetts-Amherst el otoño pasado, tenía que iniciar sesión en el nuevo sistema de registro en línea de la escuela, llamado Spire, para asegurarse de que los cursos para los que se había inscrito le permitieran graduarse.

Lo último que necesitaba era algún programa de computadora para atormentar su vida y hacer su experiencia universitaria incierta.

Pero más de 27,000 estudiantes de la Universidad de Massachusetts así como de Stanford y la Universidad de Indiana se vieron obligados a luchar contra portales defectuosos y aplicaciones de ERP que los dejaron incapaces de encontrar sus clases y en el peor de los casos incapaces de cobrar sus cheques de ayuda financiera. Dijo un estudiante de último año de UMass en ese momento: “Los estudiantes de primer año se estaban volviendo locos porque no sabían a dónde ir”. El sistema Spire permite a los 24,000 estudiantes en el campus de Amherst registrarse para clases y realizar otras actividades en línea. Entonces, cuando se estrelló como resultado de una implementación del portal web PeopleSoft que se había apresurado, las clases estaban medio vacías durante los primeros tres días del semestre. Y había largas colas por todos lados.

Sin embargo, después de un par de días y semanas de tensión, todos obtuvieron sus cheques y sus horarios de clase.

9. Waste Management tiró a la basura su proyecto ERP

El gigante de la eliminación de residuos, Waste Management, todavía está envuelto en una áspera batalla legal de U$D 100 millones con SAP por una instalación de 18 meses de su software ERP. El acuerdo inicial comenzó en 2005, pero la historia legal comenzó en marzo de 2008, cuando Waste Management presentó una demanda y afirmó que los ejecutivos de SAP participaron en un esquema de ventas fraudulento que resultó en una falla masiva.

Varios meses después, SAP respondió que alegaba que Waste Management violó su acuerdo contractual con SAP de varias maneras, incluso al “no definir de manera oportuna y precisa sus requisitos comerciales”, y no proporcionó “suficientes usuarios con poder de decisión e información”. gerentes “para trabajar en el proyecto.

En el otoño de 2008, las acusaciones seguían volando sobre documentación, presentaciones judiciales y demoras para llevar el caso ante un juez. Y esa implementación propuesta de 18 meses ahora suena como un escenario de ensueño.

Fuente: http://www.evaluandoerp.com/implementaciones-fallidas-erp-9-casos-fracasos-decepciones/