Cómo seleccionar e implantar ERPs

@ricardodevis
Ricardo Devis Botella

Lo que era un ERP y lo que parece ser hoy un ERP
Islas,Cables, Militares, Mares y Puertos 

 ERP son las siglas de Enterprise Resource Planning
(Planificación de Recursos Empresariales), y “software
de ERP” es el conjunto de aplicativos que dan soporte
a tal concepto, derivado de las cuitas asociadas a MRP
y MRPII.
 Pero el concepto se ha diluido tanto que ya, cuando se
habla de ERPs se está hablando directamente del software
de ERP.
 Así que, hummm, ¿qué ha pasado?Y, claro…
entonces… errrr… entonces, ¿qué es un ERP y para
qué sirve? Pero yo tengo/quiero uno y…
 En fin: lo anterior no nos da mucho juego . Pongamos un
poco de orden en conceptos e historias.

 Debido al auge del concepto industrial de islas de
automatización, pronto proliferaron, en los albores
del desarrollo software de gestión empresarial,
aplicativos dedicados a diferentes áreas estancas de la
empresa: finanzas, contabilidad, producción,
logística, etc., desarrollados e implantados también
por diferentes empresas, con diversas tecnologías y
resultados.
 El objetivo era (y todavía es, en muchos casos) cubrir un
área operativa bien definida en la empresa en función de
sus objetivos aislados y de sus resultados plausibles.
▪ Y sólo esa área concreta, en cada caso.
 El fin era contar con áreas super-especializadas.

 Ante tal panorama de Islas, industriales y software, las
primeras necesidades de cierta integración aparecieron en
la parte ejecutiva de gestión: informes y cuadros de
mando, complicados tremendamente por la profusión de
formatos y enfoques distintos.
 Y de aquí nacieron, entre otros, los EIS (Executive Information
System), como soporte a la toma de decisiones de gestión
▪ Se trataba de lanzar cabos de una isla a otra, a modo de hilos
telegráficos que permitieran tipos concretos (y usualmente ad hoc) de
comunicación y acopio de datos de diferentes fuentes, con los que
montar cuadros de mando (BSCs, etc.)
 El problema reside en que el enjambre de comunicaciones
depende de cada uno de los módulos, de forma que
cualquier cambio representa[ba] un grandísimo impacto
en el software de integración.

 Pero, claro… ¿y si el fabricante de todos los módulos fuera
el mismo y asegurara la comunicación estructural entre
ellos, a modo de carreteras privadas/militares por las que
fluiría información privada para uso interno de cada
módulo y de otros generales de gestión del paquete
global? ¿Y si todo esto se enfocara hacia la mejora de los
procesos productivos? ¿Y si…?
 En fin: de todo esto nace la exitosa (pero dirigida) idea de
los sistemas software ERP.
 …que se apoya extraordinariamente en el hecho de que las
ventajas de la siempre costosa integración vienen dadas por la
experiencia de la empresa constructora del software
precisamente en estas cuitas.
▪ Así que se vende que todo se integra, y que se integra de una forma
controlada y probada, probablemente en el mismo segmento industrial

 Claro que, tras un cierto tiempo, y debido al enorme
espacio económico generado por el concepto ERP, éstos
empiezan a proliferar también, aplicándose en modo
“sustitutivo”.
 Y comienzan a aparecer, también otros, aplicativos que
reclaman que el mar entre islas es de todos .
▪ Es enfoque tiene su máxima expresión en el software de
automatización de ventas (SFA), que luego derivó en CRM (Customer
Relationship Management) y que contaba con “extractores” de
información de los ERPs más difundidos, impensables poco antes.
 Pero, claro, la extracción de información de los ERPs es
muy parecida a la extracción de riquezas por los bandas
organizadas de malhechores: usualmente mediante
incursiones no del todo permitidas en los dominios del
ERP.

 La parte del negocio que se estaba escapando rauda
por el mar necesitaba ser recuperada por los ERPs, así
que éstos empiezan una apertura controlada de sus
módulos, mediante APIs (Accesos mediante
Programas Software), BAPIs (APIs de negocio)
y, últimamente, ServiciosWeb.
 Se trata de generar estructuras a modo de puertos de
comunicación para reglar el acceso interior a los módulos
anteriormente “privados” del ERP.
 De esta manera los ERPs entran, ellos mismos, en el
negocio de explotación de la integración, facilitando
la comunicación con módulos externos, no previstos
en la instalación primera o encontrados en la misma.

 Los ERPs se han adaptado a las situaciones de
mercado porque en su misma esencia, y tras los
primerísimas instalaciones en las que las empresas se
ajustaban al (supuesto) superior conocimiento de la
implantación tecnológica de estos
proveedores, pronto se tuvieron que adaptar a las
necesidades concretas de las empresas y así nacieron
entornos de desarrollo software asociados a cada ERP.
 La implantación de facilidades de comunicación
respecto de los ERPs ha generado parejas facilidades
de adaptación respecto de la instalación del software
en sus empresas clientes.

 Claro que, finalmente, como estos conceptos no están
bien asentados en la cotidianeidad empresarial, en la
práctica los proveedores tecnológicos denominan ERP
a cualquier sistema suyo de gestión modular integrada
(contabilidad, logística, facturación, producción, CRM
-?!-, finanzas, etc.)
 …pero sin lindes claros: ¿si no tiene contabilidad, es un
ERP? ¿Y si no cuenta conCRM? ¿Y si le falta “movilidad”?
Depende de quién lo cuente, claro 
 Lo que se vende, por fin, es una solución integral y,
lamentablemente, la mayoría de las veces “exclusiva”,
para la automatización operativo-tecnológica de las
empresas.

ERPs de gran Extensión Internacional
Paquetes Locales/Propietarios deGestión Integrada

 En primer lugar habría que preguntar… ¿para qué?
 Pues para adquirir criterios de decisión sobre qué
comprar, cuándo elegir, cómo implantar y de qué manera
integrar, ahora y en el futuro.
 Y después habría que preguntar… ¿sobre qué eje?
 ¿La extensión? ¿La tecnología (¡Uy, uy!)? ¿El segmento de uso?
¿El mero precio (¡Ay, ay, ay!)? ¿La fiabilidad de sus fabricantes?
¿La prestancia de sus implantadores?
▪ ¿O sobre todos los ejes unidos y compensados?
 Curiosamente (bueno, no tan curiosamente ) la situación
de mercado de competencia quasi-perfecta a la que se ha
llegado por la vulgarización del concepto ERP ha generado
un autoajuste en bloques asimilados a la conjunción de
extensión y precio, que acompasan al resto de criterios.

 Premier League (muy caros, pesados, pensados para
grandes organizaciones)
 SAP R/3, JD Edwards, Oracle, Peoplesoft…
(independientemente de sus propietarios)
 Ligas Menores (extensión internacional y grandes
volúmenes de clientes PYMEs)
 MS Nav (Navision), MS AX (Axapta), SAP Business
One, Exact Sinergy…
 Competición Local (software propietario y de
suficiente extensión, a veces con alcance
internacional)
 RPS, i68, Xpertis…
 Competición Ad Hoc (software aprovechable)

 Duelen… ¡sólo en el terreno comercio-emocional!
 El interés de la empresa debe residir en los criterios
que puede controlar, que finalmente son, por encima
de la tecnología (que usualmente no puede calibrar) o
la fiabilidad (que típicamente depende de referencias
inválidas por la imposibilidad de comparación)…
 El rango de precios
 La extensión (supeditada al rango de precios)
 …si se adquieren garantías de que la implantación va a
ser la que la empresa exactamente necesita.
 Así que hay que partir de este supuesto: de conseguir lo
que se requiere, ajustado a una horquilla de precios y, en
caso de igualdad, con preferencia por marcas reconocidas.

Producto + Implantador
Precio (Licencias + Parametrización) + Garantías

 ¿Hasta qué punto importa un producto ERP u otro
desde el punto de vista de la PYME?
 Depende de si la empresa se va a adaptar a un producto
(en cuyo caso… ¡importa bastante, en razón de los criterios
que han conducido a tal decisión!) o el producto se va a
adaptar totalmente a la empresa (en cuyo caso… ¡no es
nada importante).
 Así las cosas, la tecnología no es importante en
implantación (si procura lo que se quiere) ni en el
futuro (si se ha implantado lo que se deseaba)
 Sólo lo es, en cada producto, la disposición a la
comunicación basada en servicios de negocio.
 Pero, entonces… ¿tampoco son relevantes las
demostraciones, las referencias o las características?
 No, no y… ¡por supuesto que no! [reflexión]

 El objetivo de una “demo” de un ERP a un posible cliente
es, únicamente, asentar las labores de preventa del
ProTec.
 Es decir: tiene que ver una empresa diferentes demos de
diferentes productos para ir contando en cada caso cuál se
adapta mejor a lo que quiere… ¡si todos van a pasar-por/sufrir
un proceso de adaptación que usualmente iguala el precio de
sus licencias o lo supera!
 Lo realizado en otros clientes o provisto en el producto
básico no es relevante.
 Un matrimonio anterior no garantiza el éxito en un nuevo
matrimonio.
 La empresa necesita de garantías reales de implantación
adecuada, que forzosamente se darán en el proceso
mismo de implantación y raramente en el producto.

 Determinados ERPs tienen implantadores diferentes de
sus fabricantes (todos los grandes) y otros no (los de
menor extensión, usualmente).
 En cualquier caso.. ¿qué importa aquí? ¿La prestancia
técnica del implantador, quizás basada en sus experiencias
o en las capacidades de su personal? ¿Su ficha policial… en
blanco?
 Sólo interesa su “disposición”, muchísimo más que su
experiencia o capacidad, comprometidas forzosamente
mediante un oportuno contrato de servicios.
 La valoración de un implantador se dará en razón de el
ajuste de las necesidades a satisfacer (nunca bien
ponderables) y sus resultados (no calibrables)
 …así que, puestos a subjetivar… ¡la disposición cuenta aún más!

 El precio de la licencia debiera asimilarse a un “producto
que funciona al ser entregado o, al menos, instalado” (no
hay que olvidar que licencia es un “permiso para hacer
algo” –DRAE)
 Así que si para que un ERP funcione (operativamente hablando)
hay que parametrizar o realizar acciones de análisis, diseño, bla-
bla-bla… entonces es que se ha desviado parte del precio de la
licencia hacia la fase de desarrollo que resultará… ¡obligatoria!
 Lo más práctico es que las empresas obvien el precio de
las licencias y se centren en el coste total de la instalación
(licencias + desarrollo) y en el de su soporte y modificación
futura (mantenimiento + coste de desarrollo + licencias
adicionales).
 Una asunción profiláctica y muy práctica es la de considerar los
ERPs como productos perecederos con una vida de… ¿5 años?

 ¿Cuáles son los avales y garantías que aportan los
implantadores de ERPs?Veamos sus argumentos:
 Fiabilidad basada en la extensión del producto.
 Calidad expuesta en cuadrantes mágicos y estudios
externos.
 Prestancia centrada en anteriores casos de éxito
 Garantía sustanciada por el ajuste entre un análisis
posterior (que la empresa firmaría) y sus resultados.
▪ Es decir: una suerte de… “te vendo la licencia, y ahora dime lo que
quieres, que yo te diré cuánto te voy a cobrar por hacerte… eso; no
lo que tú necesitas, sino eso, sólo eso, que es lo que puedo estimar
monetariamente”.
 Es decir: las garantías suelen ser “expectativas
prestigiadas” y no verdaderas garantías.

 Claro que… si la parametrización depende de un
análisis, ¿qué sentido tiene el pre-análisis al
que, inmisericordemente, muchas empresas son
sometidas antes de la oferta?
 Básicamente… estimar los rangos de precios que la
empresa aceptaría en la (primera) oferta.
 ¿Por qué los ProTecs no realizan un análisis (a su
cargo) para determinar una propuesta dineraria
sentada?
 Pues porque mayoritariamente estiman que tal análisis
debe ser pagado por el cliente. Pero, claro, esto supone
que lo que los ProTecs venden es… ¡la garantía de su
buena voluntad! 

 Lo que la empresa necesita
es un paraguas contra la
lluvia, y no la garantía de la
previsión –apoyada por
informes, cuadrantes, estadís
ticas y la experiencia– de que
no lloverá.
 Pues siempre llueve, más tarde
o más temprano 
 No se trata de proteger la
inversión, sino de asegurar la
proyección… ¡de resultados!
 Comprobemos que el paraguas
existe y que no está roto o
vencido.
 La tecnología es… ¡un medio!

 El software no es ningún arcano, ni plantea esquemas
diferentes de los asociados a una compra de tornillos
o el alquiler de un vídeo.
 El problema es que los ProTecs han desplazado su modelo
de gestión hacia sus clientes, de forma que parece que
éstos hayan de aceptar sus hitos, procedimientos y formas
(como, por ejemplo, abultadas entregas iniciales), cuando
no hay motivo para ello (pregunten por él, siempre,
siempre).
 ¡Claro que se pueden pedir garantías formales!Y, en
todo caso, ¡No pagar hasta que éstas se den!
 No hay que olvidar que el contrato de implantación de
software es… ¡un contrato!Y, por tanto, está sujeto a la
voluntad de las partes. Sin más; ni menos .

¿A quién Contactar?
¿CómoContactar?

 Lo primero es… ¡elegir proveedores razonables (entre
los productos deseados y entre los desconocidos)!
 Pero… ¿cómo saber a qué ProTecs contactar? ¿Son
muchos? ¿Son pocos… los buenos? ¿Me fío de los amigos?
¿Confío en la fama?
 Desgraciadamente no se cuenta con un registro de
ProTecs, ni general ni temático, por el que se sometan
a la evaluación de sus clientes, enemigos o críticos
independientes.
 Así que el primer criterio razonable de elección será el de
proximidad: a no ser que queramos acoplarnos idealmente
a un producto, necesitaremos ajustes, por lo que
buscaremos empresas que, como mínimo, se puedan
desplazar a reuniones (y, por tanto, a aquella en la que se
planteen los términos de lo necesitado por la empresa)
▪ Hay que buscar empresas de ERPs enVizcaya… o en Euskadi.

 Un ERP no es como otro tipo de software, pues al constar
de módulos integrados, casi podría afirmarse que
cualquier desarrollo software de la empresa quedaría
asimilado en alguno de tales módulos.
 Es decir: las empresas que “fabrican” ERPs difícilmente pueden
dedicarse a otra cosa que no sea el ERP, que actúa como un
agujero negro que atrae y fagocita todas sus actividades de
desarrollo.
 Por otro lado, los implantadores de ERPs necesitan de
personal y conocimientos muy
específicos, experiencia, inversiones en productos y, sobre
todo, ventas.
 Por tanto, las empresas relacionadas con ERPs unirán el
término ERP a su actividad de forma clara, así que podrían
ser encontradas en listados en CEBEK y otras instituciones

 A los ProTecs resultantes de las listas hay que contactarles
por teléfono o e-mail para pedirles información sobre el (o
los) ERP(s) que implantan (y dónde están en laWeb).
 Pero no una cita, sino tan sólo información, preferentemente en
papel (para comprobar su gramaje [] y, sobre todo, porque al
ser un medio más caro que laWeb, se tiende a sintetizar más y a
exponer sólo lo más importante).
▪ Las citas sólo servirían para entregar el papel (lo que supone una
pérdida de tiempo para la empresa), o para que el ProTec calibre si vale
la pena invertir su tiempo (lo que no es razonable), o para aprovechar y
hacer un pequeño análisis de pre-venta (a lo que la empresa debe
negarse… pues no sirven para casi nada)
 Si el ProTec es razonable, esta simple petición disparará
sus alarmas y, tras mandar la documentación (o
recomendar un sitio Web), seguirá en adelante el proceso.

 Una relación de proveedores/implantadores de ERPs
podría ser muy larga (si fuera corta, porque no se pueden
encontrar nombres, no habría que discriminar entre ellos),
así que deben aplicarse algunos criterios de filtro, por lo
que en el primer contacto a distancia (por teléfono o e-
mail o carta) habría que plantearles expresamente:
 El precio máximo a pagar (o su horquilla)
 Que no se necesita un CRM (se necesite o no)
 Que no se va a abordar la producción (a no ser que sea el único
objetivo de la empresa).
 Los módulos de Producción o de CRM, si el ERP es
razonable, siempre se pueden añadir después.
 …así que separarlos en la oferta centra muchísimo los rangos de
precios y las disponibilidades de servicio de los ProTecs.

 ¿Dónde radica la principal diferencia de precio, tiempo y
esfuerzo entre los ERPs, y para cada uno de ellos, entre
sus posibles implantaciones?
 Sin duda… en el módulo de producción (cuya automatización, si
recordamos, fue en su día la base conceptual y de negocio de
los ERPs).
 La implantación de un ERP con Producción supone, en casi
todos los casos, una adecuación específica (llámese
parametrización o desarrollo: da igual) del ERP a la
empresa, lo que implica un análisis extenso y un desarrollo
largo y costoso.
 Así que si una empresa no necesita mecanizar su producción, lo
mejor es decirlo de antemano al ProTec, para que éste centre su
oferta de documentación

 El objetivo de un paquete software CRM no es generar
cuadros de mando de clientes, sino ayudar en la actividad
comercial de la empresa: ayudarla a vender sus productos
y servicios.
 Así que el conocimiento para su concepción y puesta en marcha
funcional y operativa es esencialmente diferente del que se
procura en los ERPs.
 En muchos casos los ERPs incorporan módulos CRM
que, en realidad, sólo son aprovechamientos internos de
información integrada que debería haberse dado
mediante servicios externos [explicar, explicar].
 En todo caso, el CRM (el que aporte el ERP u otro) siempre debe
poder añadirse tras haber implantado un ERP.
▪ Y si el CRM se regala… probablemente es que no vale nada.

Adecuación a la Empresa
Preparación y Disposición

 Los ProTecs suelen tener sus propio sistemas de
prospección, información, pre-venta, análisis, venta, etc.
de sus ERPs.
 Sistemas que, a veces, están sujetos a marcos de gestión de la
calidad.
▪ …que los criterios anteriormente expuestos podrían quebrar.
 Pero… ¡Nada de esto importa a la empresa!
 No hay que olvidar que la esencia de la implantación de un ERP
es su adecuación a las necesidades de la empresa.
▪ Así que… mal síntoma es que ya en el primer acercamiento el ProTec no
se pueda o quiera adaptar a lo que la empresa desea.
 Hay que mantenerse firme: nada de entrevistas antes de
recibir la documentación
 Y respecto de los comerciales de los ProTecs hay que aplicarles
el lema de Hollywood: “No nos llame, nosotros le llamaremos”

 Tras recibir la documentación (pues si no se recibe, el
interés habrá demostrado ser muy escaso: mal comienzo
para una posible implantación) y efectuar una primera
discriminación basada en lo que en ella aparece
(precio, localización geográfica de oficinas del
ProTec, implantación en el sector al que pertenece la
empresa, claridad en la exposición del ERP, etc.), se citará
a los ProTecs a una reunión en la que se le participarán los
requisitos de la empresa para el proyecto.
 Tal reunión será, necesariamente, conjunta (InfoPool)
 Pues no se trata de que planteen ofertas invididualizadas, sino
de que escuchen lo que la empresa tiene que contarles, junto
con el resto de proveedores pre-seleccionados.
▪ Y si el ProTec plantea pegas, probablemente no interesa a la empresa.

El Ciclo deVida de las OfertasTecnológicas
Objetivos, Criterios y Desarrollo

 El objetivo de esta
reunión conjunta de
proveedores es que los
ProTecs escuchen a la
empresa
 …y que planteen sus dudas
de forma pública
▪ …y se escuchen unos a otros,
y a las respuestas de la
empresa.
 Se trata de plantear lo
que la empresa necesita,
no lo que los ProTecs
ofrecen,
 …que podrán exponer en
las ofertas formales que se
deriven de esta reunión.

 Tal y como les hemos adelantado por teléfono, el próximo xx/xx/xx
a las xx:xx horas tendrá lugar, en nuestras instalaciones, una
reunión en la que se explicarán los requisitos deseables del sistema
ERP que pretendemos implantar en nuestra empresa. A efectos
de que puedan preparar mejor la reunión, a la que asistirán otros
proveedores, les anticipamos las líneas de la misma:
 Brevísima introducción al proyecto
 Breve explicación de las características de la empresa y de su situación
actual
 Requisitos plausibles y criterios para la toma de decisión
 Preguntas y Aclaraciones
 El resultado de la reunión deberá ser, sin reuniones intermedias
adicionales, una oferta (en el plazo que se acuerde) que contemple
todos los aspectos de
licencias, implantación, parametrización, validación, producción, p
ruebas y mantenimiento.

 Les anticipamos, también, que los criterios básicos que primarán
en la elección final, centrados en el aseguramiento de la
implantación, serán, sin pretensión de orden o importancia, los
siguientes:
 Precio de licencias
 Hitos de Pago (no importan las metodologías de implantación, sino los
hitos de validación)
 Entrega dineraria o aval inicial
 Acotación y control de la parametrización/codificación
 Mantenimiento flexible
 Prototipo operativo
 Formación evaluada por la empresa
 Eliminación de costes superfluos (dirección de proyecto, etc.)
 Esperando y agradeciendo de antemano su asistencia, reciban
nuestros saludos cordiales.

Requisitos
Análisis
DiseñoImplementación
Producción

 El objetivo del SLC (Software Life Cycle) es la
construcción o adecuación del software, aplicable a
las empresas que manejan su proceso productivo.
 Se trata, por tanto, de un conjunto de procesos internos
de los ProTecs
▪ …que no puede ni debe ser impuesto a las empresas.
 Es claro que cualquier proceso fabril o de producción
necesita de fases internas específicas
 …pero los hitos respecto de sus clientes deben ser
establecidos en razón de las necesidades de estos
últimos, y no de las condiciones de los procesos
internos, sometidos o no a sistema de gestión de su
calidad.
▪ La calidad sólo cabe aplicarla a los hitos de la empresa, que no
tienen que coincidir con los del ProTec [discutir, discutir].

Instalación
Diseño de
Interacción
Prototipo
Implantación
Modular
Validación

 Los ProTecs acostumbran a comenzar sus proyectos con
una fase de descubrimiento de requisitos (usualmente
funcionales), que se plasman en documentos que suelen
forzar a firmar a las empresas, para así determinar de
forma monetariamente clara el alcance de sus trabajos
 Se trata de que el presupuesto se ajuste a la tarificación de tales
requisitos.
 Pero no es posible para la empresa valorar la completitud
de tales requisitos, sino sólo (y a veces ni siquiera eso) su
corrección [explicar, explicar].
 Es decir: el documento de requisitos es una condición interna
del proceso de implantación, propia del ProTec, que éste
probablemente deba redactar
▪ …pero no constituye hito alguno para la empresa, que, en cualquier
caso, sólo podrá corregir en él errores obvios, pero no validarlo.

 El primer hito válido (y, por tanto, certificable y
susceptible de ser pagado) respecto de las empresas tiene
que ser un prototipo operativo del sistema final que se
implantará.
 Esto no significa que al ProTec no se le vaya a pagar su
recolección de requisitos o el análisis software/negocial que
haya practicado, sino que simplemente se le pagará un poco
más tarde, cuando demuestre su adecuación a las necesidades
de la empresa… ¡mediante el prototipo!
▪ Pues esto sí es algo que la empresa puede comprobar y validar.
 Si se dan datos a migrar (desde un ERP o cualquier sistema
anterior), un subconjunto de éstos debe ser incorporado al
prototipo, de forma que la empresa pueda comprobar la
validez de la nueva implantación.
 Así que los procedimientos de migración no pueden diferirse.

 En los presupuestos (muy) iniciales de los ProTecs se suele
notar un presupuesto, típicamente basado en horas de
consultoría, por el que realizarían la parametrización
(ajuste) del ERP para la empresa.
 Tal presupuesto no puede dejarse depende de un análisis
posterior… ¡ni de nada posterior a la firma del pedido del
ERP!
 Así que se dan dos posibilidades razonables:
 O el ProTec considera que es un precio fijo, pues conoce la
empresa y/o su sector… o estima una desviación máxima de un
15% (que tendrá que ser justificada, en todo caso)
 …o el ProTec realiza, a su coste, un análisis previo para
finalmente recalar en el supuesto anterior.
▪ En ningún caso es de recibo que la empresa pague un análisis de
estimación de costes de implantación de un producto en liza electiva.

 Los ProTecs suelen justificar sus facturas de desarrollo o
parametrización mediante “partes de trabajo” que reflejan
las horas que uno o varios de sus profesionales han
trabajado en un desarrollo software, derivado, en el mejor
de los casos, de un requisito pactado con la empresa.
 Pero se obvia que la empresa en ningún caso puede validar este
trabajo: sólo el resultado. Pero se firman las horas, no el
resultado.
▪ Así que… ¡que la empresa no firme nada! ¡Qué más da cuánto, cuándo
y dónde se trabaje! La empresa sólo puede valorar aquello que puede
medir: el resultado.
 El compromiso de los ProTecs de que ocasionarán el mejor
gasto posible es el mismo que el de las super-potencias
cuando, en guerra, afirman que causaran el menor número
de bajas posible: es una mera declaración.

 Los productos de las ligas mayores
(Microsoft, SAP, Oracle, etc.) imponen sus criterios y es
casi imposible sustraerse a ellos… si se quiere el
producto, sin más.
 Así que el mantenimiento es el que es, y el precio de las
licencias y su forma de pago las que determinen, sin discusión.
▪ En tales casos la empresa ha de valorar el precio total
 Los otros productos… tienen un software suyo y exigen…
¿qué exigen? Usualmente piden un 30% de entrada, lo que
es inusualmente irrazonable (¿por qué?), y, además, el
precio de las licencias cuando se instalen para el desarrollo
o, peor, al principio.
 No se debe ceder en esto: las licencias deben pagarse sólo
cuando se haya puesto en producción el ERP; esto es, al final del
proyecto.Y el desarrollo… que vaya por cuenta del implantador.

 La licencia (“de uso”) es un artefacto financiero para,
supuestamente, amortizar la inversión (“continua”) de
un ProTec en su ERP.
 De acuerdo. Pero ese concepto no impele al pago
inmediato. De hecho, si una empresa pide las licencias por
anticipado es porque… ¡tiene dificultades financieras!,
dado que la salida de un producto fabricado con bits no
importa salida efectiva de material o de dividendos.Y si
tiene tales dificultades, quizás sea mejor no empezar así el
proyecto.
▪ Esto es fácil de ver: si se ofrece al ProTec un aval (tal vez bancario)
garantizando que se pagan las licencias al término del proyecto
(aceptado por la empresa) y no acepta… ¡tiene dificultades claras!

 El mantenimiento no suele cubrir las mejoras sobre la
parametrización/ajuste del ERP a la empresa, ni tampoco
las nuevas funcionalidades que se quieran añadir a la
implantación previamente realizada.
 Así que sólo tiende a cubrir las mejoras sobre el producto base
▪ …que es, precisamente, aquél que se tuvo que parametrizar (y hasta
quizás pagar una dirección de proyecto) para que tuviera uso operativo
en la empresa.
 El mantenimiento debiera ser sustituido por un contrato
eficaz (para la empresa) en el que quedara claro que los
cambios legales (como la contabilidad) son asumidos por
el ProTec y sus defectos en la implantación también.
 Y, para el resto (nuevas funciones) podría establecerse una
tarifa por horas (demostrables), más una política razonable de
re-enganche (por si sale más barato) al mantenimiento inicial.

 ¿Por qué es necesario el mantenimiento (anual, del 10% al
30% del coste de las licencias) de un ERP?
 Supuestamente porque incorpora mejoras, tecnológicas y
funcionales, que se pueden ir añadiendo al software base
instalado.
▪ Pero, si se acaba de empezar un proyecto de implantación… ¿en
cuántos años a partir de su puesta en marcha empezaré a necesitar
mejora alguna (si el trabajo de implantación se ha hecho bien)?
 El mantenimiento debiera ser opcional (y, desde luego, no
asumible justo después de la implantación del ERP, y
nunca al principio del contrato).
 …pero debieran darse condiciones contractuales para asegurar
el re-enganche de la empresa más adelante
▪ Y tales condiciones no pueden ser (no pueden ser) el pago de las cuotas
atrasadas de años anteriores de mantenimiento, en ningún caso.

Cooperación como Criterio Discriminatorio
Parametrización y GastosAsociados

 Tras una sesión de InfoPool, los ProTecs se muestran un
tanto confusos (a no ser que hayan asistido antes a
una), pero finalmente acaban en una oferta que intenta
reflejar los términos que la empresa desea, hasta cierto
punto.
 Y aquí se verá el talante cooperador de cada ProTec, que es
claro reflejo y anticipo de la cooperación con la que va a contar
la empresa en la fase de análisis, diseño e implantación de su
ERP.
▪ Lo que la empresa ha planteado en el InfoPool es lo que desea, y no
fuerza a ningún ProTec a aceptarlo, pero es lo que le gustaría, sin
duda, recibir.Así que cada negativa de un ProTec a uno de estos puntos
representa una intransigencia que deberá ser explicada sin recurrir a
esquemas propios de calidad o, simplemente, “porque siempre lo
hemos hecho, se ha hecho así”.
 Las ofertas mejor valoradas serán las que reflejen todos
los puntos anteriormente descritos de forma expresa.

 “Parametrización” es un eufemismo utilizado por los
ProTecs que pretende significar que el ajuste de un ERP a
las necesidades de la empresa se realiza “simplemente”
cambiando algunos parámetros, y no desarrollando
software ni codificando, que supone grandes esfuerzos y
puede implicar enormes errores y dilaciones.
 Pero la verdad es que a la empresa le da igual: compra un ERP y
su implantación por el resultado, y le da igual que éste se
consiga mediante conjuros, codificación, parametrización o por
el concurso de elfos que se encargan en las máquinas de tal
ajuste.
 Así que no nos debe importar el método “interno” de los
ProTecs, sino lo que con él se consigue.
 Así que las valoraciones de “parametrización”, “desarrollo” o
simple ajuste requieren una discriminación especial.

 Si en una oferta aparece “consultoría de parametrización
(o un concepto similar) de la contabilidad (o de
finanzas)”, ¿qué cabe pensar del ERP que se va a
implantar?
 “¿Realmente mi empresa necesita que una contabilidad sea
retocada respecto del estándar?”
▪ Y, con todo, “¿¿¿¿¿A ese precio?????”
 No basta con que todos los esfuerzos de desarrollo
presupuestados se hayan estimado: hay que explicar su
necesidad (comprensible para la empresa, que compra un
paquete de gestión integrada) y detallar su ejecución.
 ¿Ajuste de interfaces gráficas? ¿Cambio de algún atributo?
¿Necesidad de integración? ¡¡Que se explique en la oferta!!
 Si la explicación no es comprensible para la empresa es
que no es necesaria (o que el precio de la licencia es falso).

 Un apartado interesante de gran parte de las ofertas es el
que refleja los gastos de “Dirección del Proyecto”, que
resuena como el cargo del “pan” en los restaurantes caros
(diez veces superior a su precio en una panadería
carísima).
 ¡Reclamen la implantación de su ERP sin dirección pagada
del proyecto!
 La dirección y la coordinación es una característica que se le
supone al implantador, como el valor a los soldados, pues es
parte de su quehacer organizativo.
 O, mejor: ¡Reclamen un precio razonable por la
implantación completa, tras un análisis también razonable
de su empresa y de su sector de actividad!
 Y es que el cargo por dirección es una diversión del presupuesto.

Hitos Paralelos e Implantación Modular
FormaciónValidada y Documentación

 Asumiendo que los hitos internos propios del ciclo de vida
del software sólo competen al ProTec, el proyecto de
implantación debiera reflejarlos (como puntos de control)
y señalar también, sobre todo, los hitos del ciclo de vida de
implantación de la empresa (prototipo, etc.) de forma
ligada (teniendo en cuenta que estos últimos son los hitos
de pago).
 El compromiso del ProTec con los hitos comprensibles
para su cliente (la empresa) tiene que ser plasmado de
forma conveniente y convincente en la planificación del
proyecto
 …pues en otro caso se adivinará que se ha tratado de una
operación cosmética de [pre-]venta que no tiene valor real en el
desarrollo del proyecto.

 No se debe pagar cuando se instala el paquete básico del
ERP, sino, por partes, cuando se produce una instalación
validada de un módulo concreto de éste
 …derivada de (y ajustada a) el prototipo operativo sobre el que
ha de basarse.
 Y si el ProTec asegura que sólo puede verse el desarrollo
modular al final del proyecto…
 …habrá que pagarle todo al final del proyecto también
▪ …y cualquier necesidad perentoria de pago anterior se deberá entender
como necesidad financiera de la empresa implantadora, lógicamente
asociada a dudas razonables sobre su capacidad para abordar y
terminar de forma exitosa el proyecto.
 La implantación de cada módulo será validada cuando se
haya dado formación sobre el mismo y se haya probado
suficientemente por sus usuarios correspondientes.

 Con el esquema propuesto, la formación debería empezar
al tiempo que la puesta en marcha de los prototipos
prescriptivos
 …pues en ellos se darán, de forma exploratoria, las
circunstancias concretas de uso del ERP por parte de la
empresa.
 La formación será bi-direccional
 Es decir: el ProTec emitirá un informe sobre su evaluación, y los
usuarios de la empresa determinarán si la formación ha sido
suficiente… o no (en tal caso, el ProTec se comprometerá a
enmendarla y repetirla).
 En cualquier caso, la formación necesitará de
documentación previa
 O sea: no se dará a viva voz, como el berebere, sino que se
apoyará en documentos explicativos auto-suficientes.

 Las interfaces gráficas debieran ser, ya de por
sí, razonables y auto-explicativas
 …pero –hay que reconocerlo– esto depende del producto
elegido (nunca del implantador)
 Los manuales de uso y administración deben ser
específicos para el proyecto
 …y no los del producto base
▪ …pues se está pagando (a buen precio) una parametrización que
requiere que se explique, técnica y operativamente, lo que se ha
hecho, cómo se usa, y sus implicaciones de desarrollo y extensión
ulteriores.
 La documentación de cada módulo deberá ser
entregada previamente a la aprobación (como hito de
pago) de tal módulo.

Reflexión Ponente/Asistentes
Debate Final

 Mensaje Básico
 ProTecs y Listas
 Prototipos
 Temas Dinerarios
 Proyectos
 Horas Facturables
 Migraciones
 Formación
 Documentación
 Mantenimiento
 Producción
 Integración

Cómo seleccionar e implantar ERPs

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (14)

Similar a Cómo seleccionar e implantar ERPs

Similar a Cómo seleccionar e implantar ERPs (20)

Más de Ricardo Devis

Más de Ricardo Devis (13)

Último

Último (15)

Cómo seleccionar e implantar ERPs