El contrato

Est a punto de comenzar la implantacin del sis-

tema que va a guiar las operaciones y la forma de tra-
bajar de su empresa; el xito del mismo va a depender
en gran medida del implantador que haya elegido. El
contrato que se haya firmado marcar la relacin entre
las dos organizaciones, por lo que es necesario asegu-
rarse de que sta se va a desarrollar en un plano de
cooperacin y de confianza mutua. Antes de empezar
el proyecto, vuelva a revisar el acuerdo y contraste la
opinin de otras empresas que ya hayan recorrido este
viaje y aprenda de su experiencia, modificando el
contrato si lo considera oportuno, para que se adapte
exactamente a las necesidades de su empresa.
El cambio cultural
Uno de los fallos ms recurrentes en la implanta-
cin de un ERP es la tendencia a querer trasladar de
forma mimtica al nuevo sistema la forma actual de
hacerlas. Aunque no lo parezca, hay ms maneras de
hacer las cosas. Los principales fabricantes de ERP
acometen el desarrollo de sus funcionalidades basn-
dose en las mejores prcticas de las ms importantes
organizaciones del planeta, y aunque esto no es siem-
pre sinnimo de excelencia, debemos sopesar las
recomendaciones que el fabricante y el implantador
puedan hacer en este sentido. La adaptacin al estn-
dar debe ser una premisa y un objetivo, y una modi-
ficacin del mismo debera ser aprobada nicamente
por el comit de direccin del proyecto. Aunque
suene dramtico, hay que tener en cuenta que un
ERP ofrece mltiples formas de realizar un proceso,
por lo que simplemente hay que buscar aquella que
mejor se adapte a nuestro modelo de negocio.
Todo esto supone un cambio cultural importante,
y es necesario que el equipo de proyecto al que
encarguemos la puesta en marcha del sistema sea
Implantacin de un ERP o
la lucha contra el destino
artculo
Csar Clavero
Profesor del rea de Operaciones del Instituto de Empresa Business School
Fernando Ruiz
Gerente de Soluciones de Negocio de Conversia IT
Ramiro Montealegre
Profesor Asociado de Sistemas de Informacin en el Leeds School of Business, Univesity of Colorado
La implantacin de un ERP en una organizacin puede compararse con el viaje de vuelta a casa de
Ulises desde Troya a taca. En este viaje, Ulises conoce o cree conocer el destino final que quiere alcanzar,
pero desconoce lo que realmente encontrar cuando llegue y los imprevistos sucesos que le ocurrirn a
lo largo de su viaje.
Este artculo pretende ofrecer a todos los clientes que se encaminen a implantar un ERP, ya sean directores
generales, directores de rea de negocio, jefes intermedios o simplemente profesionales de una determinada
organizacin, una hoja de ruta que les gue en relacin con los obstculos que van a hallar en el camino,
as como que les advierte sobre los cantos de sirena que oirn a lo largo de su particular Odisea.
24 Revista de Empresa N21 Julio - Septiembre 2007
INTERIOR 21 11/10/07 16:21 Pgina 24
Clavero, C., Ruiz, F. y Montealegre, R. (septiembre,2007). Implantacin de un
ERP o la lucha contra el destino. Revista de Empresa (21) pp. 24-35. (AR19169)
capaz de transmitir esta predisposicin al resto de la
organizacin.
La definicin de las situaciones
actual y objetivo
Business Blue Print (BBP) es un trmino que
habitualmente se utiliza en las implantaciones de SAP,
y designa una fase que abarca una definicin de la
situacin actual (as is) y el establecimiento de una
situacin objetivo (to be). sta debe ser la primera fase
a acometer, y es quizs la ms importante, ya que en
ella se va a moldear cmo queremos que funcione la
empresa. De hecho, volviendo al primer punto que
tratbamos en el artculo, debera ser plasmada en un
contrato diferenciado que condicionara cualquier
contrato posterior. El razonamiento es simple: es dif-
cil de cuantificar algo si todava no se sabe lo que se
quiere realmente.
En esta fase ha de transmitirse cul es el funcio-
namiento de los procesos de la empresa para que se
tenga una idea clara del modelo de partida. Es un
buen momento para revisar nuestros procesos y ver-
nos reflejados en un espejo. Quizs no nos guste lo
que veamos. Otras veces sirve para volver a pensar y
definir cmo se hacen las cosas. En una implantacin,
durante esta fase, una empresa descubri que no saba
ni tena documentada al detalle la asignacin de
cuentas en el enlace entre su sistema de facturacin y
su sistema contable. Llevaba funcionando durante
aos, y las personas que lo haban diseado ni siquie-
ra se encontraban ya en la empresa.Tenan dos opcio-
nes, o revisar lnea a lnea el complejo y obsoleto
programa que se encargaba de realizar la interfase, o
volver a definir cmo queran que su cuenta de
explotacin reflejase su negocio partiendo de cero.
Afortunadamente se decantaron por la segunda
opcin.
Inmediatamente despus, se presenta nuestra carta
a los Reyes Magos en cuanto a nueva funcionalidad y
automatizacin e integracin de procesos.Tanto en el
As Is como en el To Be participan los mejores cono-
cedores de las diferentes reas de la empresa, o key
users. En este punto, es importante que en nuestro
equipo exista una figura con suficiente peso especfi-
co que coordine y concilie esta carta a los Reyes Magos
con la realidad, distinguiendo entre los caprichos y el
apego a la forma habitual de hacer las cosas, y la rea-
lidad del proceso de negocio.
Una vez comprendida la situacin de partida y la
situacin objetivo, el implantador debe presentarnos
un mapa de cobertura, as como las mejores prcticas
de nuestros procesos y sus recomendaciones, basadas
en experiencias propias y en su mejor conocimiento
de la potencialidad existente en el ERP que hemos
elegido. ste es un punto crtico, la validacin del pro-
totipo funcional. Tenemos la inigualable oportunidad
de disear cmo queremos que funcione nuestra
empresa y la inigualable responsabilidad de acertar en
la eleccin de ese diseo.
A partir de aqu, se procede a la planificacin deta-
llada de las fases y tareas, as como de los hitos rele-
vantes y sus fechas de compromiso. Hay que especifi-
car la secuenciacin o paralelismo de las fases, fijar las
pruebas de carga del sistema, establecer el sistema de
comunicaciones necesario, y determinar las conexio-
nes requeridas con otros sistemas. En este momento,
han de definirse claramente las modificaciones al
estndar que sean estrictamente necesarias para que
nuestro modelo de negocio quede reflejado en nues-
tro ERP, no olvidando la premisa bsica que ya hemos
comentado de huir, siempre que se pueda, de dichas
modificaciones.
Se debe hacer una profunda reflexin para distin-
guir lo que significa una ventaja competitiva de la
empresa (y aqu es donde procede hacer las modifi-
caciones oportunas) de lo que son costumbres o for-
mas particulares de hacer las cosas que realmente no
aportan valor diferenciador. Por ejemplo, la empresa
alemana BASF emple SAP como plataforma bsi-
ca, lo que le permiti integrar varias funciones de
negocio, incluyendo finanzas, compras, produccin,
almacenamiento y control de inventarios. Despus
de dos dcadas, la empresa gozaba de ahorros signi-
ficativos y valor agregado, pero BASF continuaba
invirtiendo en SAP para estandarizar sus procesos
entre las diversas divisiones de negocio
1
. Por el con-
trario, Dell Computer trat de implantar un sistema
SAP R/3 para apoyar sus operaciones de fbrica en
1994. Segn Ferry Kelley, Chief Information Officer de
Dell, la empresa tuvo una tremenda dificultad para
implantar este sistema, puesto que SAP era muy rgi-
do para adaptarse a sus necesidades de negocio. En
Implantacin de un ERP o la lucha contra el destino
25 www.revistadeempresa.com
INTERIOR 21 11/10/07 16:21 Pgina 25
1997, un ao despus de haber abandonado el pro-
yecto SAP, Dell gener su propia estrategia de ERP
seleccionando funcionalidades especficas de dife-
rentes paquetes comerciales, incluyendo i2
Technologies (materiales), Oracle (pedidos) y Glovia
(produccin, control de inventario y almacenamien-
to). Kelly comentaba que estaban ajustando las
diferentes piezas de un puzzle y generando valor ms
rpidamente que si pusieran todo el negocio en un
sistema ERP global
2
.
Por supuesto, en esta fase tambin hay que elegir
la fecha de arranque del sistema, y ste es un tema
que suele motivar encendidos debates. La eleccin
de una fecha como el 1 de enero o semejante puede
ser conveniente para reas como la financiera, que
pueden preferir la coincidencia de los periodos
contables con el cambio de sistema. Sin embargo
tambin puede ser una fecha excesivamente com-
prometida por la acumulacin de festividades, la
coincidencia con cierres anuales y la presin a la
que pueda verse sometido tanto el equipo de
implantacin como los usuarios finales. Ha de
hacerse un anlisis riguroso de las ventajas e incon-
venientes de cada alternativa y tomar una decisin
ponderada, y sobre todo consensuada por todos los
involucrados.
Una vez definido qu queremos y cundo lo que-
remos, deberamos establecer un segundo contrato
referido de forma precisa a la implantacin. En algu-
nos casos, y dependiendo de la magnitud del proyec-
to, puede ser conveniente realizar varios contratos en
funcin de las diferentes fases definidas en el mismo.
Seguimiento y documentacin
del proyecto
Para dar cumplimiento al calendario detallado y
reflejar los hitos alcanzados y las incidencias del pro-
yecto, debemos dejar constancia escrita de las activi-
dades, y para ello tambin hemos de organizar en pri-
mer lugar las mismas.
Primero est la organizacin del equipo. Debe
estar orientada claramente hacia la definicin de
los procesos de la organizacin, estableciendo
equipos de trabajo entre el implantador y nuestros
key users. Las sesiones de trabajo deberan producir
siempre un acta final firmada por ambas partes con
los objetivos de la sesin, el estado de cumplimien-
to de las tareas pendientes, las tareas realizadas, los
objetivos alcanzados y las nuevas tareas para poste-
riores sesiones. Normalmente, nuestros key users
continan total o parcialmente al frente de sus res-
ponsabilidades anteriores al inicio del proyecto,
por lo que es necesario conciliar un elevado grado
de implicacin en el xito del mismo con la con-
tinuacin del funcionamiento de la empresa.
Debido a esto, es importante que dispongan de al
menos un tercio de la jornada para su propio tra-
bajo. Paralelamente, el implantador debe avanzar
en la parametrizacin del ERP y su adecuacin al
modelo de procesos.
Cada jefe de proyecto debera reunirse con su
equipo para revisar estas actas de avance como tra-
bajo previo a su propia reunin y para facilitar la
colaboracin e interrelacin entre todas las reas. La
preparacin de las reuniones es quizs uno de los
aspectos fundamentales, ya que la participacin de
personas de diferentes empresas o de diferentes reas
con diferentes culturas organizativas hace necesaria
una estructuracin clara de las reuniones para evitar
que stas degeneren en confusin. Es importante,
sobre todo, huir de las reuniones masivas.
El seguimiento general de la implantacin debe
hacerse a travs de las actas de avance que recojan las
reuniones de los responsables de proyecto, tanto del
implantador como de nuestra organizacin. Estas
reuniones deberan realizarse una vez a la semana de
forma oficial, y sus actas deben resumir los proble-
mas y los avances del resto de los equipos de traba-
jo, as como plantear las oportunas medidas correc-
toras.
Por ltimo, tenemos las reuniones del comit de
direccin, que deben ser reducidas en cuanto a
nmero de participantes, exceptuando la del arran-
que, la del seguimiento de los hitos ms importan-
tes y la de la celebracin de la puesta en marcha del
sistema. Sin embargo, los responsables del proyecto
deben acudir al comit de direccin y urgir su con-
vocatoria si se encuentran con problemas de difcil
solucin que necesiten de su intervencin, bien
porque los responsables no estn capacitados para
sacar el tema adelante o porque las discrepancias
Implantacin de un ERP o la lucha contra el destino
Revista de Empresa N21 Julio - Septiembre 2007 26
INTERIOR 21 11/10/07 16:21 Pgina 26
sean tan serias que se necesite recurrir a un nivel de
negociacin superior.
En el apartado de documentacin, el proyecto
debe generar una serie de documentos imprescindi-
bles para poder darlo por cerrado:
Documentacin tcnica. Incluye todo lo necesa-
rio para que cualquier otro tcnico pueda iden-
tificar, comprender y trabajar sobre las modifica-
ciones realizadas con rapidez:
Todo lo referente a instalacin e interrelacin
con el hardware, sistema operativo, bases de
datos y comunicaciones.
Todo lo referente a modificaciones al estn-
dar, documentacin detallada de qu se ha
modificado, imgenes de antes y de despus,
programas y procesos afectados, etc.
Cualquier desarrollo e informe especfico
que se haya realizado.
Documentacin funcional. Incluye todo lo
necesario para detallar las parametrizaciones y
definiciones realizadas en el sistema para reflejar
nuestros procesos de negocio.
Documentacin de usuario. Su fin es facilitar
el manejo del aplicativo y detallar la realizacin
de las tareas habituales de cada puesto de tra-
bajo.
Como norma general, se recomienda la simplici-
dad en toda la documentacin del proyecto. En este
sentido, recuerde la frase cuanto ms sencillo mejor.
La formacin
En este caso, como en la mayora, el conocimien-
to significa mayores posibilidades de tomar decisiones
acertadas y mejor aprovechamiento de las oportunida-
des. Antes de comenzar el proyecto, en el periodo que
abarca desde la decisin de la implantacin a su inicio,
es conveniente que dos o tres de nuestros usuarios clave
reciban formacin en el ERP sobre su alcance y posi-
bilidades. Esta formacin nos permitir ver cmo enca-
jan nuestros procesos en el nuevo sistema e ir profundi-
zando en las mejoras que puedan introducirse en ellos.
Posteriormente, se realizar una formacin al resto del
equipo de proyecto enfocada a las reas en las que va a
trabajar cada uno. Si se hace de golpe a todo el equipo,
se puede generar mucho ruido e incertidumbre por
parte de algunos usuarios. Esta formacin, al comienzo
al menos, no convendra que fuera excesivamente espe-
cializada, aunque s suficiente, de manera que la colabo-
racin con el equipo de trabajo del implantador se rea-
lice de una forma ms eficiente, evitando malentendidos
por la jerga particular de cada ERP, que muchas veces
provoca lamentables prdidas de tiempo. Este mayor
conocimiento del sistema que vamos a implantar afian-
za la posicin de fuerza y prestigio de nuestra organiza-
cin, evitando una imagen de dependencia excesiva
frente al implantador.
Otro punto importante es la formacin a escala
funcional, que afecta a la forma en que se ha parame-
trizado nuestro ERP. Esta formacin es consecuencia
de la decisin que hayamos tomado respecto a la ubi-
cacin del soporte funcional del sistema. Si la decisin
es hacerlo internamente, lgicamente deberemos
recibir una intensa formacin sobre el modo en que
se ha personalizado nuestro sistema; como mejor se
adquiere el conocimiento necesario es insertando a
las personas que se harn cargo del mantenimiento
dentro del equipo de trabajo del implantador. Si, por
el contrario, la decisin del soporte es externalizarlo,
bastar con que nos aseguremos de disponer de la
documentacin ya comentada en el apartado anterior,
de manera que contemos con independencia a la hora
de elegir a la empresa que se har cargo del mismo.
Existe tambin una formacin tcnica o de progra-
macin de nuestro personal informtico. Igualmente,
sta depende de la decisin sobre la externalizacin o
no del soporte tcnico. Habitualmente, la implanta-
cin de un ERP supone la introduccin en nuestra
organizacin de nuevos lenguajes de programacin,
bases de datos o incluso sistemas operativos. Se trata de
tecnologas que nuestro personal informtico desco-
noce, por lo que, si queremos que el soporte tcnico
se aloje en nuestra empresa, deberemos buscar la for-
macin adecuada, bien acudiendo al fabricante de
nuestro ERP o a empresas especializadas.
Ms all del tema formativo, es necesario, durante
la implantacin del ERP y antes de su arranque,
Implantacin de un ERP o la lucha contra el destino
27 www.revistadeempresa.com
INTERIOR 21 11/10/07 16:21 Pgina 27
tomar una decisin sobre la ubicacin del soporte del
sistema. Esta decisin no tiene por qu ser nica ni
irrevocable, pero va a matizar nuestra actitud en los
diferentes aspectos de la implantacin. El soporte
bsicamente puede ser de tres tipos:
Funcional. Requiere personal conocedor de la
parametrizacin del sistema, y es quizs el de
mayor valor aadido, al sustentar la modelizacin
de los procesos de negocio de la organizacin.
Programacin. Si es propio, permite disponer de
personal informtico capacitado y conocedor
del negocio que puede resolver el problema de
reporting, as como los pequeos desarrollos de los
ajustes habituales postimplantacin. A cambio,
supone el mantenimiento de una infraestructura
de personal normalmente muy especializada y
de poco valor aadido.
Infraestructura. Soporta el alojamiento y mante-
nimiento del hardware y del software de base
necesario para el funcionamiento del ERP.
La decisin respecto al soporte en infraestructura
est muy ligada a la poltica general en este aspecto y
habitual con el resto de sistemas. Dicha decisin ha de
ser tomada teniendo en cuenta la cultura de la empre-
sa y los costes que suponen cada una de las opciones,
y puede ser diferente en cada una de las tres tipologas
expuestas, no slo por costes, sino tambin por el
valor estratgico que puede tener. Normalmente,
cualquier externalizacin supone pagar una tarifa ms
alta, pero evita el aumento de nuestra estructura de
personal. En trminos generales, si el grado de ocupa-
cin es alto y hay sinergias con otras funciones, com-
pensar incorporar o reubicar internamente el perso-
nal necesario para dar el soporte. Igualmente, la
dimensin de la empresa influye directamente: a
menor tamao, ms difcil ser encontrar sinergias, y
proporcionalmente impactar ms en la estructura de
personal de la organizacin.
Por ltimo, en el captulo de formacin no hay
que olvidar la que debe tener lugar en relacin con
los procesos implicados en la implantacin. En algu-
nos casos, nuestros procesos pueden llevar tiempo eje-
cutndose de la misma forma, y los responsables pue-
den estar desfasados respecto a la evolucin de las
mejores prcticas en el sector. Es un buen momento,
a pesar de la experiencia acumulada, para renovar
todos nuestros conocimientos.
La integracin
A pesar de que nuestro ERP va a abarcar la mayo-
ra o una gran parte de los procesos de nuestra orga-
nizacin, no refleja la totalidad de nuestra empresa.
Despus del arranque, van a seguir existiendo sistemas
internos y externos con los que ha de relacionarse y
sobre todo integrarse para que no se produzca una
dispersin de la informacin, nuestro activo ms
valioso. Esta situacin se acentuar en mayor o menor
medida, como veremos ms adelante, en funcin del
tipo de implantacin que elijamos, bien un arranque
simultneo o big bang, o bien un arranque por fases.
Hay que tener en cuenta que puede existir, tanto
en el diseo como en la implantacin, una integra-
cin entre los sistemas actuales que no vayan a ser sus-
tituidos por el ERP (sistemas legacy) y los sistemas de
recogida de informacin en lnea, como por ejemplo
el control de presencia o de seguimiento de planta.
Una mencin especial merece el B2B (business to busi-
ness), el intercambio con sistemas externos necesario
para el funcionamiento de nuestro negocio; debe ser
cubierto por nuestro ERP, y en especial los estndares
de intercambio de informacin como EDI (Electronic
Data Interchange) y XML (eXtensible Markup Language)
o la factura electrnica. Muchas veces ocurre que la
integracin es impuesta por un tercero, caso de las
grandes superficies en el sector de gran consumo o el
Banco de Espaa en el sector bancario, por lo que
nuestro ERP debe tener la capacidad y flexibilidad de
adaptarse a estos estndares de facto. Igualmente, es
importante asegurar la integracin con las herramien-
tas ofimticas de los usuarios finales, ya que ser nece-
sario realizar presentaciones o estudios parciales en
hojas de clculo con los datos almacenados.
Dado que, como hemos comentado, las conexiones
son un punto fundamental en la integracin de los
procesos de negocio y con el resto de los sistemas de
la empresa y/o partners, deben estar definidas de forma
exacta y detallada, al igual que su fecha de incorpora-
cin a las pruebas de integracin. Deben ser diseadas
con un concepto DMZ (DeMilitarizated Zone), de
forma que cada parte deje datos que la otra lea y pro-
Implantacin de un ERP o la lucha contra el destino
Revista de Empresa N21 Julio - Septiembre 2007 28
INTERIOR 21 11/10/07 16:21 Pgina 28
cese; de esta manera se establece la frontera de respon-
sabilidad, al tiempo que se consigue que ningn pro-
grama invada el funcionamiento de un mdulo ajeno
y ningn mdulo sea dependiente de otro; lo nico
que se necesita es que sea capaz de generar un conjun-
to de informacin correcto y accesible. Aunque siem-
pre hay que medir la relacin coste-beneficio (y
muchas veces lo ms simple, como un fichero plano, es
lo ms barato), es conveniente la definicin de estas
conexiones como servicios o miniprocesos dentro de
una arquitectura orientada a servicios (SOA: Service-
Oriented Architecture). El gran desarrollo y mejora tec-
nolgica y funcional que han cosechado en los lti-
mos tiempos las herramientas especializadas de
integracin (EAI: Enterprise Application Integration),
hace que deban ser muy tenidas en cuenta como un
estndar de interconexin entre sistemas.
Nuestro ERP se va a convertir en el repositorio
central de la informacin de la empresa, y por tanto
ser la fuente de cualquier anlisis y de cualquier
minera de datos que en un futuro preveamos hacer.
Por lo tanto, es necesario asegurar el acceso a dicha
informacin, bien desde herramientas especializadas o
bien mediante la capacidad de extraccin a cubos de
informacin que nos permitan realizar los anlisis
necesarios. Es tambin importante no olvidar la for-
macin a los usuarios en la extraccin y utilizacin de
los datos almacenados en el ERP, sobre todo para los
departamentos ms analticos de la empresa, como
marketing o planificacin y presupuestacin.
Planificacin del hardware
y copias de seguridad
Otro de los requisitos para la implantacin de un
ERP y una cosa que debemos planificar desde la fase
de preimplantacin es la arquitectura de hardware y
las copias de seguridad, que deben ser dimensionadas
adecuadamente para la correcta realizacin de todo el
proyecto. En este sentido, es recomendable que exis-
tan diferentes entornos: de desarrollo, de preproduc-
cin o consolidacin, y por supuesto de produccin.
Hay determinados proyectos en los que se considera
que tambin es necesario un entorno de pruebas, que
sera un entorno estable para que los usuarios puedan
realizar sus ciclos de pruebas antes de pasar a prepro-
duccin, sin verse afectados por los cambios conti-
nuos que se realizan en el entorno de desarrollo. Por
lo tanto, debemos dimensionar un entorno de desa-
rrollo suficiente para soportar todos los desarrollos
que se van a realizar para cubrir los requisitos del pro-
yecto. El entorno de pruebas tambin se puede utili-
zar para dar los cursos de formacin a los usuarios,
puesto que, como hemos indicado anteriormente, va
a ser un entorno bastante estable. El entorno de pre-
produccin debe ser similar al de produccin, porque
en dicho entorno se va a simular el arranque y se van
a realizar las pruebas de estrs y de rendimiento con
datos similares a los reales. Finalmente, la arquitectura
de hardware del entorno de produccin debe estar
dimensionada para poder soportar todas las transac-
ciones y los volmenes de datos necesarios para desa-
rrollar los procesos de negocio de la empresa.
En todo este maremgnum, otro de los elemen-
tos clave que debemos utilizar es un programa que
controle y realice el transporte y traspaso de desarro-
llos entre los distintos entornos. Es muy frecuente
que en determinados proyectos no se controle bien
este aspecto, y en ciertas ocasiones no se sepa qu
versiones de software hay instaladas en cada uno de
los entornos. Por lo tanto, recomendamos que se uti-
lice de forma rigurosa alguna aplicacin de control,
con el objetivo de que en todo momento se conoz-
can las versiones exactas de todos los programas y
aplicaciones que hay instaladas en cada uno de los
entornos.
Adems, es imprescindible realizar copias de segu-
ridad de todos los entornos, tanto del software y la
base de datos como de los desarrollos realizados. En
muchos proyectos se ha perdido una gran cantidad de
tiempo y de informacin por no realizar adecuada-
mente esta tarea, que es bsica para el xito del pro-
yecto en caso de que haya que recuperar informacin
de las copias de seguridad.
Por otro lado, tambin necesitamos realizar un
plan de recuperacin de desastres para volver a la
situacin anterior. En las implantaciones de ERP
siempre se puede dar la situacin de que, despus de
una migracin de algn desarrollo, el sistema no fun-
cione como era de esperar, por lo que se hace nece-
sario volver a la situacin anterior. De ah la impor-
tancia de tener una buena herramienta de gestin de
versiones para volver al estado del ERP que s funcio-
naba anteriormente segn las especificaciones.
Implantacin de un ERP o la lucha contra el destino
29 www.revistadeempresa.com
INTERIOR 21 11/10/07 16:21 Pgina 29
Por ltimo, adems de planificar toda la arquitec-
tura de hardware y las copias de seguridad, necesita-
mos que se fijen y determinen todos los requisitos
para la entrada en produccin. En este sentido, hay
una serie de planes que tambin debemos tener en
cuenta para poder llegar bien al arranque: fijar la pla-
nificacin de los tests de estrs y rendimiento, deter-
minar la forma en que se va a integrar el ERP con el
resto de los sistemas de la empresa y las implicaciones
que pueden aparecer, y adems establecer cmo se
van a planificar las relaciones con todos los elementos
externos, como son la impresin, comunicacin e
interactuacin con otros dispositivos tales como lec-
tores de cdigo de barras, acceso mediante telfonos
mviles y PDA, conexin va tecnologa WiFi, reco-
nocimiento de voz IP, etc.
Pruebas de integracin
de procesos y mdulos
En todo nuestro proyecto de implantacin de un
ERP, necesitamos definir una serie de juegos de prue-
bas que servirn para validar el buen funcionamiento
del sistema una vez que se hayan superado con xito.
Dichos juegos de pruebas deben cubrir una serie de
contenidos que se exponen a continuacin.
En primer lugar, el 80% del trabajo diario de cada
proceso de negocio, puesto que es necesario que con
los juegos de pruebas se asegure que el ERP da
cobertura a las necesidades de la empresa.
En segundo lugar, se deben cubrir todos los pro-
cesos peridicos del proceso de negocio, tales como
los cierres mensuales y de ejercicio, las liquidaciones,
las declaraciones peridicas, etc., y se deben simular
con las pruebas este tipo de procesos.
Tambin es necesario que se incluyan los casos raros
o extraos pero que son frecuentes. Lgicamente, si
aparece este tipo de casos de forma peridica, el ERP
debe estar preparado para poder soportarlos.
Finalmente, se deben incluir los casos raros o
extraos que, aunque sean espordicos, han de estar
soportados por el ERP por la criticidad de dichos
casos o por el impacto que pudieran tener para el
negocio en el caso de que no lo estuvieran.
Estos juegos de pruebas debemos construirlos
desde cada proceso de negocio, y es recomendable
que los propios usuarios los creen o por lo menos los
aprueben y validen, ya que, por s mismos, y al tener
que estar necesariamente conectados con otros proce-
sos de negocio, deben ser capaces de ofrecernos todo
un modelo completo de los procesos de negocio de
empresa y la integracin entre los diferentes mdulos
del ERP, e incluso entre diferentes sistemas externos.
Pruebas de rendimiento y estrs
Adems de los ciclos de pruebas, es de gran
importancia medir el rendimiento del sistema, del
modelo y de los desarrollos realizados, tanto para los
procesos on-line como para los procesos batch.
Nuestro lema de funcionamiento del ERP debe ser
tiempo de respuesta no es lo mismo que plazo de
entrega. El tiempo de espera entre diferentes panta-
llas de pasos transaccionales o para realizar determina-
das consultas puede ser tan extremadamente alto que
llegue a desmotivar a nuestro usuario y a desesperarle
hasta el punto de hacerle abandonar una determinada
transaccin.
Por lo tanto, todos los programas desarrollados
para la implantacin del ERP han de buscar la exce-
lencia del desarrollo tcnico que minimice los tiem-
pos de ejecucin.
Para dimensionar correctamente las mquinas o
servidores de produccin, se debe tratar de simular
una situacin de cierre de periodo, o mejor de ejerci-
cio, con un nivel mximo de transacciones, de volu-
men de datos y de clculos internos. Los diferentes
departamentos, tales como produccin, comercial o
financiero, no cierran en el mismo momento, lo que
da lugar a la necesidad de que coexista en el sistema
una gran carga de usuarios y de trabajos batch, obte-
niendo informes y datos de diferentes periodos. Esta
coexistencia puede ralentizar el sistema y hay que
medirla y probarla para tratar de optimizarla.
Los procesadores, la memoria y el disco disponible
son elementos determinantes, ya que en las pruebas
de rendimiento y estrs deben estar dimensionados
para que el tiempo de respuesta sea apropiado para
cada uno de los usuarios.
Implantacin de un ERP o la lucha contra el destino
Revista de Empresa N21 Julio - Septiembre 2007 30
INTERIOR 21 11/10/07 16:21 Pgina 30
Tambin se debe tener en cuenta que, si se trabaja
con servidores o clientes remotos, hay que considerar
que las lneas de comunicaciones determinan la velo-
cidad por encima de todo, ya que son con mucho el
elemento ms lento, y que, en caso de tener diferentes
velocidades entre el origen y el destino, la velocidad
quedar determinada por el elemento ms lento.
Simulacin de arranque,
pruebas de carga, interfases
y comunicaciones
Conforme avanzamos en la implantacin de nues-
tro ERP, llega el momento en que se acerca el arran-
que del sistema en produccin. Este arranque necesi-
ta de una planificacin extremadamente cuidadosa, ya
que, adems de tener que ocuparnos de nuestro pro-
yecto de implantacin, vamos a afectar a los sistemas
existentes y a todo el personal de la empresa.
En este sentido, hay una serie de elementos que
tenemos que verificar que estn perfectamente dimen-
sionados para asegurar el xito de la implantacin.
Lo primero es que nuestra mquina de produc-
cin est correctamente dimensionada y lista con el
tiempo suficiente para poder efectuar todas las simu-
laciones de arranque del sistema.
Nuestro proceso de simulacin de arranque debe
seguir este esquema: en el entorno de produccin se
debe migrar cada vez toda la parametrizacin y los
desarrollos realizados desde el entorno de desarrollo y
que han sido probados en nuestro entorno de conso-
lidacin o preproduccin. Seguidamente, en esta
mquina se realizarn las cargas de datos desde los sis-
temas externos que deben dar lugar al estado origen
o inicial del ERP, que sera como el da cero del sis-
tema. Las cargas iniciales se refieren a los clientes exis-
tentes, proveedores, inventarios, pedidos pendientes,
facturas pendientes, asientos contables, datos estadsti-
cos, etc.
Cuando se realiza la simulacin del arranque, es
muy importante cuestionarnos si es posible simular
un da de trabajo en nuestra nueva mquina con el
nuevo ERP. Si el sistema se comunica con el entorno
habitual, hay que asegurarse de que todas las interfa-
ses y las comunicaciones funcionen para que dichas
relaciones aseguren la finalizacin correcta de todos
los procesos de negocio.
Por ltimo, es tambin imprescindible definir cla-
ramente qu histrico se va a trasladar al nuevo ERP.
No es lo mismo migrar datos histricos de los ltimos
periodos que migrar todo el histrico de la empresa.
En este sentido, para facilitar la migracin de histri-
cos, lo ms frecuente es migrar todas las partidas
abiertas y los datos histricos que tengan relacin con
ellas. El resto de los datos histricos, ya cerrados, que-
daran en un sistema bloqueado slo para consulta, a
efectos de alguna auditora o para el caso de que
necesitemos conocer algn dato o transaccin.
Criterios de satisfaccin del
cliente para el xito del proyecto
La satisfaccin del cliente final se consigue cuan-
do ste est satisfecho, o incluso ms que satisfecho,
con los resultados que se han obtenido con el proyec-
to. En ocasiones, podra darse el caso de que el equi-
po de implantacin hubiera hecho un trabajo que no
resultara totalmente satisfactorio para ellos mismos
pero que fuera muy valorado por nuestra organiza-
cin, considerada como cliente final. En realidad, lo
que valoramos son los criterios de satisfaccin pro-
pios, y no los del implantador, por lo que son dichos
criterios los que hay que compartir, gestionar y alcan-
zar para conseguir el xito del proyecto.
Cuando establecemos un proyecto entre dos par-
tes, siempre hay un cliente final, que es el que tiene la
ltima palabra sobre el xito del proyecto. Puede que
sea una sola persona o puede que sean varias personas,
aunque siempre habr un lder o alguien que est por
encima de todos. En este sentido, durante el proyecto,
el implantador tiene que comprobar en todo momen-
to que su cliente final est satisfecho con el trabajo que
se realiza en el proyecto. Es lo que denominamos cri-
terios de satisfaccin del proyecto: los elementos que
hacen que nosotros, como clientes, consideremos que
el proyecto acaba con xito. No se refieren a los ele-
mentos que se encuentran especificados en la defini-
cin del proyecto, como pueden ser el alcance, la pla-
nificacin o la calidad del mismo, etc., ya que dichos
elementos obviamente se deben cumplir segn lo
especificado por ambas partes. Los criterios de satisfac-
cin se refieren a elementos que a veces no estn espe-
Implantacin de un ERP o la lucha contra el destino
31 www.revistadeempresa.com
INTERIOR 21 11/10/07 16:21 Pgina 31
cficamente incluidos en el contrato, y que el implan-
tador tiene que detectar para conseguir que quedemos
plenamente satisfechos. El implantador tiene que revi-
sar peridicamente que el proyecto cumple todos estos
criterios de satisfaccin con vistas al arranque del
mismo, ya que, si hay algn punto abierto, nosotros
como clientes no estaremos satisfechos, e incluso
podramos negarnos a arrancar el sistema y posponer-
lo por no estar seguros del correcto funcionamiento
del ERP, situacin que perjudicara a ambas partes.
En este sentido, realizar un adecuado proyecto de
gestin del cambio ayuda a detectar estos criterios de
satisfaccin, adems de a conseguir que se controlen y
se cumplan para que no haya sorpresas finales.
El arranque
Cuando hablamos del arranque de un ERP, siem-
pre debe considerarse que se trata de una decisin sin
retorno, y que se debe tener preparada la alternativa
de continuidad en caso de fracaso. El arranque puede
fallar, pero la empresa no se puede parar, puesto que
eso sera muy perjudicial, no slo por las prdidas
econmicas, sino tambin por la potencial prdida de
imagen. Hay que tener en cuenta que es distinto que
se pare el rea de produccin (si no se producen los
productos o servicios de la empresa se para todo el
negocio) a que se pare el rea econmico-financiera
(el cierre de un ejercicio puede retrasarse unos das,
siendo esta situacin menos perjudicial que la ante-
rior).
La fecha de arranque debemos fijarla desde el ini-
cio del proyecto, aunque despus de superar todas las
fases, etapas y pruebas que hemos venido comentan-
do es posible que se cambie en varias ocasiones.
Como comentamos anteriormente, el arranque
debera hacerse coincidir con un cierre de periodo no
relevante en nuestro negocio para que el impacto
fuera menor, aunque tambin puede ocurrir que, por
los cambios sucesivos, finalmente el arranque tenga
que realizarse en un periodo crtico para la empresa
porque ya no quede otra alternativa.
Una opcin bastante vlida, siempre que fuera posi-
ble, consistira en realizar el arranque del ERP durante
los meses de septiembre u octubre, de forma que
durante los periodos que resten hasta el cierre de ejer-
cicio funcionara en paralelo con el sistema actual. En
este caso, si realizamos un paralelo durante dos o tres
meses, se puede verificar que todos los procesos son
correctos, que se obtienen los resultados adecuados y se
pueden realizar todas las pruebas necesarias para asegu-
rar que, cuando abandonemos el sistema actual y cam-
biemos al ERP, no haya ningn impacto negativo con
el nuevo sistema. Sin embargo, en esta alternativa tam-
bin puede ocurrir todo lo contrario, es decir, que apa-
rezcan diferentes errores del ERP durante los meses en
que se realiza el paralelo con el sistema actual. Si esto
sucede, aparecern incertidumbres y dudas ante el
nuevo sistema, y es posible que determinados usuarios
consideren mejor su actual sistema que el ERP. Podra
producirse hasta una pequea crisis que incluso podra
originar un retraso del arranque hasta que todas las
pruebas se terminen con xito y el paralelo no ofrezca
dudas del nuevo sistema ERP. Por otro lado, si no rea-
lizamos el paralelo, el arranque ser un punto sin retor-
no, y aunque haya errores en el sistema habr que solu-
cionar dichas incidencias en la fase de
postimplantacin, pero, probablemente, si todas las
pruebas han sido satisfactorias, no se producirn cam-
bios en la fecha de arranque, y el sistema se estabilizar
poco a poco desde el entorno de produccin.
En el arranque del ERP tambin tenemos que con-
siderar que se puede realizar por fases; es decir, pode-
mos ir implantando diferentes mdulos del ERP en
cada una de las fases del proyecto. Esta alternativa de
arranque puede ser equivalente a realizarlo por reas de
negocio, ya que cada mdulo del ERP da cobertura a
diferentes reas, como son la financiera, comercial, pro-
duccin, recursos humanos, etc. Tambin es posible
plantearnos arrancar el ERP por fbricas o centros pro-
ductivos: primero se implantara en una fbrica piloto,
y luego se ira implantando de forma sucesiva en el
resto de los centros. La alternativa contraria a las ante-
riores consiste en realizar un arranque en big bang, con-
sistente en poner en produccin en la misma fecha
todos los mdulos del ERP en todas las reas de nego-
cio y en todos los centros productivos. El estilo latino
tiende ms a realizar los arranques mediante un big
bang, mientras que el estilo germnico tiende ms a rea-
lizar implantaciones por fases.
El gran inconveniente de realizar una implantacin
por fases es que hay que crear una serie de interfases tem-
Implantacin de un ERP o la lucha contra el destino
Revista de Empresa N21 Julio - Septiembre 2007 32
INTERIOR 21 11/10/07 16:21 Pgina 32
porales que luego se desmontarn segn vaya entrando
en produccin el resto de los mdulos. Este hecho supo-
ne un mayor coste que debemos valorar, puesto que si el
incremento de presupuesto es muy grande, puede que no
nos compense el hecho de realizar una implantacin del
ERP ms controlada. En el lado opuesto estn las perso-
nas que prefieren el arranque en big bang, que tiene un
riesgo mucho mayor, pero que en muchas ocasiones es
preferible, ya que el da del arranque no habr vuelta atrs
y toda la organizacin estar mucho ms comprometida
con el nuevo sistema ERP.
Cuando se considera la implantacin del ERP en
multinacionales implantadas en diferentes pases o
geografas, lo habitual no es realizar el big bang en
todos los pases, sino comenzar por un pas y poste-
riormente ir aplicando roll-outs o extensiones al resto.
Puede ocurrir que el arranque en big bang sea la
nica alternativa. Como ejemplo, la implantacin de un
ERP en un organismo de la administracin pblica,
precisamente para cambiar sus sistemas, que no eran
compatibles con el efecto del ao 2000. La presin era
tan grande, que incluso una serie de personas de dicho
organismo tuvieron que ir a trabajar el 31 de diciem-
bre de 1999 por la noche, realizar una serie de transac-
ciones de su trabajo diario para posteriormente tomar
las uvas, y volver a su puesto de trabajo para realizar
nuevas transacciones ya en el ao 2000.Todo esto esta-
ba fomentado por el Gobierno, que quera asegurarse
de que el mismo da 1 de enero todos los sistemas de
las administraciones pblicas haban superado con xito
el temido efecto del ao 2000.
As las cosas, una vez que hemos arrancado el
nuevo ERP llegamos al final de la fase de implanta-
cin. El arranque de nuestro sistema se dar por fina-
lizado cuando se hayan cumplido los criterios de
aceptacin del proyecto. Recomendamos que dichos
criterios estn negociados e incluidos en el contrato
para evitar malas interpretaciones. Es posible que los
criterios de aceptacin consistan en realizar todos los
procesos de negocio con el nuevo ERP hasta que se
realice el primer cierre mensual contable, por lo que
el sistema no quedar aceptado hasta que haya pasado
un mes desde la fecha de arranque. En otras ocasio-
nes, los criterios de aceptacin pueden ser ms senci-
llos, y el sistema puede quedar aceptado el mismo da
del arranque despus de haber superado todos los jue-
gos de pruebas.
La ltima recomendacin que podemos hacer es
que la carga de valores del arranque ha de coincidir
con todas las realizadas durante las pruebas. En caso
contrario, deberamos abortar el arranque. Asimismo,
debemos verificar que con el nuevo ERP somos
capaces de trabajar con el juego de pruebas del 80%;
en cualquier otro caso, tambin deberamos abortar el
arranque.
Llegados a este punto, y una vez analizados todos
estos elementos, queremos desearle mucha suerte en
la implantacin del ERP. Una vez que se haya arran-
cado el sistema, es importante que empiece a preparar
el proyecto de estabilizacin del ERP durante la fase de
postimplantacin.
Implantacin de un ERP o la lucha contra el destino
33 www.revistadeempresa.com
ANEXO 1
Glosario
Arquitectura de hardware: conjunto de mquinas, servidores e infraestructura donde se realiza la instalacin
de un determinado sistema informtico.
Business to Business (B2B): realizacin de negocios de forma directa entre dos empresas mediante la utiliza-
cin de las nuevas tecnologas de Internet.
Business Blue Print (BBP): definicin detallada del modelo de funcionamiento o de negocio de los procesos que
cubre el ERP (utilizado en las implantaciones de SAP), basado en las reglas y normativas establecidas.
Comit de direccin: grupo de personas que forman el mximo rgano de decisin de un proyecto, por lo que es el
organismo encargado de tomar determinadas decisiones de alto nivel que no pueden ser tomadas en un nivel inferior.
INTERIOR 21 11/10/07 16:21 Pgina 33
Implantacin de un ERP o la lucha contra el destino
Revista de Empresa N21 Julio - Septiembre 2007 34
Cubos de informacin: extraccin de datos de un sistema para representar dicha informacin en forma de
informes agregados o grficos visuales que resumen un gran volumen de datos.
DeMilitarizated Zone (DMZ): zona neutral de intercambio de datos, de forma que cada parte deja datos que
la otra lee y procesa, consiguiendo as que ningn programa invada el funcionamiento de un mdulo ajeno y
ningn mdulo sea dependiente de otro.
Enterprise Application Integration (EAI): sistema de integracin de aplicaciones empresariales mediante
conectores estndar.
Electronic Data Interchange (EDI): sistema de intercambio electrnico de datos entre empresas.
Enterprise Resource Planning (ERP): software modular e integrado (como por ejemplo SAP) que automatiza
los procesos de negocio de una empresa (rea de finanzas, comercial, logstica, produccin, etc.) sobre un
modelo de informacin preestablecido y altamente configurable.
Entornos informticos: diferentes instancias de software, base de datos, etc., que se crean en una implanta-
cin de sistemas, tales como desarrollo, preproduccin, pruebas, produccin, etc., para facilitar el trabajo de los
diferentes equipos del proyecto.
Herramientas ofimticas: aplicaciones de usuario para su trabajo diario, tales como procesador de textos, hoja
de clculo y realizacin de presentaciones.
Interfase: programa informtico que permite el flujo de informacin entre varias aplicaciones o entre el pro-
pio programa y el usuario.
Key users: personas de la empresa con ms conocimiento y experiencia en los procesos de negocio, por lo que
su aportacin es clave en un proyecto de implantacin de ERP.
Mapa de cobertura: representacin grfica de todas las funcionalidades requeridas por el usuario, contrasta-
da con la forma en que el ERP ofrece soluciones a las mismas.
Personal Digital Assistant (PDA): dispositivo de mano originalmente diseado como agenda electrnica (calen-
dario, lista de contactos, telfonos, bloc de notas, etc.) con un sistema de reconocimiento de escritura.
Procesos batch: conjunto de procesos que se ejecutan por lotes, es decir, no se ejecutan en tiempo real y se
programan para que sean ejecutados ms adelante segn las necesidades.
Procesos on-line: conjunto de procesos que se ejecutan en tiempo real, es decir, en el mismo momento en que
el usuario los solicita.
Pruebas de carga: inclusin en el sistema de todos los datos que son necesarios para el arranque, verificndo-
se su correcto funcionamiento.
Roll-out: realizacin de una implantacin de ERP en multinacionales, de tal forma que primero se realiza en
un pas piloto, para posteriormente irse extendiendo al resto de los pases.
Sistemas legacy: aplicaciones informticas especficas para un proceso o rea de negocio, realizadas median-
te desarrollos a medida.
INTERIOR 21 11/10/07 16:21 Pgina 34
Csar Clavero Mantilla es Ingeniero Industrial por la
Universidad Politcnica de Madrid y Executive MBA por el
Instituto de Empresa Business School de Madrid. Su
dedicacin principal es la de Gerente-Consultor de empresas,
participando en numerosos proyectos de diferentes soluciones
y reas de negocio. Ha trabajado en Oracle Ibrica, Airtel
Mvil (actualmente Vodafone), PricewaterhouseCoopers
Consulting e IBM Global Services. Asimismo, es Profesor
Asociado del rea de Operaciones del Instituto de Empresa
Business School, ha escrito diversos artculos sobre gestin
de proyectos y satisfaccin del cliente, ha colaborado en
grupos de trabajo e impartido diferentes mdulos y cursos
en diferentes programas MBA, tanto en el Instituto de
Empresa Business School como en otros organismos
docentes.
Cesar.clavero@es.ibm.com
Fernando Ruiz es Gerente de Soluciones de Negocio de
Conversia IT, empresa de sistemas del grupo Casbega. Es
Master en Direccin de Sistemas de Informacin por el
Instituto de Empresa Business School y Diplomado en
Informtica por la Universidad Politcnica de Madrid.
fruiz@casbega.com
Ramiro Montealegre es Doctor en Administracin de
Empresas en el rea de gerencia de sistemas de informacin
por la Universidad de Harvard. Es Profesor Asociado de
Sistemas de Informacion en Leeds School of Business de la
Universidad de Colorado y Profesor Visitante del Instituto
de Empresa Business School. Sus reas de investigacin se
centran en la interaccin entre nuevas tecnologas de
informacin, como Internet, y la transformacin de la
organizacin en ambientes altamente inciertos. Ha estado
involucrado en el estudio de proyectos de cambio de
organizacin en Estados Unidos, Espaa, Canad, Mxico y
las regiones de Centro y Sudamrica. Su investigacin se ha
publicado en revistas como MIS Quarterly, Sloan
Management Review, Organization Science, Journal of
Management Information Systems, IEEE Transactions on
Communications, Information & Management e Information
Technology & People.
Ramiro.Montealegre@Colorado.edu
1
Sullivan, L. ERPzilla, InformationWeek (11 de julio de
2005).
2
Stein, T. Dell Takes Best-of-Breed Approach in ERP
Strategy, en InformationWeek (11 de mayo de 1998).
Implantacin de un ERP o la lucha contra el destino
35 www.revistadeempresa.com
Service-Oriented Architecture (SOA): la arquitectura orientada a servicios es un concepto de arquitectura de
software que define la utilizacin de servicios para dar soporte a las necesidades de software del usuario.
Voz IP: voz sobre protocolo de Internet, tambin llamada voz sobre IP, telefona IP o telefona por Internet; es
el enrutamiento de conversaciones de voz sobre Internet o a travs de alguna otra red basada en redes de
mquinas con direcciones IP.
WiFi: conjunto de estndares para realizar conexiones y comunicaciones de redes inalmbricas.
XML (eXtensible Markup Language): metalenguaje (lenguaje usado para hacer referencia a otros lenguajes)
extensible de etiquetas, que se propone como un estndar para el intercambio de informacin estructurada
entre diferentes plataformas. Se puede usar en bases de datos, editores de texto, hojas de clculo y casi cual-
quier cosa imaginable.
Fichas biogrficas
Notas
INTERIOR 21 11/10/07 16:21 Pgina 35