El documento debate sobre dónde debería comenzar la metodología para implementar un ERP. Varios expertos opinan que la metodología debería comenzar en la etapa de preventa para identificar adecuadamente los procesos de la empresa y seleccionar un ERP apropiado. Sin embargo, otros señalan que a menudo los proveedores quieren vender primero y hacer el estudio después, y los clientes no quieren invertir tiempo en la etapa previa. También se discute la importancia de contar con el equipo adecuado y definir

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
1

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
2

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
3

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

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
5

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

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

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
8

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

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
10

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
11