1

EVALUANDO ERP

Parece que hay metodologías para implementar un ERP que fallan Debate de expertos de la industria

Evaluando ERP 19/07/2010

2

¿Por qué fallan las metodologías para implementar un ERP?

Seguramente escucharon alguna vez esta frase: "Compramos las licencias del software ERP y comenzamos a implementarlo, pero no pudimos terminar el

proyecto, era muy complejo para nosotros. Preferimos volver al software que está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 el software ya está vendido? Y si tienen metodologías ¿Por qué los proyectos siguen 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 los procesos que se realizan en la empresa, para poder seleccionar adecuadamente 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 de esta nueva herramienta es bastante elevado por tratarse de un software de gestión empresarial, y la primera etapa siempre demandará un mayor esfuerzo”, aclara.

José María Renedo -IT DIRECTOR at TOPSALES Barcelona, España- también opina que “la metodología debería comenzar en la preventa para que ambas partes, tanto proveedor como cliente, tengan más claro ante lo que se van a

enfrentar. De esta forma el proveedor podrá hacer una planificación más adecuada y el cliente se habrá visto obligado a hacer una reflexión más exacta de lo que quiere”, asegura.

“Pero en todo caso, siendo ese el camino deseable, luego te encuentras con la realidad, que te dice que en muchas ocasiones el proveedor lo que quiere es implementar su ERP y por lo tanto, “primero que firme el cliente, y luego hacemos el estudio pormenorizado...”; y la otra realidad es que al cliente le cuesta hacer una reflexión detallada antes de firmar el proyecto, ya que esta

reflexión le consume mucho tiempo”, reconoce José María de acuerdo a su experiencia.

“Yo creo que así como el proveedor quiere colocar su ERP, hay clientes que

son ansiosos, y otros que no tienen mucha idea de lo que están comprando y creen 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 ¿No estaría asumiendo costo y riesgo alto sin tener la más mínima señal del

comprador?”, 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ón

de nuestro ERP. No creo que se le pueda otorgar toda la responsabilidad a la metodología. Nada nos asegura el éxito por seguirla, y creo que son muchos más los factores que atentan contra el éxito final. Lo que sí es cierto que las

3

veces que nos hemos apegado más a seguir una metodología, tuvimos implementaciones muy controladas, prolijas y exitosas. Si bien no lo

garantiza, es mucho más cómodo trabajar así, tanto para el cliente como para nosotros”.

Para Juan Ramón Caballero - Director Delegación de Catalunya en EXCELIA

Barcelona, España- “Esa no es la solución, porque no hay una metodología standard para la implantación de cualquier solución tecnológica... y evidentemente, tendríamos que multiplicar el numero de especialistas en la empresa, por el número de tecnologías a implantar... Creo que si las dos partes fueran con los conceptos y objetivos claros, con la sinceridad necesaria

y con el sentido común que siempre ha de imperar en cualquier relación profesional, el porcentaje de proyectos exitosos aumentaría considerablemente”.

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 tan importante 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 que además tengan algún conocimiento de la otra para reducir el tiempo de

desarrollo de las adaptaciones. Un buen consultor tiene que saber detectar los procesos de un cliente y adaptarlos a la empresa, y además tiene que tener el suficiente conocimiento técnico de la herramienta y del diseño tecnológico para que al programador no le toque hacerlo todo. Pero esto se adquiere de una forma no estandarizada, sino que se basa en los

proyectos que el consultor lleve a sus espaldas que le den un expertise en la materia”, expresa.

“El método de implementación es como máximo una hoja de ruta con la que

rellenar el calendario de actividades y poder verificarlas. Normalmente las adaptaciones y las complejidades del cliente hacen que los proyectos sigan caminos muy distintos. En eso se basa la interacción con el cliente. Por muy buena metodología que tengas, los problemas en un proyecto aparecen, y es

ahí cuando todo ese método no sirve y empieza la improvisación, basada en la experiencia, claro. Las mejores prácticas en la implantación de un ERP muchas veces apenas se conocen fuera de la consultora que las ha ido desarrollando, y a veces se

limitan a un "Paper" o como mucho a un Caso de Éxito que apenas aporta información. Me parece que las metodologías sólo implican un cambio si la casa 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 equipos son 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 en un determinado rol o en una determinada área, hace que el enlace entre

los miembros del equipo sea algo más complejo. En este caso la metodología

4

se impone como una forma de estructurar todo ese trabajo de mucha gente que sólo ve parte de las cosas. Allí, es necesaria una visión de conjunto, un

manager con conocimientos funcionales que sepa ver las generalidades. Esto lamentablemente lo he visto sólo en raras ocasiones”.

Miguel Castella -Socio en CCQ Barcelona, España- disiente respecto a la

opinión de Manuel, ya que considera que “A lo largo de los últimos 25 años, se ha conseguido reducir significativamente la tasa de fracasos en la implantación de ERP's, definiendo fracaso como no logro de la puesta en producció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 el sector informático son artesanales, y en ese contexto es sumamente importante poseer inteligencia emocional y experiencias previas. Pero, si se desea poder llevar a cabo los proyectos sin que se dependa de la

inteligencia emocional o la suerte u otros factores parecidos, deberemos tomar 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 minimizan o eliminan la posibilidad de materialización de una amenaza. A lo largo de estas decenas de años se han ido consolidando las mejores practicas en implantación de ERP (Enterprise Resource Planning), y si se siguen estas reglas es mucho más fácil llevar a buen puerto el proyecto”, concluye.

“Sin embargo, yo creo que las metodologías son muy positivas, aunque también considero que son el aspecto "hard" de la implementación”, confiesa Daniel.

“Hay un hecho que se estudia poco en las implementaciones, aunque se habla mucho de ello. Me refiero al encuentro de dos (a veces más) culturas empresariales diferentes. Este sería el lado "soft". No he visto ningún Plan de

Proyecto que incluya este tema, ya sea como un factor de riesgo y, menos aún, con actividades concretas dentro del Plan para unir ambas culturas. Debe ser 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, pero aclara 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 componen personas, tanto de la empresa implementadora como del propio cliente, y en más de una ocasión, no son las adecuadas. El compromiso de los componentes

del equipo, además del compromiso de la alta dirección del cliente con el proyecto, son claves.

5

2- El segundo, y en esto coincido con los que indican que la metodología se inicia desde la preventa (incluso desde la venta), es identificar los objetivos

del proyecto de forma correcta, así como entender los procesos del cliente y no querer siempre construir el “sistema de la NASA”, cosa a la que se sienten tentados muchos consultores. A veces no hace falta y es hasta contraproducente. 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 el implantador en el proyecto y, por supuesto, a menos horas, menos estricta es la metodología que se aplica. Grandes metodologías son válidas para grandes proyectos, pero esto no siempre es factible.

Sergio Yazyi -System Integration and SAP ERP Financials Consultant Salamanca, España-, afirma que “sin duda el centro cambió de la metodología a las personas. Imaginemos un proyecto con los mejores consultores y los mejores usuarios claves, acompañados de otras tantas

personas adecuadas, con un sponsor que provee los límites y recursos correspondientes. Pienso que en este caso la metodología pasa a ser menos relevante, casi surgiría por sí misma ,producto de la experiencia, y además sería adaptada con rapidez al caso concreto donde hiciera falta, con el fin de

cumplir el objetivo de valor -expectativa claramente definida desde la preventa, sin duda-

Me parece clara la importancia de las personas, igualmente clara la dificultad

de lograr tal equipo. Pero ¿puede una metodología ayudar a suplir la inadecuación al nivel qué sea? ¿Puede la metodología producir roles rígidos que dificulten la comunicación y la iniciativa? ¿Puede una persona, grupo o rol definido, ser responsable de intervenir para promover la adecuación en la dinámica del equipo? ¿Han visto que esto ocurra naturalmente o

informalmente en algún proyecto exitoso?

Miquel Castella interviene nuevamente en el debate, y expresa que “Lo que ocurre es que el hecho de provocar que se cumplan esos factores formaría

parte de la metodología en sí: efectuar un conjunto de actividades de forma que los elementos que intervienen en un proyecto sean los adecuados para las características de ese proyecto, de forma que minimicen las posibilidades o el impacto que la materialización de amenazas puedan producir....

Y evidentemente, en primer plano están las personas, y también el azar y otros imponderables.

Considero que habrá que corregir el rumbo, pero si existen los sensores

adecuados –metodologías- se podrá corregir con mas anticipación y mas precisió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 un software empresarial. O sea, mucho antes de la preventa, y muchísimo antes de haber vendido el software. Sobre todo si estamos hablando de implementación de licencias que ya están desarrolladas y cuya

6

implementación en el cliente se refiere a personalizaciones o módulos específicos.

Pero para que esto funcione, toda la aplicación debe haber sido desarrollada utilizando una prolija y bien pensada metología. De otro modo, con el tiempo resulta imposible sostener las personalizaciones a clientes, y como

consecuencia de esto, el proyecto se estanca, no se termina, o termina mal”.

Actualmente existen muchas empresas en el mercado que tienen metodologías de desarrollo de software. Incluso, más de una, alcanzó

certificación CMMI. Sin embargo, cuando llega el momento de ejecutar o implementar el producto que desarrollaron, las cosas no siempre salen bien. Es evidente que, teniendo certificaciones de desarrollo, no se puede cargar muchas tintas sobre el producto. El hecho que la implementación de muy buenos productos funcionales y/o tecnológicos se altere, en tiempo y/o

presupuesto, nos hace pensar que la forma de implementarlo falló. Y esas fallas pueden ser de una o de las dos partes.

Por eso, a la pegunta inicial ¿Donde debe comenzar la metodología de implementación?, le agregamos: ¿De qué sirve tener la mejor metodología,

la más documentada, la mejor desarrollada si los intérpretes no son los adecuados?

Oscar González -Presales Manager at CDC Software- “Bajo mi punto de vista

la 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 demasiado

desconectados, es decir, el preventas hace su trabajo hasta la firma y se retira del cliente para que entre la gente de servicios (con lo que todo empieza de nuevo). Esto es un error. Los responsables de la cuenta a nivel de soluciones (preventas, product managers...etc.) deberían continuar en relació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 de servicios 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 que favorece la venta repetitiva en dicho cliente.

Por supuesto en grandes sistemas otra ventaja añadida es que normalmente los consultores de preventa tienen una experiencia más dilatada y por lo tanto son mucho más flexibles a la hora de buscar soluciones a problemas, por lo

que pueden ser una gran ayuda durante la definición e implantación de un proyecto.

7

Albert Condal –Director de Ventas de EXCELIUM- “Coincido con Oscar en que las empresas fabricantes de software y las empresas que nos dedicamos a

venderlas e implementarlas debemos trabajar en equipo y de ser posible, con mé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 el proceso de pre-venta, venta e implantación y hacerle ver y entender los cambios que se pueden producir a todos los niveles de la organización, y

ayudarle a afrontarlos.

Cualquier buen servicio tiene unos costes implícitos, y esa también es una realidad y una gran responsabilidad que tenemos y que debemos saber

transmitir a los clientes "en vez de vender a cualquier coste", ya que de lo contrario seguiremos sufriendo los mismos problemas y la incomprensión hacia nuestro sector, y perjudicamos al fabricante, a nosotros mismos y sobre todo al cliente”, afirma.

Sergio Broutvaien -CEO en Maer Software- considera que “Se está dejando

de lado al actor principal que es el usuario. Generalmente, la decisión de compra de un ERP viene de los mandos medios con un aval económico de la dirección de la empresa. Con suerte, estaremos siendo apoyados por la

gerencia de sistemas del cliente (si es que esta gerencia existe). Pero a la hora de implementar, nos encontramos con los usuarios, a los que, generalmente nada se les preguntó sobre sus preferencias, se les agrega trabajo por la nueva implementación y se pretende que aprendan algo que no

les interesa, en tiempo récord, para reemplazar algo con lo que ya se sentían cómodos”, reconoce.

“En definitiva, sin duda alguna para mi, la metodología es un post venta de

respuesta inmediata, amable, paciente y que acompaña el aprendizaje de los usuarios finales”.

“Es cierto lo que mencionas con relación al usuario”, agrega Daniel. “Creo

que él debe ser considerado en cualquier metodología. Pero aquí tiene mucho que ver el estilo de management de cada empresa. Una cosa es cuando se les informa "Hemos comprado un sistema" y otra es cuando se les presenta el proyecto que llevará a la empresa a otros niveles. Insisto que esto depende de la empresa, del proyecto y del tipo de gerenciamiento que se tenga”.

Marino Alejandro Correa - Consultor en Nodum S.A.- “En mi experiencia como consultor he participado en implementaciones de proyectos que van desde muy buenas hasta muy malas. Del análisis que hago encuentro que en

general, aquellas implementaciones que no han sido satisfactorias responden a varias causas:

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.

8

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 “El secreto para una implementación exitosa es entender la cultura de la empresa y la fortaleza para adaptarse al cambio, identificando los interlocutores

vá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 llegar preparado al proceso de preventa con todo el conocimiento necesario para

llegar al objetivo primario, que es la venta.

Incluso algunas empresas identifican la necesidad de hacer una consultoría previa, que les permita llegar con los procesos claros y documentados, para la

incorporació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 invertir en la mejora de procesos.

Ya en el cierre de la venta, el Director de TI debería participar activamente del proceso para evaluar puntualmente las necesidades de la compañía versus la solución, y poder detectar de antemano los deltas que luego serán evaluados internamente, lo que permitiría una cotización clara y con los menos costos ocultos posibles.

Si bien sería utópico decir que esta metodología resuelve los problemas, es cierto que ayuda a acotarlos en costos y tiempos.

Otros factores pueden incidir, son la adopción del conocimiento de una nueva herramienta, 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 con el enfoque que adquirió el debate, me gustaría añadir una mirada deferente de acuerdo a mi trayectoria.

Yo soy de los que opino que un proyecto no empieza en fase de preventa, sino antes, cuando una empresa toma la decisión interna de implementar un nuevo

9

sistema de gestión: ERP, BI, CRM, etc.

Cuando era director de TI de una multinacional, tuve la ocasión de estar en esa toma de decisión, y para ello adopté una metodología holística no demasiado conocida en Europa. La ventaja está en que esta metodología ataca 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 para implementar 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 que he indicado arriba. Otro de los factores que influyen mucho el resultado, es conseguir que el equipo (cliente, consultores, etc.) entre en sintonía desde el primer día. Una

de las cosas que se pueden adoptar es estructurar de una manera muy concreta todas las reuniones que ocurren a lo largo del proyecto. Los resultados 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.

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”.

10

Luego del testimonio de Ricardo, Miguel Castella repasa lo expuesto considerando que “No cabe la menor duda de que las metodologías han

evolucionado y son suficientemente maduras como para minimizar y en su caso detectar y gestionar los riesgos, que en mayor o menor medida, están sujetos a todo proyecto de implantación de software estandard. El problema es que las metodologías se siguen adecuadamente en un porcentaje ínfimo, y las razones son varias:

- Los implantadores solo aplican los elementos que están mas relacionados con la parte mas visible de su actividad y la que les afecta mas a ellos. Por

ejemplo: es difícil ver a un implantador convenciendo a su cliente de que debe definir detalladamente los objetivos del proyecto para que ellos puedan desarrollar indicadores que al final del mismo acrediten que el retorno esperado se ha producido, o que debe implementar un sistema de seguimiento

y control sobre su propia actividad como implantador.

- Hay implantadores que si el cliente no lo exige utilizan metodologías claramente insuficientes para salvaguardar los riesgos del proyecto.

- Los clientes no entienden de metodologías de implantación de software estandard, ni tienen porqué hacerlo. Aunque en otros ámbitos se han

incorporado 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 y usarlas”.

A modo de conclusión

Desde Evaluando Software sabemos que, tanto los vendors de software como los implementadores ponen mucho énfasis en los instrumentos que utilizan, pero consideramos que lo hacen un poco menos con las personas que, en definitiva, son los ejecutores.

El vendor y el implementador le están entregando al cliente un activo de mucho valor como lo es un ERP o un CRM y están poniendo a su disposición capital 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 los provee tiene posibilidad de invalidar las contrapartes.

Y ahí aparece uno de los tantos factores de riesgo que pueden hacer extender el proyecto.

Como bien dice Miguel, los clientes no entienden de metodología o de implantación de software. Ahora bien ¿No debería haber alguien en la

11

organización del cliente que tenga las habilidades/ conocimiento mínimo para recibir el plan del proyecto y llevarlo adelante?

No hablamos de un ingeniero en sistemas o de un técnico similar. Más bien de alguien con el conocimiento organizacional, de manejo de herramientas de proyecto y una cierta capacidad de liderazgo.

Es cierto que toda la responsabilidad no es de la metodología. Después de todo 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 ERP