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)