Crónica de un fracaso: implementación ERP SAP de USD 30 Millones. En abril de 2010 la empresa Condado de Marin, en California, decidió contratar a la empresa consultora de sistemas DLT para implementar el sistema SAP. Tras dos años de desaciertos, con un gasto de USD 30 millones y luego de desembolsar USD 11 millones en concepto de consultoría, el proyecto cayó. En el año 202 la Junta de Supervisores del Condado de Marin votó a favor de detener el proyecto SAP en curso y buscar una solución de reemplazo, aceptando implícitamente que perdió más de $ 30 millones de dólares en software y servicios de implementación relacionados brindados por DLT Consulting. En un documento presentado ante la corte, las autoridades alegaron que: “en lugar de proporcionar experiencia en el sector público, DLT utiliza los proyectos SAP del Condado como un campo de entrenamiento de prueba y error para enseñar a sus consultores”. La drástica decisión de sustituir SAP se produce después que las relaciones entre Marin y DLT Consulting, el consultor de implementación de este proyecto, se deterioraron hasta el punto de ruptura. EL condado presentó una demanda "en busca de daños y compensación de al menos $ 30 millones, además de daños y perjuicios punitivos y ejemplares o no especificados". DLT ha contrademando a Marin por aproximadamente $ 550.000 en honorarios no pagados y cargos por mora. Por su parte, SAP tuvo cabida para publicar su versión de los hechos en Computerworld, dónde el portavoz de la firma, Andy Kendzie, declaró: “SAP cree firmemente en el valor y el rendimiento de su software en el condado de Marin. Nuestro producto funciona exactamente como debe ser, y los problemas en esta implementación de ninguna manera reflejan el software de SAP. Nuestro sistema está instalado y funcionando perfectamente en decenas de miles de organismos del sector público, incluyendo organismos de California." En un comunicado DLT declaró que es lamentable que el condado haya decidido presentar una demanda. "Como se dijo anteriormente, hemos cumplido todas y cada una de las obligaciones derivadas del contrato de servicios. Todo nuestro trabajo fue aprobado por los funcionarios del condado responsables del proyecto. Para ser claros, el software de SAP estaba funcionando correctamente cuando completamos nuestro trabajo. No sólo que la denuncia carece de fundamento, sino que hemos presentado nuestra propia demanda contra el Condado por incumplimiento de contrato y las facturas pendientes de pago. Aunque estamos seguros de que vamos a prevalecer en los tribunales, sigue siendo nuestra convicción de que este conflicto puede y debe ser resuelto de una manera más lógica que beneficia el Condado y sus contribuyentes ", dijo la compañía. En la afirmación de DLT, presentada ante la Junta de Supervisores del Condado de Marin, la compañía dijo que 13 consultoras que trabajan con SAP, Oracle, PeopleSoft y otros proveedores de software, presentaron ofertas para la implementación del ERP, y que la oferta de DLT fue uno de los cuatro que trabajan con SAP. En diciembre de 2004, un comité formado por personal del Condado recibió demostraciones de las capacidades y servicios de cada consultor interesado en el proyecto. "Con base en su análisis independiente, el comité del Condado, más allá del disenso de los miembros que preferían un proveedor de software diferente, eligió SAP como proveedor del software ERP para la actualización del sistema. De las 4 consultoras que implantan SAP, el Condado seleccionó a DLT Consulting”, escribió la compañía en su reclamo. Análisis de la situación. ¿Qué salió mal? El rol del Condado de Marín. Después de haber revisado la documentación importante, la decisión de Marín para sustituir SAP parece destinada, principalmente, a fortalecer su posición en la demanda e impulsar todas las responsabilidades fuera de su organización. La posición de Marin es extrema y poco creíble. La aparente falta de de madurez de la organización, su pobre gestión y su incapacidad para absorber los cambios que transforman el negocio, asociados a esta aplicación, parecen ser un elemento básico que subyace a este fracaso. Un informe elaborado por los Servicios de Información de Marin y del Departamento de Tecnología, reconoce importantes lecciones aprendidas en este proyecto, que serán consideradas en una futura implantación de ERP. El equipo de trabajo recomienda fijarse en otras opciones del sistema y advierte el siguiente enfoque: • Un enfoque gradual y por fases para la sustitución de SAP, en lugar del enfoque "big bang", que fue aplicado en la implementación de SAP y que fue aconsejado por los asesores externos. • Menos dependencia de consultores externos y más en los profesionales del Condado, que tienen un mayor interés personal en el resultado y el éxito de la implementación. El rol de DLT. DLT comparte la culpabilidad en la creación de esta situación. La postura y la falta de voluntad de DLT para aceptar una responsabilidad parcial por el fracaso parece inconsistente con los hechos. DLT parece centrado en indemnizaciones derivadas del propio proceso de la implantación, sin tener en cuenta si el cliente ha logrado fracasos o resultados exitosos. La posición y las acciones de DLT están en marcado contraste con lo que pregona en su sitio web acerca de de ser una compañía centrar en el cliente. El rol de SAP. Ni Marín, ni DLT han sugerido que el software de SAP ha contribuido de alguna manera al fracaso. Sin embargo, un análisis completo debe considerar el papel de SAP en el establecimiento de las expectativas del cliente con respecto a las demandas impuestas por el proceso de implementación. La medida en que los proveedores de software e integradores deben asumir la responsabilidad de las decisiones que los compradores hacen durante el proceso de compra es una cuestión difícil. La solución está en tres áreas: • Los clientes de software empresarial deben tener más cuidado la evaluación de sus propias capacidades antes de emprender cualquier iniciativa de cambio organizacional complicada que incluya la implementación de sistemas ERP. • Los integradores de sistemas y empresas de consultoría tienen que ser más claros en la explicación a los clientes potenciales de las trampas que encierra un proyecto y en los factores de éxito. Algunos consultores pintan un cuadro demasiado positivo durante el proceso de venta. Tales comentarios superficiales tienen que evitarse. • Los proveedores de software deben vincular un mayor porcentaje de compensación a la satisfacción del cliente final. Opiniones. Mark F. O'Connor , CEO y co -fundador de Monadnock Investigación , una firma que ofrece asesoramiento a clientes empresariales que contratan compañías de servicios manifestó: “Parece que el Condado nunca ha aceptado la responsabilidad de ser el más interesado en que el sistema funcione. De hecho, la lectura del acuerdo con DLT parece indicar que el Condado estaba tratando de cederla a DLT. Pero la responsabilidad sin autoridad, siempre produce resultados similares a lo que vemos aquí, en proyectos de sistemas complejos. Hay, literalmente, miles de decisiones importantes que deben ser tomadas por personal del cliente durante la implementación, mientras que siguen haciendo su trabajo rutinario”. Si bien hay casos de proyectos fallidos en América Latina, entre los casos resonantes caben destacar dos bancos de Argentina. Uno de ellos es el Banco Columbia en dónde SAP vendió su software para la vertical bancaria. Se trata de una institución de poco más de 40 puntos de venta (agencias y sucursales) que, en Noviembre de 2007, decidió por el proveedor alemán con la esperanza de incrementar su eficiencia operacional y reducir costos, así como hacer frente a los desafíos que tienen los bancos tales como: integración de la información, prevención de riesgos, respuesta a las regulaciones y el desarrollo de productos innovadores a la medida de sus cliente. El colapso del proyecto no solo terminó con las ilusiones del banco sino también con gran parte de los ejecutivos de la institución que tuvieron a cargo la implementación. En 2011 el banco decidió abortar el proyecto. En el mismo año 2007, otro banco de Argentina con más de 130 sucursales decidió implementar SAP. Todavía lo está intentando. Conclusiones. El análisis del caso Marin y la evaluación de las diferentes alternativas llevan a reflexionar lo siguiente: • ¿Cuál es el costo estimado del proceso de evaluación de alternativas, selección y puesta en marcha de un software ERP? • ¿Cuáles son los costos de adquisición de aplicaciones? • ¿Cuáles son los costos estimados para el rediseño de procesos de negocio? • ¿Cuántas horas están siendo asumidas por cada una de las partes? • ¿Qué tarifas por hora se aplican a los consultores? • ¿Cuáles son los costos estimados para la migración y conversión de datos? • Si se elige la mejor solución ¿Cuáles son los gastos de infraestructura y servicios de software asociados con la integración de aplicaciones frente a la que estaría presente en un conjunto de aplicaciones integradas ? • ¿Cuáles son los costos de mantenimiento de aplicaciones y estimaciones de gastos de apoyo? • ¿Cuáles son los costos de capacitación para las distintas alternativas? • ¿Cuáles son los costos de personal interno durante el proyecto? • ¿Cuáles son los costos ocultos de implementar un ERP? Los responsables de Sistemas de Información Marin y el grupo de tecnología, parecen haber llegado a la conclusión que la implementación total de la aplicación SAP, tendrá un costo de casi el 25 por ciento más, en un período de diez años, que la compra, modificación, implementación y la migración de datos a un nuevo sistema en un proyecto de fases, en un tiempo durante el cual continuarían operando el entorno SAP en paralelo , hasta que se realice el lanzamiento en vivo de los respectivos nuevos módulos del sistema. Su opinión es que nada bueno viene de este tipo de situaciones . Marin parece haber perdido 30 millones de dólares ; DLT se enfrenta a una demanda y mala prensa, la marca y la reputación de SAP sufrirá aunque nadie culpa al software. Conteste lo siguiente: 1. ¿Afectó este caso a SAP? ¿Cómo? 2. Describa las causas que ocasionaron la implementación fallida del sistema considerando los siguientes componentes: fallas en la administración del proyecto, fallas de la empresa en general y del proveedor. Liste al menos 3 fallas de cada elemento. 3. ¿Qué mecanismos se debieron implementar para evitar este caso?
