EVALUANDO SOFTWAREParece que haymetodologías paraimplementar unERP que fallanDebate de expertos de la industriaEvaluando S...
¿Por qué fallan las metodologías para implementar un ERP?Seguramente escucharon alguna vez esta frase: "Compramos las lice...
más los factores que atentan contra el éxito final. Lo que sí es cierto que lasveces que nos hemos apegado más a seguir un...
en un determinado rol o en una determinada área, hace que el enlace entrelos miembros del equipo sea algo más complejo. En...
más de una ocasión, no son las adecuadas. El compromiso de los componentesdel equipo, además del compromiso de la alta dir...
un software empresarial. O sea, mucho antes de la preventa, y muchísimoantes de haber vendido el software. Sobre todo si e...
los consultores de preventa tienen una experiencia más dilatada y por lo tantoson mucho más flexibles a la hora de buscar ...
•   Una primera causa es que no se explicitan en el momento de la venta       los costos complementarios que significan pa...
de acuerdo a mi trayectoria.Yo soy de los que opino que un proyecto no empieza en fase de preventa, sinoantes, cuando una ...
•   La metodología debe ser flexible y adecuarse a la realidad.   •   Debe integrarse con un cierto nivel de "coaching" de...
Y ahí aparece uno de los tantos factores de riesgo que pueden hacer extenderel proyecto.Como bien dice Miguel, los cliente...
Próxima SlideShare
Cargando en…5
×

Por qué fallan las metodologías de implementación

651 visualizaciones

Publicado el

0 comentarios
0 recomendaciones
Estadísticas
Notas
  • Sé el primero en comentar

  • Sé el primero en recomendar esto

Sin descargas
Visualizaciones
Visualizaciones totales
651
En SlideShare
0
De insertados
0
Número de insertados
1
Acciones
Compartido
0
Descargas
9
Comentarios
0
Recomendaciones
0
Insertados 0
No insertados

No hay notas en la diapositiva.

Por qué fallan las metodologías de implementación

  1. 1. EVALUANDO SOFTWAREParece que haymetodologías paraimplementar unERP que fallanDebate de expertos de la industriaEvaluando Software 1
  2. 2. ¿Por qué fallan las metodologías para implementar un ERP?Seguramente escucharon alguna vez esta frase: "Compramos las licencias delsoftware ERP y comenzamos a implementarlo, pero no pudimos terminar elproyecto, era muy complejo para nosotros. Preferimos volver al software queestábamos usando…"Las empresas que venden o implementan software de gestión empresarial -ERP, Enterprise Resource Planning- dicen tener metodología para hacerlo.Pero, ¿Donde comienza la metodología? ¿En la etapa de preventa o cuando elsoftware ya está vendido? Y si tienen metodologías ¿Por qué los proyectossiguen excediéndose en tiempo y presupuesto?Según Darwin Hava Pezo -Consultor Técnico EBS Oracle en HSP SAC Perú-“La metodología debe comenzar en la preventa con la identificación de losprocesos que se realizan en la empresa, para poder seleccionaradecuadamente un ERP que se pueda implementar acorde a esa compañía.Pero para esto es necesario también entender que el costo de apropiación deesta nueva herramienta es bastante elevado por tratarse de un software degestión empresarial, y la primera etapa siempre demandará un mayoresfuerzo”, aclara.José María Renedo -IT DIRECTOR at TOPSALES Barcelona, España- tambiénopina que “la metodología debería comenzar en la preventa para que ambaspartes, tanto proveedor como cliente, tengan más claro ante lo que se van aenfrentar. De esta forma el proveedor podrá hacer una planificación másadecuada y el cliente se habrá visto obligado a hacer una reflexión másexacta de lo que quiere”, asegura.“Pero en todo caso, siendo ese el camino deseable, luego te encuentras con larealidad, que te dice que en muchas ocasiones el proveedor lo que quiere esimplementar su ERP y por lo tanto, “primero que firme el cliente, y luegohacemos el estudio pormenorizado...”; y la otra realidad es que al cliente lecuesta hacer una reflexión detallada antes de firmar el proyecto, ya que estareflexión le consume mucho tiempo”, reconoce José María de acuerdo a suexperiencia.“Yo creo que así como el proveedor quiere colocar su ERP, hay clientes queson ansiosos, y otros que no tienen mucha idea de lo que están comprando ycreen que trabajar en la etapa previa a la compra es una pérdida de tiempo.Por otra parte, si la metodología comienza en la preventa, el vendor ¿Noestaría asumiendo costo y riesgo alto sin tener la más mínima señal delcomprador?”, cuestiona Daniel Aisemberg, Director de Evaluando Software.Carlos Rosignoli -Lider de Proyecto en Datasul, Argentina- expresa que“Desde mi posición he pasado por diferentes resultados en la implementaciónde nuestro ERP. No creo que se le pueda otorgar toda la responsabilidad a lametodología. Nada nos asegura el éxito por seguirla, y creo que son muchos 2
  3. 3. más los factores que atentan contra el éxito final. Lo que sí es cierto que lasveces que nos hemos apegado más a seguir una metodología, tuvimosimplementaciones muy controladas, prolijas y exitosas. Si bien no logarantiza, es mucho más cómodo trabajar así, tanto para el cliente como paranosotros”.Para Juan Ramón Caballero - Director Delegación de Catalunya en EXCELIABarcelona, España- “Esa no es la solución, porque no hay una metodologíastandard para la implantación de cualquier solución tecnológica... yevidentemente, tendríamos que multiplicar el numero de especialistas en laempresa, por el número de tecnologías a implantar... Creo que si las dospartes fueran con los conceptos y objetivos claros, con la sinceridad necesariay con el sentido común que siempre ha de imperar en cualquier relaciónprofesional, el porcentaje de proyectos exitosos aumentaríaconsiderablemente”.Manuel Rodriguez Peon -Senior Consultant at Indra Madrid, España- no estádel todo de acuerdo, y considera que “El tema de la metodología no es tanimportante como parece. En los proyectos de implementación de un ERP(Enterprise Resource Planning) siempre hay 2 perfiles: los denominados"funcionales" y los “técnicos”.“Para mi es importante que esas dos partes estén bien ensambladas y queademás tengan algún conocimiento de la otra para reducir el tiempo dedesarrollo de las adaptaciones. Un buen consultor tiene que saber detectar losprocesos de un cliente y adaptarlos a la empresa, y además tiene que tener elsuficiente conocimiento técnico de la herramienta y del diseño tecnológicopara que al programador no le toque hacerlo todo.Pero esto se adquiere de una forma no estandarizada, sino que se basa en losproyectos que el consultor lleve a sus espaldas que le den un expertise en lamateria”, expresa.“El método de implementación es como máximo una hoja de ruta con la querellenar el calendario de actividades y poder verificarlas. Normalmente lasadaptaciones y las complejidades del cliente hacen que los proyectos sigancaminos muy distintos. En eso se basa la interacción con el cliente. Por muybuena metodología que tengas, los problemas en un proyecto aparecen, y esahí cuando todo ese método no sirve y empieza la improvisación, basada en laexperiencia, claro.Las mejores prácticas en la implantación de un ERP muchas veces apenas seconocen fuera de la consultora que las ha ido desarrollando, y a veces selimitan a un "Paper" o como mucho a un Caso de Éxito que apenas aportainformación. Me parece que las metodologías sólo implican un cambio si lacasa matriz las pone como recomendaciones y las sistematiza”, opina Manuel.“Es cierto que hay ERPs que posibilitan más esto que otros, ya que los equiposson más pequeños y el consultor funcional tiene que saber un poco de todo.En los grandes proyectos de implantación a veces el exceso de especialización 3
  4. 4. en un determinado rol o en una determinada área, hace que el enlace entrelos miembros del equipo sea algo más complejo. En este caso la metodologíase impone como una forma de estructurar todo ese trabajo de mucha genteque sólo ve parte de las cosas. Allí, es necesaria una visión de conjunto, unmanager con conocimientos funcionales que sepa ver las generalidades. Estolamentablemente lo he visto sólo en raras ocasiones”.Miguel Castella -Socio en CCQ Barcelona, España- disiente respecto a laopinión de Manuel, ya que considera que “A lo largo de los últimos 25 años, seha conseguido reducir significativamente la tasa de fracasos en laimplantación de ERPs, definiendo fracaso como no logro de la puesta enproducción de un ERP o la no supervivencia del mismo.Y esto ha sido básicamente por dos cosas:Dejar de mezclar reingenierías de procesos de negocio e implantación de ERP,y por la consolidación de las metodologías de implantación.Coincido sí en que la mayoría de las actividades que se desarrollan en elsector informático son artesanales, y en ese contexto es sumamenteimportante poseer inteligencia emocional y experiencias previas.Pero, si se desea poder llevar a cabo los proyectos sin que se dependa de lainteligencia emocional o la suerte u otros factores parecidos, deberemostomar el camino de la estandarización y la repetibilidad de procesos”,sostiene Miguel.“Una metodología no es mas que un conjunto de salvaguardas que minimizano eliminan la posibilidad de materialización de una amenaza. A lo largo deestas decenas de años se han ido consolidando las mejores practicas enimplantación de ERP (Enterprise Resource Planning), y si se siguen estasreglas es mucho más fácil llevar a buen puerto el proyecto”, concluye.“Sin embargo, yo creo que las metodologías son muy positivas, aunquetambién considero que son el aspecto "hard" de la implementación”, confiesaDaniel.“Hay un hecho que se estudia poco en las implementaciones, aunque se hablamucho de ello. Me refiero al encuentro de dos (a veces más) culturasempresariales diferentes. Este sería el lado "soft". No he visto ningún Plan deProyecto que incluya este tema, ya sea como un factor de riesgo y, menosaún, con actividades concretas dentro del Plan para unir ambas culturas. Debeser por varias razones, y tal vez una de ellas sea el costo”, piensa.Juan Martínez Pérez – Business Developement en Own Business Barcelona,España- coincide con Daniel en que la metodología es muy importante, peroaclara que muchas veces los fracasos son externos a ella.“Para mí hay otros factores que intervienen:1- El primero: no hay que olvidar que el equipo de proyecto lo componenpersonas, tanto de la empresa implementadora como del propio cliente, y en 4
  5. 5. más de una ocasión, no son las adecuadas. El compromiso de los componentesdel equipo, además del compromiso de la alta dirección del cliente con elproyecto, son claves.2- El segundo, y en esto coincido con los que indican que la metodología seinicia desde la preventa (incluso desde la venta), es identificar los objetivosdel proyecto de forma correcta, así como entender los procesos del cliente yno querer siempre construir el “sistema de la NASA”, cosa a la que se sientententados muchos consultores. A veces no hace falta y es hastacontraproducente.3- Finalmente, el hecho de que el precio es muchas veces un factor decisorio,lo que impacta directamente en la cantidad de horas que invierte elimplantador en el proyecto y, por supuesto, a menos horas, menos estricta esla metodología que se aplica. Grandes metodologías son válidas para grandesproyectos, pero esto no siempre es factible.Sergio Yazyi -System Integration and SAP ERP Financials ConsultantSalamanca, España-, afirma que “sin duda el centro cambió de lametodología a las personas. Imaginemos un proyecto con los mejoresconsultores y los mejores usuarios claves, acompañados de otras tantaspersonas adecuadas, con un sponsor que provee los límites y recursoscorrespondientes. Pienso que en este caso la metodología pasa a ser menosrelevante, casi surgiría por sí misma ,producto de la experiencia, y ademássería adaptada con rapidez al caso concreto donde hiciera falta, con el fin decumplir el objetivo de valor -expectativa claramente definida desde lapreventa, sin duda-Me parece clara la importancia de las personas, igualmente clara la dificultadde lograr tal equipo. Pero ¿puede una metodología ayudar a suplir lainadecuación al nivel qué sea? ¿Puede la metodología producir roles rígidosque dificulten la comunicación y la iniciativa? ¿Puede una persona, grupo o roldefinido, ser responsable de intervenir para promover la adecuación en ladinámica del equipo? ¿Han visto que esto ocurra naturalmente oinformalmente en algún proyecto exitoso?Miquel Castella interviene nuevamente en el debate, y expresa que “Lo queocurre es que el hecho de provocar que se cumplan esos factores formaríaparte de la metodología en sí: efectuar un conjunto de actividades de formaque los elementos que intervienen en un proyecto sean los adecuados para lascaracterísticas de ese proyecto, de forma que minimicen las posibilidades o elimpacto que la materialización de amenazas puedan producir....Y evidentemente, en primer plano están las personas, y también el azar yotros imponderables.Considero que habrá que corregir el rumbo, pero si existen los sensoresadecuados –metodologías- se podrá corregir con mas anticipación y masprecisión, para minimizar el impacto”, asegura.Según la opinión de Andrea Manna - Chief Software Architect en Uppersoft-“La metodología debe existir desde que comienzas a planear el desarrollo de 5
  6. 6. un software empresarial. O sea, mucho antes de la preventa, y muchísimoantes de haber vendido el software. Sobre todo si estamos hablando deimplementación de licencias que ya están desarrolladas y cuyaimplementación en el cliente se refiere a personalizaciones o módulosespecíficos.Pero para que esto funcione, toda la aplicación debe haber sido desarrolladautilizando una prolija y bien pensada metología. De otro modo, con el tiemporesulta imposible sostener las personalizaciones a clientes, y comoconsecuencia de esto, el proyecto se estanca, no se termina, o termina mal”.Actualmente existen muchas empresas en el mercado que tienenmetodologías de desarrollo de software. Incluso, más de una, alcanzócertificación CMMI. Sin embargo, cuando llega el momento de ejecutar oimplementar el producto que desarrollaron, las cosas no siempre salen bien.Es evidente que, teniendo certificaciones de desarrollo, no se puede cargarmuchas tintas sobre el producto. El hecho que la implementación de muybuenos productos funcionales y/o tecnológicos se altere, en tiempo y/opresupuesto, nos hace pensar que la forma de implementarlo falló. Y esasfallas pueden ser de una o de las dos partes.Por eso, a la pegunta inicial ¿Donde debe comenzar la metodología deimplementación?, le agregamos: ¿De qué sirve tener la mejor metodología,la más documentada, la mejor desarrollada si los intérpretes no son losadecuados?Oscar González -Presales Manager at CDC Software- “Bajo mi punto de vistala implantación de un proyecto de gestión, sea en el ámbito que sea (CRM,ERP) comienza en la preventa.En muchas ocasiones las compañías tienen sus departamentos demasiadodesconectados, es decir, el preventas hace su trabajo hasta la firma y seretira del cliente para que entre la gente de servicios (con lo que todoempieza de nuevo). Esto es un error. Los responsables de la cuenta a nivel desoluciones (preventas, product managers...etc.) deberían continuar enrelación con el cliente durante todo el proceso de implantación.Esto tiene varias ventajas:1-. El cliente no nota un corte durante el proceso.2-. La persona que ha propuesta una solución debe guiar a las personas deservicios durante todo el proceso de diseño práctica de dicha solución.3-. Estará atento a nuevas oportunidades de negocio en el cliente, por lo quefavorece la venta repetitiva en dicho cliente.Por supuesto en grandes sistemas otra ventaja añadida es que normalmente 6
  7. 7. los consultores de preventa tienen una experiencia más dilatada y por lo tantoson mucho más flexibles a la hora de buscar soluciones a problemas, por loque pueden ser una gran ayuda durante la definición e implantación de unproyecto.Albert Condal –Director de Ventas de EXCELIUM- “Coincido con Oscar en quelas empresas fabricantes de software y las empresas que nos dedicamos avenderlas e implementarlas debemos trabajar en equipo y de ser posible, conmétodos parecidos. Igualmente, y sé que esto es muy difícil en la actualidad,debemos ser aún más profesionales, rigurosos y honestos con el cliente en elproceso de pre-venta, venta e implantación y hacerle ver y entender loscambios que se pueden producir a todos los niveles de la organización, yayudarle a afrontarlos.Cualquier buen servicio tiene unos costes implícitos, y esa también es unarealidad y una gran responsabilidad que tenemos y que debemos sabertransmitir a los clientes "en vez de vender a cualquier coste", ya que de locontrario seguiremos sufriendo los mismos problemas y la incomprensión hacianuestro sector, y perjudicamos al fabricante, a nosotros mismos y sobre todoal cliente”, afirma.Sergio Broutvaien -CEO en Maer Software- considera que “Se está dejandode lado al actor principal que es el usuario. Generalmente, la decisión decompra de un ERP viene de los mandos medios con un aval económico de ladirección de la empresa. Con suerte, estaremos siendo apoyados por lagerencia de sistemas del cliente (si es que esta gerencia existe). Pero a lahora de implementar, nos encontramos con los usuarios, a los que,generalmente nada se les preguntó sobre sus preferencias, se les agregatrabajo por la nueva implementación y se pretende que aprendan algo que noles interesa, en tiempo récord, para reemplazar algo con lo que ya se sentíancómodos”, reconoce.“En definitiva, sin duda alguna para mi, la metodología es un post venta derespuesta inmediata, amable, paciente y que acompaña el aprendizaje de losusuarios finales”. “Es cierto lo que mencionas con relación al usuario”, agrega Daniel. “Creoque él debe ser considerado en cualquier metodología. Pero aquí tiene muchoque ver el estilo de management de cada empresa. Una cosa es cuando se lesinforma "Hemos comprado un sistema" y otra es cuando se les presenta elproyecto que llevará a la empresa a otros niveles. Insisto que esto depende dela empresa, del proyecto y del tipo de gerenciamiento que se tenga”.Marino Alejandro Correa - Consultor en Nodum S.A.- “En mi experienciacomo consultor he participado en implementaciones de proyectos que vandesde muy buenas hasta muy malas. Del análisis que hago encuentro que engeneral, aquellas implementaciones que no han sido satisfactorias respondena varias causas: 7
  8. 8. • Una primera causa es que no se explicitan en el momento de la venta los costos complementarios que significan para el cliente la implementación del ERP dando por sentado de que el cliente ese tema lo visualiza al momento de tomar la decisión de compra. • Una segunda causa a destacar es una insuficiente definición del alcance del proyecto y de la metodología a emplearse para cumplir las diferentes etapas del mismo lo que hace que cuando existen culturas empresariales diferentes entre la empresa proveedora y el cliente el proyecto no avance como debería. • Una tercera causa es la falta de una gestión del cambio del proyecto desde el lado del cliente. Esto esta muy ligado a lo que he planteado como primera causa. • Una cuarta causa que he identificado es no tomar en cuenta en el proyecto como inciden los intereses de terceras partes (usuarios del sistema, clientes y proveedores de la empresa cliente) • Y una quinta y última causa es una deficiente gestión del proyecto de ambas partes (empresas proveedoras y clientes) al no tomar en cuenta los riesgos del mismo.Daniel Valletta -Presidente en Baires Business Consulting- considera que “Elsecreto para una implementación exitosa es entender la cultura de la empresay la fortaleza para adaptarse al cambio, identificando los interlocutoresválidos que se inician en nuestro proceso de generación del negocio.Este análisis debería realizarse desde la concepción del Lead, para llegarpreparado al proceso de preventa con todo el conocimiento necesario parallegar al objetivo primario, que es la venta.Incluso algunas empresas identifican la necesidad de hacer una consultoríaprevia, que les permita llegar con los procesos claros y documentados, para laincorporación del ERP, para lo cual se pone a disposición el equipo de RRHH.Pero no siempre se da este ideal. A la Pyme, por ejemplo, le cuesta invertiren la mejora de procesos.Ya en el cierre de la venta, el Director de TI debería participar activamentedel proceso para evaluar puntualmente las necesidades de la compañía versusla solución, y poder detectar de antemano los deltas que luego seránevaluados internamente, lo que permitiría una cotización clara y con losmenos costos ocultos posibles.Si bien sería utópico decir que esta metodología resuelve los problemas, escierto que ayuda a acotarlos en costos y tiempos.Otros factores pueden incidir, son la adopción del conocimiento de una nuevaherramienta, la resistencia al cambio, la falta de comunicación, etc.”,comparte Daniel Valletta, de acuerdo a su experiencia.Riccardo Facchini – Gerente en Enterprise Architect- “Si bien coincido conel enfoque que adquirió el debate, me gustaría añadir una mirada deferente 8
  9. 9. de acuerdo a mi trayectoria.Yo soy de los que opino que un proyecto no empieza en fase de preventa, sinoantes, cuando una empresa toma la decisión interna de implementar un nuevosistema de gestión: ERP, BI, CRM, etc.Cuando era director de TI de una multinacional, tuve la ocasión de estar enesa toma de decisión, y para ello adopté una metodología holística nodemasiado conocida en Europa. La ventaja está en que esta metodologíaataca justamente las principales causas de fracaso en un proyecto:- Resistencia interna de la organización al cambio.- Falta o inadecuación del Sponsor del proyecto.- Expectativas irreales.- Alcance no definido.Además de minimizar los otros factores clásicos:- Mala gestión de proyecto.- Falta de preparación del equipo.- Mala gestión del cambio.- Falta de visión de conjunto.- Falta de motivación.Una de las grandes ventajas para el integrador es que le deja libertad paraimplementar según la metodología con la que se encuentre más cómodo, asícomo actuar de facilitador en la fase de preventa y posterior implantación.Para el cliente, la ventaja reside justamente en que minimiza los riesgos quehe indicado arriba.Otro de los factores que influyen mucho el resultado, es conseguir que elequipo (cliente, consultores, etc.) entre en sintonía desde el primer día. Unade las cosas que se pueden adoptar es estructurar de una manera muyconcreta todas las reuniones que ocurren a lo largo del proyecto. Losresultados son espectaculares en tres áreas:- Motivación.- Reducción de los tiempos de reunión.- Reducción de tiempos en la toma de decisiones.Mi conclusión de todo ello es: • Hay que adoptar la metodología adecuada desde el día cero • El día cero está en el momento que el CLIENTE decide mirar qué soluciones se pueden incorporar y no cuando el INTEGRADOR empieza la fase de preventa. • La metodología adoptada debe enfocarse al éxito. • Ninguna metodología sirve de nada si no se es riguroso en su aplicación. 9
  10. 10. • La metodología debe ser flexible y adecuarse a la realidad. • Debe integrarse con un cierto nivel de "coaching" de TODO el equipo para alinear métodos de trabajo desde el primer día”.Luego del testimonio de Ricardo, Miguel Castella repasa lo expuestoconsiderando que “No cabe la menor duda de que las metodologías hanevolucionado y son suficientemente maduras como para minimizar y en sucaso detectar y gestionar los riesgos, que en mayor o menor medida, estánsujetos a todo proyecto de implantación de software estandard.El problema es que las metodologías se siguen adecuadamente en unporcentaje ínfimo, y las razones son varias:- Los implantadores solo aplican los elementos que están mas relacionadoscon la parte mas visible de su actividad y la que les afecta mas a ellos. Porejemplo: es difícil ver a un implantador convenciendo a su cliente de quedebe definir detalladamente los objetivos del proyecto para que ellos puedandesarrollar indicadores que al final del mismo acrediten que el retornoesperado se ha producido, o que debe implementar un sistema de seguimientoy control sobre su propia actividad como implantador.- Hay implantadores que si el cliente no lo exige utilizan metodologíasclaramente insuficientes para salvaguardar los riesgos del proyecto.- Los clientes no entienden de metodologías de implantación de softwareestandard, ni tienen porqué hacerlo. Aunque en otros ámbitos se hanincorporado conceptos como dirección facultativa externa de obras, en elámbito de las TICs este concepto esta poco desarrollado.En resumen, las metodologías están y sirven, sólo hay que conocerlas yusarlas”.A modo de conclusiónDesde Evaluando Software sabemos que, tanto los vendors de software comolos implementadores ponen mucho énfasis en los instrumentos que utilizan,pero consideramos que lo hacen un poco menos con las personas que, endefinitiva, son los ejecutores.El vendor y el implementador le están entregando al cliente un activo demucho valor como lo es un ERP o un CRM y están poniendo a su disposicióncapital humano muy valioso, entrenado, que día a día, rinde examen.Como el que recibe estos recursos es un Cliente, pocas veces el que losprovee tiene posibilidad de invalidar las contrapartes. 10
  11. 11. Y ahí aparece uno de los tantos factores de riesgo que pueden hacer extenderel proyecto.Como bien dice Miguel, los clientes no entienden de metodología o deimplantación de software. Ahora bien ¿No debería haber alguien en laorganización del cliente que tenga las habilidades/ conocimiento mínimo pararecibir el plan del proyecto y llevarlo adelante?No hablamos de un ingeniero en sistemas o de un técnico similar. Más bien dealguien con el conocimiento organizacional, de manejo de herramientas deproyecto y una cierta capacidad de liderazgo.Es cierto que toda la responsabilidad no es de la metodología. Después detodo se trata de un marco de trabajo que, asumiendo está bien elaborado,necesita de los más importantes: los ejecutores. Por la División consultoría de Evaluando Software 11

×