¿Qué factores llevan al éxito en una implantación de ERP?
Hoy he recibido un link de parte de Carlos Liébana que no puedo dejar de postear aquí:
http://www.expansion.com/2009/09/20/juridico/1253478282.html
El tema va de una gran empresa que contrata a una gran consultora de renombre para implantar el rey de reyes en el mundo de los ERPs propietarios: SAP.
Cualquiera diría que el éxito de esta implantación estaba asegurado teniendo en cuenta las premisas desde las que partían. Al final, han terminado en tribunales y el Juez ha dado la razón al Cliente.
A pesar de no conocer en absoluto la problemática concreta de este caso, ni siquiera empresa y consultora cuyos nombres no se mencionan, voy a atreverme a hacer de pitonisa e intentar adivinar qué pasó. Si alquien me ofreciera apostar algo, quizás no pondría mi mano porque sólo tengo dos pero una buena cena en un buen restaurante sí que me jugaba a que acierto al menos 8 de las 10 razones que voy a poner aquí para que esto acabase como el rosario de la aurora.
- El cliente de entrada ya soltó un pastón antes de empezar, con lo cual espera que absolutamente todo lo que necesita esté como él quiere que esté, no como otro supuso que debería estar.
- Puesto que es una gran empresa, supongamos que son muchos usuarios a formar, muchos procesos a definir, mucha gente opinando sobre cómo debe funcionar algo nuevo que no conocen. Los consultores, en vez de frenar las “quejas” y los “como que esto no lo hace” de los usuarios se dedican como locos a realizar tomas de requerimientos de funcionalidad faltante, que se convierten en desarrollos no previstos inicialmente y por tanto no presupuestados de antemano.
- Los consultores “no conocen” la empresa. Los usuarios no conocen el alcance ni la funcionalidad de la herramienta. Los jefes de proyecto de ambos lados, no se dedican a formarse mutuamente sino que entran al trapo con la implantación.
- Hay usuarios poco habituados a cambiar su forma de trabajar y la imposición de un ERP les parece un “rollo”. ¿Para qué cambiar lo que ya estaba haciendo de alguna forma? ¿Quéeeee? ¿Que algo que con mi excel hacía en 5 minutos ahora tardaré 20 en hacerlo? La utilización de un ERP les descuadra su forma de trabajo habitual pero no se dan cuenta de que posiblemente tarden 20 en configurarlo pero una vez hecho, seguramente a la larga no tardarán 5 minutos, tardarán 30 segundos.
- Volviendo a los desarrollos a medida, se presupuestan mal. La cosa se complica. Las entregas no son en fechas y cuando se instalan no hacen lo que el usuario creía que había pedido y encima dan errores por todas partes. Cuando al final ven que medio funciona, resulta que se ha roto algo que antes funcionaba y ahora hay que arreglar de nuevo lo que ya estaba hecho. La consultora en ningún caso va a regalar estas horas. Las cobra. Más costes ocultos.
- Y volviendo de nuevo a los desarrollos, cuando el usuario ve lo que le han programado que esta vez sí funciona se le ocurren otras 10 mejoras que es “imprescindible” que estén porque si no, no pueden arrancar. Cosa que normalmente salvo en contadas ocasiones no es cierta. SIEMPRE se puede arrancar a no ser que uno necesite perentoriamente el módulo de proyectos y la herramienta sea exclusivamente de contabilidad por ejemplo…
- Es una gran empresa por lo que tenían datos anteriormente en otros sistemas. No quieren tener históricos en otro lado por lo que posiblemente hubo que migrar “todo”. Claro, los datos antiguos están en una estructura de datos que no tiene absolutamente nada que ver con la nueva. El volumen de datos es inmenso y es complicado tener en cuenta toda la casuistica. Cuando migraron por primera vez al entorno de pruebas, había direcciones de un cliente en otro y la numeración de facturas se había desmontado por completo… hay que rehacer los procesos de migración. Más costes ocultos.
- Puesto que la empresa Cliente es enorme, hace falta un batallón de consultores. No es mejor tener 2 buenos que lo hagan bien, que va… si son 10 irá mejor. Pero 10 consultores senior es un pastón, no obstante, te los ponemos. Pero no… resulta que no te van a enviar a 10 de los 20 consultores senior que tienen por lo que te mandan 1 senior y 9 junior que se van formando según avanzan los meses en el Cliente. Los chavales ponen ganas pero es que algunos no se enteran de nada, lo cual en ningún caso es responsabilidad suya sino de quien les ha enviado allí sin estar formados suficientemente.
- Los usuarios están cada mes más quemados con la situación de que aquello no tira ni con un motor turbo y la distancia entre consultores y usuarios es cada vez mayor. El ambiente se hace rancio y trabajar allí es desmotivador y cada vez más complicado. La gente se va y la consultora los sustituye con más gente que se incorpora a un proyecto que no conocen, que está medias y ya viciado. Se tienen que formar y esto es tiempo. Y aquí más costes ocultos porque lo que iba a acabar en ocho meses, ya llevan año y medio y seguimos igual.
- En este caso NO FALLA la herramienta. Cualquiera dirá que SAP es de lo mejor, o al menos, (al hilo de lo que decía en mi post anterior) es lo más caro que hay y la herramienta a nivel mundial que posiblemente tenga más casos de éxito documentado.
Entonces… ¿qué falló? ¿La consultora o el cliente? Pues los dos. Cada uno en la parte que le toca. Una implantación debe ser una simbiosis de las 3 partes. Si falla una sóla, se llegará a implantar, pero si fallan dos… fracaso seguro. Aunque sea SAP.
- El cliente: Primero… conoce la herramienta antes de liarte a pedir cambios que luego no te servirán. No me cansaré de repetirlo. Nadie dice que no hagan falta adaptaciones o desarrollos a medida. Seguro que en función del tamaño de la empresa serán necesarios, pero espérate a conocer la herramienta en su totalidad para pedirlos.
- Los consultores: En estos casos de consultoras grandes, hacen lo que les dicen y ejecutan lo que tienen aleccionado y no lo que creen que deberían hacer, o sea que no digo nada.
- La herramienta: Elige una que cubra la mayor parte de tus necesidades. Si tu sector es muy específico y existe un vertical adecuado, quizás sea ese y no una herramienta generalista lo que necesites.
Me encantaría que alguien que haya estado metido realmente en el caso me diga en cuantos de los puntos he acertado. Si no he llegado a los 8 que decía al principio, le invito a cenar
Y aquí… buscando un pelín más en internet, la sentencia completa para quien tenga el hígado de leerse la parrafada legal!!!
http://estaticos.expansion.com/estaticas/documentos/juridico/sentencias/2009/sentencia_vitoria.pdf
Al loro con las cantidades que barajan ambas partes. O sea, hablan de MILLONES de EUROS… que se piden los unos a los otros por distintos motivos… Millones de euros, habeis leido bien. Tampoco perderse la frase donde dicen que contrataron a esta consultora porque otra consultora fracasó en la implantación de la misma herramienta en esta empresa. En fin, es un tema jugoso. Espero que os animeis a comentarlo y una vez leída la sentencia creo que mi razonamiento anterior de los 10 puntos es bastante simplista. Pero me ratifico en ellos.
Aquí una opinión sobre la noticia que también suscribo:
http://legnita.wordpress.com/2009/09/22/sentencia-judicial-a-tener-en-cuenta/#comment-5594
Tags: éxito implantación erp, Fracaso implantación erp, SAP OpenERP
Septiembre 25th, 2009 at 6:41
Ana:
Gracias por hacer referencia a mi blog en este artículo y por la recopilación que has hecho de errores que una y otra vez se cometen en “casi” todo estos proyectos.
Pero el principio del desastre puede que se situe en el proceso de venta donde se buscan las cifras que el cliente espera escuchar para que todo les cuadre. En esto son responsable tanto el que compra como que el que vende.
Es hora de construir otro tipo de relaciones y contratos en este tipo de proyectos que faciliten las condiciones del éxito en lugar de las condiciones para el fracaso. Si no es posible hacer una valoración en coste y plazo, ¿por qué se hace?. Si es imprescindible la dedicación en x horas por parte del cliente, ¿por qué no se pone en el contrato? Etc., etc.
Algunas herramientas que nos pueden ayudar:
- El libro blanco de la consultoría. http://legnita.wordpress.com/2009/01/21/presentacin-del-libro-blanco-de-la-consultora/
- Metodologís ágiles como SCRUM
- Consultoría artesana http://artesanosenlacumbre.wikispaces.com/
Seguimos en contacto,
Ángel
Septiembre 25th, 2009 at 8:40
Hola Angel:
Encantada de tenerte como comentarista. Bienvenido a nuestro blog también.
Gracias por los links que nos pasas. Por supuesto que les echaré un vistazo. Lo que pasa es que casi todas las metodologías que he estado mirando y evaluando van más por definir y centrar proyectos de desarrollo de software, que no de implantación. Por ejemplo Scrum.
A fin de dar pautas para llevar una implantación a éxito, según mi humilde experiencia, publiqué hace poco un curso en aulaerp precisamente de esto. Metodología y consultoría en la implantación de un ERP. Lo comento por si pudiese interesar a alguien.
En cuanto a lo que decías del contrato y la venta, totalmente de acuerdo. Por esto, nosotros intentamos hacerlo al revés. Primero, el cliente únicamente contrata el análisis inicial de procesos y a partir de ahí y una vez terminado dicho análisis realizamos el plan de implantación y nos atrevemos a presupuestar el proyecto.
Previo a la firma, recomendamos no sólo una demo, sino incluso una maqueta personalizada donde pueda comprobar que la herramienta resuelve si no todas su problemática, sí la gran parte. Y si el Cliente tiene la más mínima duda de que OpenERP le pueda valer. Directamente no implantamos. El cliente inicialmente invierte un dinero en análisis pero se cura en salud, tanto él como nosotros. Y ni que decir tiene que si el cliente considera necesario enviar dicho análisis a otras consultoras que implantan otras herramientas para solicitar demos y presupuestos… adelante. Busque, compare y si encuentra algo mejor, cómprelo!!!
Cordiales saludos!!!
Ana
Septiembre 28th, 2009 at 9:35
Considero muy acertados, tanto el diagnóstico de Ana como las buenas prácticas aportadas por Ángel.
Sin embargo, el proceso de compra-venta es un juego de percepciones donde la razón pasa a un segundo plano. Un ejemplo: una importante empresa necesita un ERP. Argumento de su Director Financiero para haber elegido XXX: “la mayor parte de las empresas del Forbes 500 lo tienen, ¿y no pueden estar equivocadas?”… En el proyecto presentado no figuraba ninguna personalización, a pesar de que su importe inicial superaba los 120 millones de pesetas… tras la “negociación” este presupuesto se redujo en un 25% !!!… seguía sin especificar personalizaciones (a pesar de las más de 50 páginas de contrato)… A todo esto, el comercial no se lo creía: él no había vendido nada, le habían comprado…
El resultado fue el previsible: un desastre que luego tuvieron que resolver otros.
Va a resultar difícil romper esta dinámica. Los grandes invierten mucho en propaganda para crear estados de opinión que ofuscan cualquier planteamiento racional.
De todas formas, algunos, estamos dispuestos a seguir adelante y demostrar que es posible hacer las cosas de otra manera: bien.
Septiembre 30th, 2009 at 4:49
Hello,
I agree that Scrum like and agile methodologies help avoiding such failures. But agile only work for certain kind of software (luckily it’s definitely OpenERP compatible). Agile doesn’t work when developing mean you should outsource (eg sub-contract specifications and hence kill agile) to say India to find some average low profile engineers that can’t refuse killing their neuron on out dated old ERP technologies just because no western engineer will accept to do it anymore for a decent price. When technologies suck so much (like SAP ABAB does, like PL/SQL does…) that development cycles can’t take less than months, agile is almost impossible and you’ll see such “waterfall” failed implementations.
BTW, OpenERP changes the game here. Its decent OOOP/modular technology allows to have very short SCRUM iterations, depending on the customer, it’s even possible to work hand in hand and show new development at least in working prototype stage day after day, hours after hours. Instead of asking for a full boring spec, just fucking do the job, and show it instantly to the customer. After that he simply trust the job can be done easily and it will be done properly, you can spend time tuning the code right to his exact need rather than having some consultants that have no idea about what is possible to code or not or how much it would cost spending days writing tons of useless specs.
With my 3 last OpenERP customers, we worked in such agile ways, avoiding spending time in too much specs and we had the job done in little time for very cheap. Those are happy customers, unlike the one you mention here. One even testimonies here: http://www.erp-infos.com/info_article/m/709/anevia-deploie-openerp-en-moins-de-trois-mois.html
Now I agree, OpenERP will need to mature yet a bit more (1, 2 years?) to be a drop in replacement of SAP in larger companies. But at least OpenERP starts change the game already where you would put SAP AllInOne or M$ Axapta using old waterfall methodologies.
Octubre 2nd, 2009 at 1:18
Aquí un link que me han enviado… suscribiendo lo de las “grandes consultoras” con consultores noveles vendidos como expertos.
http://technology.blogs.ie.edu/2009/09/sap-consultores-desorientados.php
Aquí otro (es del 2007 pero creo que vale para el caso) otro donde de una forma bastante amena nos dan detalles de una “demo de SAP” vivida in situ.
http://6x.velneo.es/292/como-vender-mejor-tu-software-al-cliente-final/
Sobre este último, aprovecho para comentar algunos puntos que ratifican alguna opinión que he incluido yo misma en alguna ocasión, pero sin referirme a ningún producto en concreto…
1. Su objetivo era claro: Ganarse la confianza del cliente , lo de menos el que el programa tuviera más o menos funcionalidades y una cosa que me llamo la atención, la respuesta a todas las preguntas era “Sí, es posible”. –> SIEMPRE es posible hacer todo. Evidentemente. Con una buena cartera, tiempo y un par de programadores expertos… claro que puedes hacer cualquier cosa. En cualquier herramienta, aunque en algunas con más coste y esfuerzo que en otras.
2. En cuanto a la problemática del cliente, trazabilidad de los productos, descomposición de palets, y una gestión de almacén un tanto particular, nada de nada. Pero eso no tenía importancia, ya que según ellos Business One internamente lo tenía todo resuelto. Tan sólo habría que hacer unos desarrollos a medida para integrarlo con el Erp, el cual se facturaría aparte y listo. –> Una de 2… o está resuelto, o requiere desarrollo. NO es compatible decir que está resuelto y que requiere desarrollo. CUIDADO con esto en las demos. Aclarad bien si está resuelto o no lo que necesitais.
3. A cada pregunta un poco especifica, la respuesta era siempre la misma “Eso Sap internamente lo tiene previsto” (Sap con voz hueca e importante) y por tanto no es problema desarrollarlo.
Otro detalle que apareció fue el de la migración de datos actuales, y la repuesta fue rápida. Los clientes y los artículos están incluidos, facturas y demás, no hay problema se hace un presupuesto y se realiza. –> De nuevo… EVIDENTEMENTE!!! Bajo presupuesto cualquiera cosa se puede hacer.
4. La cuestión económica: Fácil y sencilla; aproximadamente 2.000 Euros por licencia (Una por usuario) x 30 Usuarios =60.000 Euros y la implantación. Después 17% de mantenimiento anual, creo recordar. –> Simpático dato. 60.000 de licencias de entrada y luego un 17% de 60000 de mantenimiento anual… y en el precio no pone el coste de la implantación y menos el de los “desarrollos” no presupuestados.
5. Una vez el primer punto claro, firmado y comprado, no había problema, unos consultores analizarían su problemática concreta y se desarrollaría todo lo necesario para que su problemática particular se adaptase al Business One. –> PERO ESTO ES UNA LOCURA!!! NO SE PUEDE cerrar un contrato sin conocer la problemática concreta y sin saber lo que se necesita desarrollar. Así que fracasa, según he leido un porcentaje altísimo de las implantaciones de ERPs en general.
6. ¿Cómo es posible que una empresa en la que están cuestionando un software de 15.000 o 20.000 Euros acaben firmando una operación por más de 100.000 y sin rechistar? –> AMEN!!!!
En fin… no sigo comentando que al final me sale un post en vez de un comentario. MUCHAS GRACIAS POR LOS LINKS!!!
P.D: Sin ánimo de criticar, sería interesante que los pusieseis vosotros mismos en los comentarios de los post. No pasa nada. Wordpress no muerde
Octubre 25th, 2009 at 14:44
Hola,
Excelentes comentarios, estoy 100% de acuerdo con la opinión de que al implementar un ERP siempre hay costos ocultos porque a las consultaras no le interesa de primera presentar una solución completa, si no se concentran en dar soluciones parciales que al final representa más costo, por ello considero que es imprescindible centrarse en los procesos de negocio entender donde estamos parados, con quien contamos (Gente) y darle rumbo con una visión holística (360°), donde nos enfoquemos en los clientes tanto internos como externos, al lograr esto la implementación de cualquier ERP (Microsoft, SAP, Oracle….) es mas “sencillo”.
Lla preparación previa es lo más importante considero que hay es donde se debe enfocar la consultorías dedicarle más tiempo a la planificación y así la ejecución será mucho más rápida.
Un diagrama seria:
Gente — Procesos – Tecnología.
Procesos es la base angular de cualquier implementación de un ERP, si esto no está claro tendremos muchas posibilidades de fracaso, donde el tiempo es nuestro verdugo, acuérdense “Las empresas corren al ritmo del más lento” siendo el mas lento el que tiene menos conocimiento o ganas de aportar al proyecto.
Octubre 25th, 2009 at 15:42
Precisamente es esto lo que intentamos evitar sobremanera los que implantamos OpenERP. Muchos de nosotros venimos de consultoras de ERPs propietarios cuya forma de actuar no nos parece transparente. Su principal objetivo es vender. Sea como sea y lo que sea. No. Paremos aquí. Primero veamos cuales son las necesidades de la empresa y digámosle qué es lo que podemos cubrir de forma standar, incluso de qué forma está cubierta esa necesidad. Contémosle además qué es lo que no está cubierto y a partir de aquí presupuestemos.
El tiempo es relativo. Son tantos los factores que influyen en el retraso del arranque de una implantación que es muy posible que alguno nos toque. Nadie está libre de esto. Muchísimas veces es el propio cliente quien retrasa el arranque. Y es correcto. Solicita tiempo para cargar datos, tiempo para formar internamente a sus usuarios, tiempo para analizar algún proceso que se quedó en el aire con o sin nuestra ayuda. Otras, surgen necesidades nuevas durante la implantación. La implantación es un proceso vivo. Y más en software libre donde existen módulos que no se había contemplado instalar en un principio porque no se vio la necesidad, pero luego se ve que sí. Esto pasa mucho por ejemplo con CRM y RRHH. Inicialmente el Cliente dice… mmm… no. En principio no me interesa esta parte. Una vez que ve todo el resto, ve que śi… ahhh… pues sí que me es útil. Lo ponemos también. Informes… puede ser que inicialmente el Cliente por ahorro de costes prefiera no incluir en el presupuesto la personalización de informes, pero luego se da cuenta de que en realidad es mejor que lo haga un técnico y lo contrata, decidiendo esperar al arranque final hasta tener dichos informes terminados…
Cada implantación es un mundo. Cada empresa pone lo que quiere y puede de su parte para llegar a buen fin. Pero lo cierto es que con un análisis inicial de procesos, una herramienta potente como OpenERP, un Cliente implicado, un equipo técnico profesional y consultores expertos es bastante complicado que una implantación de OpenERP fracase.