Llegamos a ustedes gracias a:



Reportajes y análisis

El ERP salió mal: Lecciones de fracasos

[29/11/2010] Los proyectos de ERP se encuentran entre los esfuerzos más críticos que compromete a TI, al tocar casi todas las operaciones empresariales esenciales y al ser técnicamente complejos. Por ello, no sorprende que algunos fallen espectacularmente. A pesar de que los ERP han estado en el foco de las empresas durante una década, muchas compañías siguen embarcándose en tales esfuerzos, y más aún, tratan de rehacer los ERP, debido a las fusiones y los cambios del negocio. Esto es lo que podemos aprender de los fracasos de los demás y utilizarlos en provecho de sus proyectos.

Me concentro en las implementaciones fallidas de SAP porque los detalles son más fáciles de adquirir, gracias a la enorme presencia de SAP en las grandes empresas de propiedad pública y del gobierno, donde los documentos que rodean los litigios y los principales proyectos cancelados deben hacerse públicos. Sin embargo, las lecciones se aplican a Oracle y otras implementaciones fallidas de ERP.
¿Qué es un fracaso de los proyectos de ERP? No solo el exceso en los costos, sino que es un acontecimiento cuyos efectos son tan grandes que obligan a una empresa a replantear sus ganancias, o una entidad gubernamental a cancelar un proyecto que está bien financiado.
John F. Kennedy dijo una vez: "La victoria tiene mil padres, pero el fracaso es huérfano". En el mundo de los proyectos de ERP, lo contrario es casi siempre cierto: Las fallas tienen un millar de causas. Estas causas casi siempre surgen, señala Michael Krigsman, CEO de la consultora Asuret y un conocido analista de fallas de ERP, debido a la falta de alineación entre las tres partes principales de un proyecto: el cliente, el proveedor de software, y el integrador del sistema.
Fallas del cliente
La falta de adaptación a menudo comienza con problemas en la variable cliente de la ecuación. En su forma más común, consiste en la falta de planificación adecuada. David Bergen, ex CIO de Levi Strauss & Co., quien llevó a cabo varios proyectos SAP en la fábrica de prendas de vestir, dice que la mayoría de las empresas no están preparadas para un proyecto de ERP, porque los pasos básicos no se han realizado adecuadamente. "Las empresas no suelen ser buenas para el cambio. Además, muchas empresas tienen problemas en definir sus procesos de negocio. Los que luchan con el rediseño de procesos tendrán dificultades para alcanzar el éxito y la realización de los beneficios".
Un tema recurrente en los proyectos fallidos es la extralimitación por parte del cliente. Esta ambición es a menudo alimentada por los integradores y proveedores de software, que tienden a crear escenarios improbables de éxito y fomentan proyectos de gran tamaño.
Un ejemplo de ello le ocurrió a Shane, una joyería con 200 millones de dólares en ventas. En 2006, la compañía llevó a cabo un proyecto ERP de 36 millones de dólares que estuvo enlatado por tres años. Este fue un proyecto de enorme tamaño y probablemente demasiado grande para la compañía, señala la firma de asesoría ERP, Panorama Consulting. Su encuesta de 1.300 implementaciones de ERP llega a la conclusión de que la empresa promedio gasta un 9% de sus ingresos anuales en un proyecto de ERP -Shane gastó el doble. Shane se declaró en bancarrota en el 2009, culpando en parte al exceso de gastos en su incompleta aplicación ERP.
Sin embargo, incluso una vez que un proyecto está bien planteado y puesto en marcha con un plan validado, con frecuencia los clientes no pueden gestionar el proyecto correctamente. Normalmente, esto toma la forma de malas decisiones, impulsando las tareas que el cliente debe realizar sobre el personal del integrador, y no manteniendo al integrador en el plan del proyecto, los horarios, y sobre todo, los presupuestos. Cuando una empresa con una gestión deficiente del proyecto se asocia con un integrador que no entrega las especificaciones técnicas, puede acarrear un desastre en la venta al por mayor.
Un ejemplo de esto es FoxMeyer, un distribuidor de medicinas de cinco mil millones de dólares -el cuarto más grande en los Estados Unidos. El equipo directivo fue uno de los primeros y ruidosos impulsadores de un proyecto de ERP para racionalizar las operaciones de almacén. A pesar de las advertencias de que el calendario de aplicación era demasiado agresivo, la empresa siguió adelante y firmó un acuerdo enorme de distribución de medicamentos y redujo drásticamente el precio de sus productos en anticipación de la finalización del proyecto.
El proyecto, sin embargo, cada vez se retrasaba más. Los retrasos se agravaron por las exigencias cambiantes y los procesos de negocio a consecuencia del nuevo acuerdo. Mientras la situación empeoraba, los consultores de gestión sugirieron que el proyecto se redujera y se ejecutará por fases. Sin embargo, el CEO y CIO, que tanto apoyaron la conversión de ERP, dijeron que habían "apostado la casa" en el proyecto y en su lugar optaron por ampliarlo. Esta decisión aceleró el fracaso, y en un plazo de dos años, la compañía se vio obligada a declararse en bancarrota.
Un estudio realizado por Judy Scott (entonces en la Escuela de Negocios de la Universidad de Texas) concluye que FoxMeyer fue un fracaso de la administración. El empleo de consultores sin experiencia por el integrador principal, Andersen Consulting, fue un factor que contribuyó, señala ella, pero el factor que selló el destino del proyecto fue la incapacidad de la administración para recuperar el control del proyecto y tomar las decisiones indicadas. Los proyectos exitosos requieren un manejo sensible, reflexivo.
Fallas del integrador del sistema
Debido a que los integradores hacen el trabajo de implementación, con frecuencia son una parte integral de todas las fallas del proyecto. Sus principales ofensas tienden a consistir en el uso de consultores que no están suficientemente capacitados en los paquetes que están instalando -a veces incluso en aspectos básicos de ERP- y tienden a ser pobres en regularse a ellos mismos. Ambos factores derivan directamente en cómo los integradores cargan: por hora. (Pocos contratos son buenas ofertas.) Como resultado, el personal más barato que puede hacer el trabajo resulta el mayor beneficiado, mientras que implementando tareas adicionales produce un compromiso más rentable.
El conflicto de intereses inherente entre el integrador y el cliente es una fuente frecuente de controversia, no solo entre los dos partes, sino que con el proveedor de software también. En el 2009, por ejemplo, Léo Apotheker, el entonces director general de SAP (y ahora consejero delegado de Hewlett-Packard), condenó en términos muy contundentes como el interés propio de los integradores (en este caso, Accenture e IBM), llevó a proyectos fallidos que se reflejaban negativamente en el software, en lugar de hacerlo en los integradores. "No me importa si se trata de Accenture o IBM... Me parece notable que la gente [los integradores] estén andando por ahí hablando con los clientes y no tengan experiencia. [Ellos] no tienen ni idea. Es muy molesto, pero eso es un hecho".
La práctica de los integradores de enviar consultores sin experiencia es tan dominante que casi todos los pleitos en los proyectos de ERP la mencionan como una causa de acción. Greg Hatch, director gerente de Alvarez & Marsal Business Consulting, una firma que ofrece servicios de asesoramiento a clientes en grandes proyectos de ERP, afirma que este problema se deriva en parte de una percepción equivocada de los integradores: "Se puede ver como la participación de una empresa, pero realmente debe verse como la contratación de un equipo de personas. Se debe entrevistar al personal de categoría superior, como el director del proyecto y jefes de equipo, y estudiar las hojas de vida de los demás. Asegúrese de que no solo tenga relevancia la experiencia de ERP, pero lo ideal es que hayan hecho proyectos ERP en su industria en particular".
Como cliente, debe abordar el problema de los plazos extendidos a través de una fuerte gestión del proyecto. Debe resistir activamente la tentación de empujar el calendario debido a problemas inesperados o des-proyecciones de tiempo y recursos. Cada retraso es síntoma de un problema mayor, y el equipo de gestión de proyectos, con el integrador, tiene que averiguar lo que está mal y arreglarlo.
Hatch observa: "Los proyectos no van al sur, de repente, al final. Ellos siempre han estado languideciendo poco a poco. Esta "muerte por mil cortes" tiene que ser abordada con prontitud por el equipo de gestión de proyectos del cliente".
Fallas de los vendedores de software
Los proveedores de software, como SAP y Oracle, tienden a ser culpados por los pecados de sus vendedores -es decir, prometiendo características o software que no existen o no se pueden entregar. En muchos casos, esto es simplemente una verdad extendida o una representación excesivamente ambiciosa de los beneficios, pero de vez en cuando, los proveedores pueden bajar el acantilado por completo.
Consideremos el caso del gigante de procesamiento de basura Waste Management, que demandó a SAP por fraude en un fracasado proyecto de ERP en el 2008. En su demanda afirmaba que SAP había mostrado un software que era una solución "fuera de la caja" para las necesidades de la empresa. En cambio, el software, según la compañía, fue "una versión maqueta de aquel software con la intención de engañar a Waste Management". El "software falso" fue utilizado en varias ocasiones en demostraciones para los ejecutivos de la empresa. El pleito de Waste Management se liquidó a principios de este año, con SAP pagando una liquidación en efectivo.
Hatch comenta que escenarios similares pueden ser evitados -en gran parte- consiguiendo compromisos por escrito. Además, dice, "la demostración debe hacerse con secuencias de comandos utilizando los datos específicos del cliente y de la industria, no una aplicación genérica". Y, añade, que con un proveedor Tier 1 de ERP (SAP y Oracle), usted debería ser capaz de obtener referencias a otras implementaciones que la empresa ha hecho en su segmento de la industria. Si existe un paquete para su industria, úselo sin personalizarlo hasta el punto de hacerlo irreconocible.
Krigsman está de acuerdo: "Una de las cosas por las que está pagando a una empresa como SAP es su conocimiento de los procesos de negocio en su sector. Su software normalmente encarna las mejores prácticas, por lo que en la medida de lo posible, evite escribir código personalizado, y en su lugar, donde sea posible, cambie sus procesos de negocio para alinearlos con el paquete de ERP.
Triada compleja ERP: Haciéndolo bien
La alineación de la necesidad del cliente, el software del proveedor, y la implementación del integrador es una tríada muy compleja, cuya naturaleza dinámica requiere que todas las partes -el cliente, sobre todo- monitoreen la actividad cuidadosamente y respondan de forma inmediata cuando se produzcan problemas.
Pero incluso los gerentes que están bien versados en las implementaciones de ERP pueden incurrir en problemas graves e inesperados. Considere a Hewlett-Packard, una empresa que en el momento de su fracaso interno de SAP tenía una unidad de negocio, que consultaba sobre los proyectos SAP. La fallida implementación le costó a HP 400 millones de dólares en los ingresos del tercer trimestre. Según un artículo de Register.co.uk, "empleados de HP se mantenían sobre camiones de 18 ruedas etiquetando a mano los traslados de servidores Superdome de millones de dólares y similares. Los ejecutivos de alto rango estaban obligados a pasar su tiempo aprobando pedidos urgentes de 50 dólares en partes a los clientes clave".
Como varios analistas señalan, no importa cuán bueno sea usted, los proyectos de ERP son difíciles. Sin embargo, hay algunos consejos en los que los consultores y analistas están de acuerdo.
Definir el proyecto por completo. Entender lo que la empresa debe hacer antes, durante y después de los proyectos. Algunas de las actividades que preceden a un proyecto son completar las migraciones hacia nuevos sistemas, documentar los procesos del negocio, y la limpieza de datos.
Una falla en el suministro de datos limpios puede ser costosa. En el 2008, los manifestantes salieron a las calles de Los Ángeles para protestar contra un proyecto de nómina que llevó a que algunos profesores sean pagados en exceso, otros mal pagados, y otros sin paga. Una de las causas fue, según una investigación realizada por Los Angeles Times, "años de mala calidad en el mantenimiento de registros y una compleja unión de contratos haciendo que las preguntas básicas -incluyendo a cuánta gente se debe pagar y en qué puestos de trabajo- sean casi imposibles de responder. Como muchos consultores señalan, las preguntas deberían haber sido contestadas antes de que el proyecto se llevara a cabo. La preparación paga bien en los proyectos de ERP.
Elija al proveedor con cuidado. Bergen recomienda que las empresas que carecen de una amplia experiencia en proyectos ERP contraten a consultores no afiliados, ya sea con el vendedor o el integrador potencial para asesorar al cliente con la planificación y ejecución. Un beneficio clave de estos asesores es que facilitan el diálogo entre los clientes, integradores y vendedores, y se aseguran de que la solución propuesta se adapte a las necesidades de la empresa. Los buenos asesores sabrán lo que está faltando en un contrato y serán capaces de verificar que está recibiendo lo que usted piensa que está recibiendo. Krigsman subraya la necesidad de obtener todas las promesas sobre el software y la aplicación por escrito.
Elija el integrador con mucho cuidado. Normalmente, el integrador trae al proveedor de software, por lo que el aviso previo en la selección del proveedor es aún más crítico cuando se selecciona el integrador. Entreviste a los altos funcionarios y repase las hojas de vida de los demás participantes. Asegúrese de que tienen experiencia en el segmento de la industria.
Prepare un equipo fuerte para que supervise el proyecto. El equipo debe incluir al CEO, CIO, los jefes de las líneas afectadas del negocio, el oficial de gestión de proyectos (que es con frecuencia un asesor externo), y cualquier patrocinador principal del proyecto, informa Hatch. La integración de los ejecutivos de negocios en el equipo es crucial para el éxito, señala Ross Wainwright, vicepresidente ejecutivo de servicios profesionales de SAP América del Norte. "Una aplicación ERP es un proceso de negocio, no un proyecto de TI", señala.
Muchas de las prácticas sugeridas de SAP se centran en el equipo del proyecto. La clave es su autoridad para actuar en dos ámbitos importantes: el rechazo (o aprobación) de las solicitudes para alcanzar la aprobación y pidiendo al integrador y al personal de TI que expliquen y resuelvan los retrasos, las etapas perdidas y excedentes del presupuesto. Sin esta autorización, el proyecto seguramente se desviará de su curso.
Gestionar activamente el proyecto. Los proyectos de ERP son casi siempre muy amplios, por lo que es tentador no darles una atención constante. Pero el éxito está en los detalles. Los miembros del equipo deben estar recibiendo actualizaciones constantes sobre los avances y problemas. Si surge un problema importante, los miembros disponibles del equipo de supervisión deben ser convocados y tomar una decisión. Todo el equipo, según Hatch, debe reunirse como mínimo una vez al mes. Wainright añade que las corrientes en el proyecto deben ser claras y fáciles de entender, ya que esto facilita las correcciones rápidamente.
Comprender el impacto en el negocio. Los proyectos de ERP en general, tienen un impacto profundo en muchas de las funciones internas de la empresa. Es por eso que los efectos de los grandes proyectos tienen que ser entendidos y previstos desde el principio, señala Pam Daniels, quien encabeza Stylus Group, una consultoría de desarrollo organizacional. "La gestión del cambio es una práctica fundamental que debe acompañar a los proyectos ERP desde el principio hasta el final. Se continúa incluso después de que los consultores han dejado las instalaciones", agrega. Si se descuida la gestión del cambio, los empleados pueden resistirse al nuevo software o usarlo mínimamente. De cualquier manera, los beneficios del proyecto son inferiores incluso si se trata de un éxito técnico.
No escatimar en la formación. Una de las formas más dramáticas de rendimientos decrecientes es la capacitación insuficiente de los usuarios del nuevo software. En el modelo de formación más común, el integrador redacta la documentación sobre las distintas partes a medida del paquete, y luego se entrena a los capacitadores, que en última instancia, formarán a los usuarios. Pero el modelo de formación de formadores se rompe cuando el personal del cliente no se desempeña bien capacitando, señala Jennifer Jackson, de Elliott Jackson Communications, que se especializa en lanzamientos de formación de SAP. Ella prefiere un método en el que el personal del cliente participe activamente con instructores externos en las reuniones de información, por lo que las sesiones de entrenamiento pueden ser muy específicas para la empresa, mientras se base en la experiencia del entrenador externo con el software de SAP.
Jackson agrega que todo entrenamiento con demasiada frecuencia es precipitado y que las empresas no dan tiempo a los instructores para que practiquen o perfeccionen su experiencia en capacitar. Teniendo en cuenta que el beneficio final del proyecto ERP se basa en el uso que hacen los empleados del software, ella advierte sobre tomar atajos en la formación o apurar el programa de entrenamiento.
Incluso si sigue este consejo, no hay garantía de éxito, por desgracia. Pero es más probable que pueda evitar el fracaso con una adecuada planificación, la supervisión activa del proyecto y una rigurosa gestión del cambio.
Andrew Binstock, InfoWorld (US)

COMENTARIOS
jcgamarr   mié, 01-dic-10

Este articulo ratifica mi experiencia en proyectos informaticos: No se puede iniciar un proyecto sino se tiene claro un mapa de los objetivos y alcances del mismo.

vladimir   mar, 30-nov-10

Excelente publicacion. Muy buenos los ejemplos y lecciones. Un pequeño detalle: falta un "continuar leyendo" al pie del articulo, por poco no me doy cuenta del detalle y me pierdo las otras paginas.


Leer más comentarios | Realizar un comentario