1 TESIS de Maestría en Magíster en Ingeniería en Sistemas de Información Procedimientos de selección de Sistemas ERP en grandes empresas Tesista: Lic. Fernando J. Martini Director: Magister José Pedro Pagano Codirector: Magister Inés Casanovas Ciudad Autónoma de Buenos Aires, 2011
195
Embed
TESIS de Maestría en Magíster en Ingeniería en … TESIS de Maestría en Magíster en Ingeniería en Sistemas de Información Procedimientos de selección de Sistemas ERP en grandes
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
1
TESIS de Maestría en
Magíster en Ingeniería en Sistemas de Información
Procedimientos de selección de Sistemas ERP en grandes
empresas
Tesista: Lic. Fernando J. Martini Director: Magister José Pedro Pagano Codirector: Magister Inés Casanovas
Ciudad Autónoma de Buenos Aires, 2011
2
Resumen
El impacto de la velocidad del cambio tecnológico en los negocios y la
necesidad de integrar la estrategia con la tecnología obliga a comprender a los
Sistemas de Planeamiento de Recursos Empresariales (en inglés Enterprise
Resource Planning en adelante será llamado ERP) en todas sus dimensiones.
Si bien existe mucho material al respecto, no se observa un abordaje de la
problemática —desde un posicionamiento claro— dentro del conjunto del saber
en administración. Precisamente, en este sentido, esta tesis busca brindar una
diferente forma de afrontar esta problemática y toma como punto de partida la
disciplina de la administración como fuente de inspiración. Debido a la amplitud
y complejidad del tema, esta tesis se limitará al proceso de selección de un
Sistema ERP en grandes empresas y propondrá un procedimiento acorde al
paradigma vigente en la disciplina.
3
ÍNDICE
TEMA PÁGINA
Capítulo I. Introducción 5
1. Objetivos de la tesis y metodología empleada 5
2. Contribución de la tesis 7
3. Estructura general del trabajo 8
Capítulo II. Estado del arte 9
1. El software 10
2. ¿Qué es un Sistema ERP? 11
3. La década del 50 15
4. La década del 60 16
5. Las décadas del 70 y del 80 17
6. La portabilidad 19
7. La portabilidad en la arquitectura cliente-servidor 29
8. La década de los 90 30
9. Nuevas tecnologías 33
10. Nuevos requisitos de los negocios 34
11. Rechazo de la dirección al desarrollo de sistemas 34
12. A medida de los usuarios y no de las organizaciones 37
13. De funciones a procesos 38
14. La fragmentación de los procesos 41
15. Los Sistemas ERP como integradores de funciones en procesos 43
16. Los mejores en su clase 44
17. Propuestas existentes para la selección de Sistemas ERP 48
Capítulo III. Descripción del problema. Hipótesis de trabajo 69
1. Fundamentos de la problemática 69
2. Objetivos e hipótesis de trabajo 75
Capítulo IV. Solución propuesta (El sustento teórico) 77
1. El ciclo de vida de los Sistemas ERP 78
2. Objetivo de la etapa de selección 81
3. Restricciones que operan en la selección 91
4. Las organizaciones consideradas como sistemas altamente complejos 93
5. El modelo mental financiero 94
Capítulo V. Solución propuesta (El proceso de selección) 103
1. De la formación de los grupos de selección 105
2. Duración del proceso de selección 114
3. Planificación de actividades 117
4. Nombrar el gerente de proyecto 119
5. Designar un coach 119
6. Buscar las prácticas poco comunes 122
7. Detectar los problemas 126
8. Detectar oportunidades 131
9. Conformar el grupo de detalle 133
10. Buscar productos 135
11. Confeccionar el RFP 136
12. Estimar costos 136
13 Primer nivel de análisis y pre-selección de productos 137
4
14. Jerarquía del modelo AHP para la pre-selección 140
15. Segundo nivel de análisis y selección final 141
16. Las demostraciones 142
17. Elaboración del dictamen final 144
Conclusiones y futuras líneas de investigación 150
1. Conclusiones 150
2. Futuras líneas de investigación 152
Referencias 153
ANEXO I 157
ANEXO II 191
5
Capítulo I
Introducción
1. Objetivos de la tesis y metodología empleada
1.1 Objetivo general
La tesis tiene como objetivo proponer un conjunto de procedimientos y
elaborar pautas a seguir para la selección de Sistemas ERP en grandes
empresas, que estén acordes al paradigma vigente en la disciplina de la
administración.
1.2. Objetivos específicos y metodología empleada
a) Selección de información vinculada a los Sistemas ERP (etapa 1).
b) Determinación de las propuestas existentes (etapa 2).
c) Evaluación de las propuestas existentes (etapa 3).
d) Elaboración de una propuesta afín con el objetivo general (etapa
4).
Etapa 1 (selección de información vinculada al tema): Se buscó
información vinculada al tema en bibliotecas, sitios especializados, librerías,
revistas especializadas, consultas con especialistas, consultas con
proveedores de Sistemas ERP, tesis, newsletters, papers, información digital
disponible en la Web, etc. Se seleccionó el material que provenga de fuentes
confiables y acreditadas, se compiló la información relevante y se organizó de
tal manera que se facilite su análisis.
Etapa 2 (determinación de las propuestas existentes en materia de
selección de Sistemas ERP): Considerando esta tesis dentro de las ciencias
fácticas, la misma operaró en sus tres dimensiones (histórica, presente y
futura). Para comprender los aspectos administrativos de la selección de un
Sistema ERP resulta inevitable realizar una investigación de la evolución de
6
sus mutaciones y transformaciones, como único medio de comprender su
estado actual y sus características presentes. De esta forma se pudo
establecer el estado del arte de los Sistemas ERP y rescatar las propuestas, en
relación a su selección.
Se analizó:
Nichos de mercado, funcionalidades cubiertas, cobertura
geográfica, volúmenes de ventas, y demás atributos que
surgieron como destacables.
Las encuestas existentes sobre el grado de satisfacción que
brindan los Sistemas ERP, como así también los problemas que
se han presentado desde su existencia.
Los beneficios esperados contra los beneficios obtenidos.
Los cambios ocurrido en los roles organizacionales y
fundamentalmente dentro del área de sistemas.
El ciclo de vida según distintos autores.
Los Sistemas ERP vs los desarrollos.
Las consecuencias del ―best of breed‖.
La visión financiera sobre los Sistemas ERP.
Los Sistemas ERP en la era de la información.
La integración de los Sistemas ERP con el resto de los sistemas
de la organización.
Etapa 3 (evaluación de las propuestas existentes): Desde el criterio del
pensamiento complejo se abordará la comprensión y explicación de los
hallazgos realizados. El análisis de las propuestas partió, fundamentalmente,
de la aplicación de las cinco disciplinas propuestas por Senge, y de otras
teorías relacionadas (teoría de las restricciones, el coaching, etc.).
Se trata de un estudio teórico que es exacto con las referencias que
respaldan su análisis y muy severo aún con la consistencia lógica de los
resultados.
Se analizaron las propuestas existentes desde distintas ópticas:
7
La gestión de cambio organizacional.
La carga de la novedad.
El manejo de la complejidad.
Los modelos mentales.
La reingeniería.
Etapa 4 (elaboración de una propuesta afín con el objetivo general): el
diseño se basó en supuestos o datos conocidos y se aplicó la deducción y el
análisis lógico teniendo en cuenta los postulados de la administración moderna,
ya enunciados, y las especiales características de los Sistemas ERP.
Se puso especial énfasis en:
La complejidad de la selección.
El análisis de procesos.
Quiénes y cómo deben intervenir en la selección.
La utilización de un coach.
Las nuevas funciones en la organización.
El gerente de procesos.
El proceso de benchmarking.
2. Contribución de la tesis
Este trabajo aspira contribuir al desarrollo de las organizaciones en
función de que sus integrantes incorporen otra visión del proceso de gestión de
los Sistemas ERP. Esta visión esta despojada de toda influencia comercial, en
un contexto donde muchas de las ideas que prevalecen están fomentadas e
impulsadas por enérgicos intereses empresarios. Esta visión le permitirá a la
dirección mejorar la toma de decisiones, en función de desarrollar un
procedimiento eficaz utilizando criterios preestablecidos y un modelo
matemático que los incorpora en un proceso donde intervienen múltiples
decisores.
El procedimiento que propone esta tesis enmarca un conjunto de
métodos dispersos dentro de un armado teórico coherente y bajo el influjo de
8
las ideas vigentes en la disciplina administrativa. El mismo espera aportar a la
dirección una herramienta que le permita tomar una decisión pudiendo
comprender cabalmente la importancia, sus consecuencias, las secuelas, los
beneficios esperables, separar lo central de lo accesorio y abordarla con la
participación de todos los involucrados.
3. Estructura general del trabajo
En el capítulo II se desarrollará el estado del arte, efectuando un
exhaustivo análisis de los motivos por los cuales el mercado se inclinó a los
Sistemas ERP por sobre los desarrollos a medida. En este mismo capítulo se
expondrán las propuestas existentes sobre la selección de los Sistemas ERP.
En el capítulo III se explicarán los conceptos fundamentales que deben regir la
selección de un Sistemas ERP y en el capítulo IV se desarrollará la propuesta
concreta. En el cierre de la tesis se elaborarán algunas conclusiones y se
propondrán algunas líneas de futuras investigaciones. En el anexo A se
desarrolla la demostración del modelo denominado Proceso Analítico
Jerárquico (en inglés Analytic Hierarchy Process o AHP) y en el anexo B la
demostración del modelo Proceso Analítico Jerárquico Borroso (en inglés
Fuzzy Analytic Hierarchy Process o FAHP).
9
Capítulo II
Estado del arte
El filósofo Thomas Kuhn escribió en 1962 un libro titulado ―La estructura
de las revoluciones científicas‖, donde argumenta que la evolución de las
ciencias es por saltos: a un período de ciencia normal le sucede un período de
crisis, luego un momento de ciencia extraordinaria y luego una nueva etapa de
ciencia normal que inicia nuevamente el ciclo. Cuando la realidad supera al
conocimiento del paradigma científico vigente se produce lo que Kuhn llama
anomalía. Esta anomalía anuncia la llegada de un cambio paradigmático (etapa
de la ciencia extraordinaria); todo lo que antes se conocía (los métodos,
hipótesis y teorías) pierde validez y debe replantearse a la luz del nuevo
paradigma. Esta posición epistemológica de Kuhn, sobre la que se posiciona
esta tesis, sostiene que para que el nuevo paradigma se imponga debe cumplir
con dos condiciones: primero, ser aceptado por gran parte de la comunidad
científica; segundo, dejar problemas sin resolver, problemas que den lugar a la
etapa de la nueva ciencia normal.
La ciencia, como cualquier actividad humana, se realiza socialmente y,
por ende, está fuertemente influenciada por la sociedad y su cultura. De la
misma forma, la evolución científica influencia toda actividad humana y
proyecta sobre ella todos los cambios de paradigmas afectando toda su cultura.
La administración, como expresión cultural de la sociedad y rama del
conocimiento sometida a los cambios paradigmáticos de las ciencias, se
encuentra en un período de conocimiento extraordinario. Esta etapa tiene su
origen en los ensayos realizados entre 1976 y 1988 por el pensador francés
Edgard Morin sobre el pensamiento complejo, y se consolida con la divulgación
del libro La Quinta Disciplina (1990), de Peter Senge.
El pensamiento complejo implica oponerse al pensamiento simplificador
que anteriormente presentaban las ciencias. La sabiduría consistía en eliminar
la complejidad de los fenómenos, tratando de descubrir el orden simple que los
conducía. Estas formas mutilaban el conocimiento de la realidad, que siempre
10
era mucho más compleja que lo que se pretendía. La simplificación, más que
ayudar a resolver los problemas, los agudizaba en la ceguera que
imposibilitaba ver la totalidad y el allanamiento de todos los matices. Senge,
junto a otros pensadores del MIT (Massachusetts Institute of Technology),
retoman esta idea del pensamiento complejo y la proyectan sobre la
administración.
Este nuevo paradigma indica un camino distinto para superar los
problemas organizacionales. Este supone la creación de organizaciones
inteligentes, donde, según palabras de Senge (2000, p.11) ―la gente expande
continuamente su aptitud para crear los resultados que desea, donde se
cultivan nuevos y expansivos patrones de pensamiento, donde la aspiración
colectiva queda en libertad y donde la gente continuamente aprende a
aprender en conjunto‖. Para este autor, la forma de crear organizaciones
inteligentes es a través de la práctica de cinco disciplinas: el pensamiento
sistémico, el dominio personal, los modelos mentales, la visión compartida y el
aprendizaje en equipo. Estas cinco facultades no son una forma de simplificar
la compleja realidad de las organizaciones, sino que atacan la complejidad sin
destruirla en pequeñas e incomprensibles partes de un todo.
Este marco teórico resultará productivo para entender muchas de las
afirmaciones que se harán en esta obra y cuáles son, las nuevas reglas del
paradigma vigente.
1. El software
A pesar de los numerosos esfuerzos realizados hasta ahora en el ámbito
de la computación, los científicos y técnicos no han logrado aún encontrar la
forma de crear máquinas capaces de aprender a resolver problemas por ellas
mismas. Esto implica que, para que las computadoras presten un buen servicio
a las tareas de los seres humanos, es necesario brindarles las instrucciones
detalladas para su operación, o sea programarlas. A los programas de
computadora técnicamente se los llama software.
11
El software se clasifica en dos grandes grupos:
a) De sistemas: es el conjunto de programas que permiten utilizar los
recursos físicos de la computadora (hardware). Este, a su vez, se
subdivide en otros tres grupos: uno es el sistema operativo, que
permite temporizar sucesos, asignar recursos y monitorear eventos.
Otro grupo son los programas utilitarios que se utilizan para realizar
tareas rutinarias como copiar o crear archivos, imprimir, etc. El tercer
grupo esta integrado por los programas traductores de lenguajes
cuya finalidad es convertir las instrucciones escritas en lenguaje de
alto nivel (COBOL, BASIC, Pascal, etc.) a lenguaje de máquina. En la
práctica, a los programas utilitarios se los considera parte del sistema
operativo y así se tratará en esta tesis.
b) De aplicaciones: se refiere a los programas que han sido escritos con
el fin de utilizar la computadora para una función específica y
destinada al usuario final. En este último grupo se enrolan los
Sistemas ERP.
2. ¿Qué es un Sistema ERP?
Se dará un caso a modo de introducción de lo que es un Sistema ERP.
El caso consiste en las operaciones de una empresa que vende casas
prefabricadas a la que se denominará, ficticiamente, Easy House.
Desde su PC, un cliente instalado cómodamente en un cuarto de su
casa efectúa, por intermedio de Internet, la compra de una casa prefabricada,
de acuerdo con los modelos y especificaciones establecidas por el fabricante.
En esta misma operación se fija la forma de pago y se estipula un determinado
plazo de entrega. El departamento de ventas de la empresa Easy House (EH)
dará vista del pedido del cliente, verificará en su computadora que se hayan
acreditado los fondos del anticipo solicitado, emitirá la orden de fabricación
que, desde luego, sólo podrá realizarse si previamente está registrado el
pedido y autorizada la venta. En función de las órdenes de fabricación y
12
apoyados en la funcionalidad del Sistema ERP, más los beneficios de la
comunicación vía Internet, se le enviarán a los proveedores de EH (maderas,
sanitarios, cerámicas, etc.) los pedidos de materiales correspondientes. A su
vez, en su sector de fabricación, EH emitirá el apropiado plan de producción y
se aprestará a recibir los materiales que los proveedores enviarán
oportunamente. Una vez recibidos los materiales y registrada la operación en el
sistema se procederá, en función de la forma y plazo de pago acordados, a
efectuar la operación de transferencia de fondos de EH a los proveedores.
Simultáneamente a todas estas operaciones se realizarán las registraciones
contables necesarias y se producirán los informes programados a los niveles
de jefaturas y de gerencias. A medida que la fabricación de la casa avance se
actualizarán los lotes de producción, que estarán acordes a las formulas
preestablecidas. La registración organizada de las operaciones permitirá en
cualquier momento, establecer una prolija trazabilidad de los productos
terminados. El departamento de logística estará preparado para que en el
momento exacto en que la casa esté terminada, se disponga de los recursos
para su traslado e instalación. Cuando esta operación haya finalizado, se
contabilizará la deuda pendiente del cliente y se le emitirá un mail reclamando
su pago. De la misma forma en que se registró el pedido, el cliente efectuará el
pago de la deuda desde el cuarto de su casa.
Un caso como el relatado o parecido, resulta hoy en día poco común,
pero sin duda alguna impensable en la época de los inicios de la computación.
Tener una empresa con un sistema funcionando como lo sugiere el párrafo
anterior, operando en múltiples ubicaciones geográficas y a gran escala, no es
algo que lleve poco esfuerzo y cueste barato. Por el contrario, es posible que
se invierta mucho dinero y años de esfuerzo para que al final no se obtenga ni
siquiera algo parecido a lo que se pretende.
Para precisar qué son los Sistemas ERP se utilizará una definición
elaborada sobre una idea de José Esteves y Joan Pastor (2000, p.1) y que
dice: ―los Sistemas ERP son software, prefabricado e integrado, cuya
finalidad es colaborar con los sistemas de información en las organizaciones,
típicamente compuesto por un conjunto amplio de subsistemas estándar
13
(cadena de abastecimiento, recursos humanos, finanzas, etc.) y que son
susceptibles de ser adaptados a las necesidades específicas de cada cliente”.
Algunos autores dicen que el nombre de Sistemas ERP no es el adecuado y
utilizan otros, como Enterprise Systems (ES), Integrated Vendor Solutions,
Integrated Standard Software, Enterprise Application Systems, etc. Si bien se
puede coincidir con que Sistemas ERP no es el más feliz de los nombres, sí es
el más utilizado; y como un nombre es simplemente un signo, como bien dice
Magariños de Morentin (1991, p.32), ―las cosas no significan en sí mismo sino
que significan para un hombre, para una sociedad o para un conocimiento que
de ellas se tiene‖, por eso es que para esta tesis se utilizará el nombre de
Sistemas ERP.
A continuación se analizarán detenidamente la definición.
a) Prefabricado: esto da la idea de que el programa no ha sido
desarrollado para una necesidad concreta de una determinada
empresa, sino que está pensado para atender generalidades.
b) Integrado: significa que los datos se comparten independientemente
del área que los genera, evitando que los procesos se dividan en
compartimentos estancos.
c) Compuesto por un conjunto amplio de subsistemas estándar: aquí lo
importante es la noción de amplitud; es decir que un Sistema ERP es
considerado como tal cuando cubre la mayoría de las operaciones
del negocio. Aquí también es importante el concepto de estándar,
que está unido al de prefabricación y que se opone al de desarrollo
de software a la medida de la organización.
d) Su uso es susceptible de ser adaptado a las necesidades de cada
cliente: si el software no tiene capacidades mínimas de adaptación a
las diversas prácticas de negocio, jamás podrá comercializarse como
un Sistema ERP.
14
Es importante detenerse para comprender, con claridad, el concepto de
integración.
Davenport (2000 p. 185) afirma que ―una de las razones principales de
emplear un SE (sistema ERP) radica en lograr la integración de los procesos y
las funciones del negocio.
Stephen Harwood (2003 p. 1) asevera que ―El sistema ERP puede,
simplemente, ser descripto como un sistema integrado de información que
sirve a todos los aspectos del negocio‖.
Marianne Bradford (2008, p. 5) escribe ―con el objetivo de eliminar
muchos, si no todos, los aislados almacenes de datos, un sistema ERP integra
toda la información: las compras de la organización, los recursos humanos, la
producción y las ventas que, posiblemente, anteriormente estaban contenidas
en sistemas separados‖
El concepto de integración es el más presente en las definiciones de
Sistemas ERP, y básicamente se puede expresar como la capacidad de un
sistema de información de mantener una base de datos común a todos sus
sub-sistemas, a la facultad de manejar reglas de negocios comunes a todos, a
la existencia de tecnología de hardware y software parejas, y a la consistencia
de los datos a lo largo de todos los procesos de negocios.
Grabot, Mayère y Bazet (2008, p.1) definieron la integración como la
creación de un flujo continuo de materiales, valores, información y decisiones a
fin de reducir los residuos que son producto de múltiples interfaces entre
actividades aisladas.
En O’Brien y Marakas (2007, p.260) dicen: ―El software ERP está
compuesto por módulos integrados de aplicaciones‖. Esta aseveración da pie
para establecer la diferencia entre el concepto de integrado y el de modular. En
principio, es importante destacar que la integración tiene que ver con los
procesos de negocios y la modularidad con las funciones previstas por el
sistema. Más adelante, en este capítulo, se desarrollarán con detenimiento las
15
diferencias entre procesos y funciones. Pero, fundamentalmente, la
modularidad tiene por objetivo facilitar el ensamble de los componentes, su
reparación o posible reemplazo. En la misma página O’Brien y Marakas dicen
―Los módulos son relativos a funciones específicas de la organización‖.
La modularidad de los Sistemas ERP es, esencialmente, una necesidad
de diseño para que pueda ser factible su implementación por etapas, y su
convivencia con otros sistemas.
* * *
La dirección de hoy presenta un gran desconcierto y se formula
preguntas del tipo: ¿Por qué tengo que invertir tanto dinero y tiempo en un
sistema computarizado? ¿Por qué estos sistemas tienen tantos errores? ¿Por
qué tengo que confiar en un proveedor que también le vende el mismo sistema
a mi competidor? ¿Cómo nos vamos a diferenciar si todos desarrollamos las
mismas prácticas? ¿Por qué, después de tanto esfuerzo volcado sobre este
sistema, la empresa está igual o peor que antes? ¿Por qué compramos un
sistema a un proveedor externo y en el departamento de sistemas tenemos
más gente que cuando desarrollábamos nuestros propios sistemas
informáticos?
Para empezar a dar respuesta a estas y muchas otras preguntas, es
necesario efectuar un análisis de cómo se ha llegado a los actuales Sistemas
ERP. Es importante extenderse en el relato, porque para entender los sistemas
altamente complejos es indispensable conocer los procesos que les dieron
origen.
3. La década del 50
En los años 50 comenzaron a comercializarse las primeras
computadoras: la Remington Rand lanzó la UNIVAC I con gran éxito y muy
pronto IBM salió a competir con su famosa IBM 650. En esta primera etapa, el
desarrollo del software estuvo a cargo de los proveedores de hardware; nadie
16
pensaba en la posibilidad de que el software pudiera constituirse en un
producto independiente. El ámbito de aplicación era exclusivamente científico o
de ingeniería. La utilización de la computadora para soluciones de negocio era
inexistente. En 1959 se creó la empresa Applied Data Research (ADR), que
prestaba servicios de programación. ADR disponía de equipos de
programadores que, bajo contrato, se ponían a disponibilidad de alguna
empresa, generalmente para adaptar programas suministrados por las casas
de ventas de hardware. Este tipo de organizaciones pueden considerarse las
antecesoras de las actuales casas de software.
4. La década del 60
Si bien los años 60 estuvieron signados por el desarrollo de aplicaciones
de negocio para empresas comerciales, su construcción continuó a cargo de
los fabricantes de hardware. Para su adaptación a cada organización, las
empresas debieron dedicar un gran esfuerzo de reprogramación.
Las aplicaciones de negocios predominantes fueron:
a) Contables (diario, subdiarios, cuentas corrientes, mayor y
balance).
b) Gestión de inventarios.
c) Liquidación de sueldos y jornales.
Los proveedores de hardware entregaban, junto con la compra de la
computadora, bibliotecas de software gratis, ya que los costos del hardware
eran tan grandes que minimizaban cualquier posible negocio de software.
A modo de anécdota, es interesante destacar que la primera patente de
software fue otorgada a ADR en 1965 por un programa que se denominó
Sorting System y que, en definitiva, ADR nunca llegó a comercializar. La
segunda patente fue concedida también a ADR en 1970, por su producto
denominado Autoflow, un documentador de sistemas que generaba como
salida un diagrama de flujo. Para fines de los 60, ya existían algunas empresas
17
dedicadas únicamente a la comercialización de software. Básicamente,
producían programas de los denominados utilitarios.
5. Las décadas del 70 y del 80
Las bibliotecas de software gratuito que proveían las empresas
vendedoras de hardware seguían creciendo en importancia hasta que un juicio,
iniciado por ADR contra IBM por monopolizar la industria del software, obligó a
un brusco cambio en el mercado. En 1970, IBM anunció que ya no entregaría
más las bibliotecas de software gratuitos, excepto los sistemas operativos.
En estas décadas se produjo la gran explosión de las software-houses,
denominación que se les dio a las empresas de la industria del software. En
1967, y según Software History Center (2002), la empresa International
Computer Programs, Inc. (ICP) publicó el primer catálogo de productos de
software. Para el año 1971, este reconocía que veintinueve empresas habían
vendido software por valor de más de un millón de dólares en el año. En 1976,
esta misma lista contenía más de 100 productos que pertenecían a 64
software-houses: 52 productos habían superado los 5 millones de dólares, 15
habían pasado los 10 millones, 4 los 20 millones. El que se destacó por sus
ventas fue el producto TOTAL, un programa de administración de base de
datos desarrollado por la empresa Cincom, que generó ventas por un valor
mayor a 50 millones de dólares.
En 1971, Luanne Johnson fundó Argonaut Information System, para
vender sistemas de remuneraciones y contabilidad. Así se convirtió en la
primera software-house de productos para negocios. Por otra parte, Sandra
Kutzig creó Ask Computer Systems, introduciendo el primer MRP (Material
Requirement Planning, que en español es: planeamiento de requerimiento de
materiales) multiusuario.
En 1972 fue fundada SAP, la empresa pionera en la industria de los
Sistemas ERP. Ese año también nacieron J.D.Edwards y Oracle, pero esta
última se lanzaría a la industria de los Sistemas ERP muchos años después.
18
En 1978 aparece Baan, conformándose ya en esta década cuatro de la cinco
grandes en ventas de Sistemas ERP. La quinta es PeopleSoft, que saldría al
ruedo recién en 1987.
En estas décadas la expansión de las fábricas de software fue
incesante. En 1986 SAP ya estaba en los 100 millones de dólares de ventas
anuales y en 1989 superaba los 1.000 empleados.
En una encuesta realizada por ITtoolbox durante el año 2004
(www.ittoolbox.com) a nivel mundial, sobre organizaciones globales dio por
resultado el siguiente Market share: SAP 37,50%, PeopleSoft/J.D. Edwards
16,50%; Oracle 10,60%, SSA Global/Baan 7,70%, Microsoft Great Plains
1,90%, QAD 1,00%, Lawson 1,30%, SYSPRO 0,50% y otros 21,00% (Fig.: 1).
Fig.: 1; market share ERP (ITtoolbox, 2004)
En el mercado actual no se observan variaciones significativas ya que, si
bien crece Oracle, esto fue a consecuencia de la adquisición de Peoplesoft. Y
aparece como un importante proveedor Infor pero, en este caso, por la
adquisición de SSA Global y otras. También crece, con importancia, Microsoft
como un significativo competidor.
Es de destacar que los grandes jugadores mundiales del mercado de
Sistemas ERP, deben enfrentarse a un vasto número de competidores locales
19
y regionales, sobre todo, cuando compiten en empresas locales o regionales.
6. La portabilidad
Antes de entrar en la década de los 90, es necesario detenerse un
momento para entender el concepto de portabilidad. En este sentido, debe
conocerse qué han significado UNIX, SQL y la arquitectura cliente-servidor en
la computación electrónica.
6.1. UNIX
Desde los inicios de la computación hasta fines de los 80, los sistemas
operativos de las computadoras eran desarrollados por las mismas
casas que fabricaban el hardware, y diseñados especialmente para una
determinada computadora. Nunca se daba a conocer al mercado cómo
era que estaban construidos, secreto celosamente guardado y cuidado
por las empresas de hardware porque:
a) Vender hardware y software como una sola cosa permitía una
mayor capacidad diferenciadora.
b) Ninguna de las empresas quería cederle a otra el esfuerzo de
su propio trabajo.
Como consecuencia de esta fuerte unión entre hardware y sistema
operativo, quienes desarrollaban software de aplicación estaban
prácticamente forzados a hacerlo exclusivamente para un determinado
tipo de máquina. Ya se ha explicado que COBOL fue un intento de
desarrollar un lenguaje común para cualquier hardware y no lo logró.
Precisamente, las particularidades de cada sistema operativo
constituyeron los impedimentos principales. A las software-houses les
resultaba poco menos que imposible desarrollar las aplicaciones para
equipos distintos, lo que en definitiva reducía el mercado al cual podían
dedicarse. Por otro lado, no hay que olvidarse de que IBM tenía una
20
enorme participación en el mercado de hardware, por lo que, en general,
las empresas desarrolladoras de aplicativos sólo lo hacían en ese nicho.
Las otras marcas de hardware casi no contaban con software de
aplicación, ya que el mercado era poco significativo frente a un costo de
producción muy elevado. Tal es así que las dos primeras empresas
grandes que surgieron en el mercado de Sistemas ERP, SAP y J. D.
Edwards, se desenvolvieron en el mercado de IBM; la primera, para
mainframe (equipos centrales para soportar gran cantidad de usuarios) y
la segunda para minicomputadoras (equipos departamentales). UNIX es
un sistema operativo con marca registrada por AT&T (2011,
http://enciclopedia.us.es/index.php/Unix) que surgió de un proyecto de
investigación iniciado en 1965 desde la división Bell Labs de esa misma
compañía. El proyecto, al que se denominó MULTICS, tenía como
objetivo desarrollar un nuevo sistema operativo para lograr gran
potencialidad de cálculo y almacenamiento. Este proyecto generó
interesantes resultados, pero Bell le fue quitando esfuerzo al no lograr
obtener un producto final estable para comercializar. En 1974, AT&T
decidió entregar lo que hasta ese momento se había desarrollado a
varias universidades de EE. UU. para su investigación. Esta
determinación implicó difundir todos los secretos, entregando el código
fuente de los programas. Este sistema operativo fue ampliamente
divulgado entre los estudiantes. Era la primera vez que los alumnos de
las universidades contaban con un sistema operativo que podía ser
ejecutado en sus computadoras y con los detalles de cada una de sus
instrucciones.
Los estudiantes hicieron innumerables aportes, generando un sólido y
robusto sistema operativo. En 1977, cuando AT&T descubrió las
bondades de este sistema operativo ampliado, decidió patentarlo con el
nombre de UNIX. Ya era tarde, pues el sistema estaba a disposición del
todo el mundo. Con algunas variantes, fue adoptado por todas las casas
de hardware como sistema operativo para sus equipos. Así, Hewlett
Packard desarrolló su propio ―UNIX‖ al que denominó HP-UX, IBM
desarrolló el suyo, al que llamó AIX, SUN lo denominó Solaris, etc.
21
A partir de la difusión de este sistema operativo la desvinculación entre
hardware y sistema operativo fue irreversible. La difusión de ―UNIX‖ fue
de gran beneficio para las empresas productoras de software de
aplicaciones. Estas casas desarrollaron aplicativos que podían ser
ejecutados en variadas instalaciones ―UNIX‖. A este nuevo ambiente
tecnológico se lo denominó de sistemas abiertos, en contraposición a los
sistemas cerrados o propietarios, que son los que mantienen una
estrecha unión entre sistema operativo y hardware.
6.2. SQL
Para entender qué es SQL hay que saber qué es un Sistema de
Administración de Base de Datos (en ingles Data Base Management
Systems o DBMS) y, aún antes, qué es una base de datos.
Siguiendo la definición de Laudon y Laudon (2002, p. 234), una base de
datos es una colección de datos organizados a fin de que sirvan a
muchas aplicaciones al mismo tiempo. Anteriormente, cada aplicación
tenía su propio conjunto de datos. En el ejemplo de la figura 4 puede
observarse que existen dos juegos de datos de productos: uno para el
sistema de ventas y el otro para el de producción. Esta forma de trabajo
significaba duplicar datos (redundancia) y posibles inconsistencias entre
ellos. A modo de ejemplo: el mismo producto podía tener unidades de
medidas diferentes en cada archivo. En la figura 3 reaparece el ejemplo
de la figura 2, pero en este caso ambos sistemas utilizan la misma base
de datos.
22
Laudon y Laudon (2002, p. 235) afirman que un DBMS es un tipo de
software especial para crear y mantener una base de datos.
Anteriormente a los DBMS, la actualización de los datos, la consulta, la
Fig.: 2; ordenamiento de datos previo a la aparición de las bases de datos
Fig.: 3 Autor: F. Martini
Fig.: 3; base de datos
23
seguridad y la integridad de los datos, permanecían bajo el control de
cada programa. En cambio, cuando se utilizan DBMS los programas
gestionan los datos por su intermedio (Fig.: 4).
SQL nació en 1975 en el marco de un proyecto de investigación de IBM
denominado System/R, cuyo objetivo era demostrar la operabilidad de
un DBMS relacional. No se entrará en detalles sobre lo que
específicamente es un ―DBMS relacional‖, ya que nada agregaría a los
objetivos planteados. Simplemente se dirá que es un tipo especial y el
más difundido de DBMS. El proyecto System/R incluía el desarrollo de
un lenguaje de consulta para este tipo de DBMS. El lenguaje resultante
se denominó SEQUEL, un acrónimo de Structured English Query
Language (en castellano Lenguaje Estructurado de Consultas).
Posteriormente, con la primera implementación experimental de este tipo
de DBMS, se renombró bajo el acrónimo de SQL o Structured Query
Language (Lenguaje Estructurado de Consultas). El proyecto, que había
sido publicado en una revista científica de EE. UU., interesó a un grupo
Fig.: 4; DBMS
24
de ingenieros de Menlo Park, California, quienes en 1977 formaron una
compañía llamada Relational Software Inc. para construir un DBMS
relacional basado en SQL. El producto logrado se denominó Oracle y en
1979 comenzó a comercializarse adelantándose dos años a la
finalización del trabajo de System/R de IBM. Relational Software Inc.,
hoy renombrada como Oracle Corporation, es actualmente la número
uno en ventas de DBMS y la número dos en ventas de Sistemas ERP.
SQL recibió el gran espaldarazo cuando en 1986 se publicó el estándar
ANSI/ISO, ya no sólo como un lenguaje de consulta sino también de
actualización de datos. De esta forma, los DBMS con lenguaje SQL
comenzaron a adquirir una gran popularidad que se sumó a la fama
alcanzada por el sistema operativo UNIX. Sobre la plataforma UNIX se
instalaron la gran mayoría de los DBMS basados en SQL. Así se generó
una fuerte alianza entre UNIX y SQL que revolucionó el mercado
informático.
6.3. Arquitectura cliente-servidor
Durante fines de los 80 una nueva forma de procesamiento, a la que se
denominó arquitectura cliente-servidor, comenzó a difundirse entre los
desarrolladores de aplicaciones. Los antecedentes que llevaron a pensar
en esta nueva forma de trabajar fueron:
a) La proliferación de computadoras personales.
b) La amplia difusión de los DBMS basados en SQL.
c) El gran desarrollo de las tecnologías de comunicaciones.
En general, todas las aplicaciones (y fundamentalmente las de negocios)
se forman con tres tareas bien diferenciadas:
a) La obtención y actualización de los datos desde y hacia un
almacenamiento secundario (hard disk).
b) La interacción con los usuarios (ingresar datos por pantalla,
25
mostrar los resultados de una consulta, etc.).
c) Las ―reglas de negocio‖; que son todo el resto de instrucciones
que no tienen que ver con la interfaz usuario ni con la gestión de
datos y que refiere a la problemática específica del negocio.
La arquitectura de procesamiento cliente-servidor se basa en la
separación de estas tareas básicas entre distintos procesadores.
Aquí es necesario explayarse, pues sobre la arquitectura cliente-servidor
se asientan los actuales Sistemas ERP. A la primera variante de esta
arquitectura se la denomina ―de dos capas‖ y consiste en otorgar la
función de la gestión de datos (DBMS) a una computadora, y el manejo
de la interactividad con el usuario, junto con las reglas de negocio, a
otra. A la primera función se la llama servidor o back-end y a la segunda
cliente o front-end (Fig.: 5).
Fig.: 5; arquitectura cliente-servidor de dos capas
26
La arquitectura de dos capas es bastante conflictiva ya que, si bien
descarga el computador central de mucho procesamiento y lo deriva a
los distintos clientes (tantos como usuarios de la aplicación hubiera), trae
muchos inconvenientes para la actualización del software. Hay que
trasladar cada modificación de programas a la PC de cada usuario.
Además, la instalación de todo el aplicativo en cada PC obliga a tener
una máquina poderosa en cada puesto de trabajo.
Existe una metodología intermedia que consiste en poner toda la
aplicación en un servicio de archivos en red (Fig.: 6). En dicha
modalidad, todos los clientes acceden a la aplicación por intermedio de
la red desde un almacenamiento compartido. De esta forma, se alivia la
tarea de actualización de programas pero se aumenta la carga de
trabajo de la red de datos.
Fig.: 8 Fig.: 6; arquitectura cliente-servidor de dos capas con la aplicación en servicios de red
27
En la actualidad, esta tecnología es poco usada. De la arquitectura ―de
dos capas‖ se pasó a la ―de tres capas‖ que consiste en separar las
tareas en las tres funciones básicas anteriormente comentadas. La
interfaz con el usuario es la que permanece en el cliente; las reglas de
negocio se trasladan a un servidor al que se denomina servidor de
aplicaciones, y la tercera capa es la del DBMS, que se suele instalar en
otro procesador al que se lo llama servidor de datos (Fig.: 7).
La arquitectura de tres capas evita los inconvenientes de la anterior ya
que, por un lado, centraliza las aplicaciones en un único equipo; y por
otro achica los requisitos de los clientes (da lugar a lo que se denominan
clientes flacos).
Así, los clientes necesitan poco más que un navegador de Internet y una
simple conexión a un servidor Web, productos que en su gran mayoría
adhieren a las normas diseñadas por el consorcio World Wide Web
Fig.: 9 Fig.: 7; arquitectura cliente-servidor de tres capas
28
Consortium (W3C, en www.w3.org). Este consorcio, formado por más de
500 organizaciones, tiene como objetivo principal mantener un estándar
para el desarrollo de tecnología Web, sosteniendo el compromiso de la
interoperabilidad y la independencia de las marcas proveedoras de
software para Internet.
Ahora es posible retomar el concepto de portabilidad, a la que se puede
definir como la capacidad del software de migrar de un tipo (marca o modelo)
de hardware a otro sin grandes esfuerzos.
En resumen: en los inicios de la computación, el sistema operativo
estaba estrechamente ligado al hardware. Los fabricantes de hardware creaban
el sistema operativo para una determinada computadora (marca o modelo) que
podía ser operada únicamente por ese software que tampoco servía para otra
computadora. El software aplicativo, a su vez, estaba atado al sistema
operativo. Por lo tanto, si una casa de software producía, por ejemplo, un
sistema contable, lo hacía para un determinado equipo con un determinado
sistema operativo. Si la casa de software quería desarrollar comercialmente el
sistema para otro equipo, estaba obligada a rescribir todos los programas casi
por completo.
Al aparecer UNIX, la unión entre el sistema operativo y el hardware se
hizo mucho más débil. Un aplicativo escrito para UNIX de un determinado
equipo no requería de un gran esfuerzo de reescritura para ser ejecutado en
otro. Esto aumentó la portabilidad de las aplicaciones y, por supuesto, las
posibilidades comerciales del producto.
La aparición de los DBMS relacionales con el lenguaje SQL aumentó
mucho más la portabilidad. A partir de ellos, el software aplicativo manejó un
lenguaje estándar para la gestión de los datos.
Por último, la arquitectura cliente-servidor terminó por ampliar los límites
de la portabilidad al permitir que los usuarios armaran la configuración de
―aplicación – sistema operativos – hardware‖ más conveniente en cada una de
29
las capas.
7. La portabilidad en la arquitectura cliente-servidor
La portabilidad a nivel de cada capa de la arquitectura cliente-servidor
actualmente se presenta de la siguiente forma:
7.1. A nivel del DBMS
El proveedor de la aplicación ha dejado de preocuparse, en su
software, por el manejo de los archivos (la gran diferencia entre los
distintos sistemas operativos). Con respetar las instrucciones SQL
ANSI/ISO se asegura el buen funcionamiento en cualquier DBMS
ANSI/ISO compatible. La portabilidad en cuanto a la gestión de datos
pasó a ser un problema del proveedor del DBMS, quien es, en
definitiva, el que tiene que adaptarse a cada sistema operativo.
7.2. A nivel de las reglas de negocio
Esta capa debe acomodarse a cada sistema operativo. Hoy en día es
común que las grandes casas de software ofrezcan sus programas con
versiones para ser ejecutados en, por lo menos, Unix, Windows y Linux.
7.3. La portabilidad del software en el cliente
Está impactada por dos factores muy importantes:
a) El estándar que se creó de facto, bajo la tecnología de la más
grande de las corporaciones de venta de software -Microsoft- y su
afamado sistema operativo Windows en sus múltiples versiones.
Prácticamente no existe proveedor de software que no haya
desarrollado un producto que no corra bajo el ambiente Windows.
30
b) Los navegadores (en ingles browsers), son ejecutables en
Windows, desde luego, pero también existen versiones para la
mayoría de los sistemas operativos tales como Linux, OS2, SCO,
etc. En general, los navegadores trabajan con todas las
instrucciones previstas por el consorcio W3C.
En la figura 8 se muestran algunas de las variantes en cuanto a la gran
cantidad de posibilidades que se han abierto para la instalación de Sistemas
ERP, como ejemplo se menciona solamente algunos de los más importantes.
Esta variedad en la oferta no sólo amplió enormemente el potencial mercado
de cada proveedor de Sistemas ERP, sino que además bajó sustancialmente
los costos del hardware y de los sistemas operativos con relación al software
aplicativo.
8. La década de los 90
La década de los 90 se caracterizó por grandes cambios para la
Fig.: 8; la portabilidad de las aplicaciones en cuanto a la gestión de los datos
31
industria y el comercio en general, producidos esencialmente por tres factores:
económicos, sociales y tecnológicos.
Dentro de los factores económicos hay que señalar una generalización
mundial de medidas que favorecieron el libre cambio entre los países. De esta
forma, la producción manufacturera se trasladó a los países donde la relación
calidad y costo de mano de obra brindaban mejores resultados. Como
consecuencia de esta nueva realidad, las empresas debieron desarrollarse y
competir en todo el mundo; por ende, los proveedores y clientes dejaron de ser
locales para pasar a ser globales. Este proceso, conocido como globalización,
obligó a que las empresas desarrollaran métodos y técnicas que les permitieran
planear, organizar, dirigir y controlar las operaciones en todo el mundo.
La sociedad de esta década ya no se satisfacía con los productos y
servicios baratos creados gracias a las bondades de la producción en serie.
Las empresas se vieron obligadas a atender necesidades específicas del
mercado y a diseñar productos y servicios a la medida de los clientes. A partir
de esta nueva perspectiva del cliente, ha aumentado fuertemente la oferta de
productos, sumado a un notable acortamiento de su ciclo de vida. Así, en los
70 y 80 el ciclo de vida de un modelo de automóvil podía llegar a los 10 años;
en los 90 apenas llegaba a los 3.
En lo tecnológico, se destaca un poderoso desarrollo de las
comunicaciones y la computación; el crecimiento de la inversión privada en
esta área, sobre todo en los países periféricos, generó nuevos y mejores
servicios. Como afirma Don Tapscott en su libro La Economía Digital (1997,
p.57) ―Mientras en la antigua economía, la industria automotriz era el sector
clave, en la nueva el sector predominante son los nuevos medios de
comunicación, los cuales son producto de la convergencia de las industrias de
la computación, la comunicaciones y el contenido‖. Los cambios tecnológicos
se hicieron evidentes en la industria. La tecnificación y robotización de los
procesos industriales generaron un aumento de la productividad y de la calidad.
Estos cambios fueron muy notables en la industria del hardware, lo que
permitió bajar sustancialmente el costo y mejorar tremendamente las
32
prestaciones. Una agenda electrónica de bolsillo de los 90 ya tenía más
capacidad de memoria que las computadoras de los 50.
En los inicios de los años 90 ya estaban dadas las condiciones para la
gran explosión de la venta de los Sistemas ERP. La portabilidad permitió que
las software-houses ampliasen las fronteras de sus mercados a un bajo costo y
la baja de los precios de las computadoras minimizó los costos de inversión en
hardware. La globalización requirió a las empresas contar con elementos que
les permitieran controlar las operaciones mundiales. Y a esto se sumó un factor
imprevisto: el efecto año 2000.
El efecto ―año 2000‖ fue un gran obstáculo para las empresas. El
problema radicaba en que el software desarrollado durante prácticamente
medio siglo contenía datos referentes a fechas que consideraban sólo los dos
últimos dígitos para el valor del año. Por ejemplo: cuando se solicitaba un
ingreso de fecha por pantalla, sólo se pedía el ingreso de los dos últimos
dígitos del año (78, 80, 98, etc.) y el programa asumía que los dos primeros
dígitos eran el 1 y el 9. De modo que, para que las empresas pudieran sortear
bien este obstáculo, había dos opciones:
a) Revisar toda la programación. Luego, una vez localizados los puntos
de fallo, corregirla, probarla y convertir los datos históricos.
b) Comprar un nuevo software que ya tuviera resuelto el problema del
año 2000.
Las empresas que tenían software de aplicación adquirido a software-
houses no se vieron muy afectadas, ya que la responsabilidad de la adaptación
recayó sobre las empresas productoras. Pero la gran mayoría de las
compañías que tenían software desarrollado dentro de las mismas
organizaciones (en inglés in-house) decidieron aprovechar la oportunidad para
migrar hacia Sistemas ERP, en lugar de enfrentar la faraónica tarea de la
corrección. Esto motivó que el período comprendido entre el año 1996 y el año
2000 fuera el de mayores ventas de Sistemas ERP.
33
Ni la baja de los precios del hardware, ni la portabilidad, ni la
globalización hubieran sido suficientes para consolidar a los Sistemas ERP de
no haberse operado un cambio en las expectativas de los clientes y una nueva
forma de entender a las organizaciones, tal como se explicará a continuación.
9. Nuevas tecnologías
En los primeros años de la década de los 80, en las áreas de tecnología
de la información se tenía la perspectiva de que el mercado del software se
orientaría hacia un mayor desarrollo de aplicaciones in-house. La tecnología
creciente de los DBMS incluía cada vez más herramientas para mejorar la
productividad del desarrollo (forms, querys, etc.), se pasaba por el esplendor de
los lenguajes de cuarta generación (herramientas que por su supuesta facilidad
permitirían a los usuarios finales desarrollar sus propios productos de software)
y se hablaba de las bondades que ofrecían las nuevas herramientas CASE
(programas para automatizar el desarrollo de software).
Pero la realidad fue muy distinta. Lejos de facilitarse la tarea de análisis
y programación, todo se tornaba más sofisticado año tras año. Algunos de los
elementos que aumentaron la complejidad son:
a) El incremento en el uso de las comunicaciones.
b) La arquitectura cliente-servidor impactó en la forma de programar y,
lejos de facilitarla, la complicó bastante.
c) El ambiente de aplicaciones gráficas y la revolución de Internet
obligaron al conocimiento de nuevos lenguajes (JAVA, HTML, CGI,
XLM, etc.).
d) Nuevos servicios tuvieron que ser incorporados dentro de las
aplicaciones (FTP, e-mail, buscadores, etc.).
e) Hubo que lidiar con las sutiles pero a veces enloquecedoras
diferencias de los ―UNIX‖ y los SQLs.
34
10. Nuevos requisitos de los negocios
La globalización de la economía obligó a las empresas a operar y
competir en todos los mercados. Esto trajo aparejado, desde un punto de vista
tecnológico, que las grandes corporaciones buscaran proveedores tecnológicos
capaces de dar asistencia en todas las localizaciones geográficas donde
tuviesen instalaciones. La globalización complicaba muchos los desarrollos in-
house, ya que las empresas no podían erogar tanto dinero en personal de
sistemas lo suficientemente capacitado como para atender las instalaciones
mundiales. Por otro lado, se multiplicaron las fusiones y adquisiciones de
empresas, lo que suscitó la necesidad de solucionar los conflictos
organizacionales y los problemas que este reacomodamiento creó en los
sistemas de información. En este sentido, los Sistemas ERP se presentaron
como una buena alternativa de solución porque podían ser utilizados como
instrumentos de homogeneización de procesos.
11. Rechazo de la dirección al desarrollo de sistemas
En la alta dirección de los años 90 se produjo un rechazo al desarrollo
de sistemas. A continuación se describirá dos de las causas fundamentales
que lo generaron.
11.1. Grandes demoras en los proyectos de desarrollo
Dice Edward Yourdon (1993, p. 118): ―Tal vez el problema más visible al
que se enfrenta actualmente la profesión de desarrollo de sistemas sea
el de la productividad. La sociedad y los negocios modernos parecen
exigir cada vez más, más sistemas, más complejidad y todo más rápido.
El analista se enfrentará al retraso en los nuevos sistemas que se
necesitan desarrollar y al tiempo que se requiere para construir un
sistema individual nuevo‖.
Eduard Yourdon (1993, p.119) comenta que una investigación realizada
por Robert Alloway y Judith Quillar (1982), de la escuela Sloan del MIT,
35
reveló que el retraso invisible era típicamente 5,35 veces mayor que el
retraso visible de los nuevos sistemas. El retraso invisible se refería a la
demora en el desarrollo de nuevos sistemas que los usuarios no
solicitaban oficialmente porque aún estaban aguardando que se
terminasen los proyectos en desarrollo retrasados (retraso visible).
Para tener una idea de cuántos eran los retrasos visibles se puede
considerar el estudio realizado por Caper Jones (Edward Yourdon 1993,
p.119) que, en una encuesta de aproximadamente 200 grandes
organizaciones de EE. UU., encontró que el promedio de los proyectos
se demoraban un año y se excedían en un 100% del presupuesto
original.
Esta problemática de los desarrollos a medida es también compartida
por el desarrollo de los Sistemas ERP, pero son problemas de
producción de las software-houses que sus clientes jamás conocen,
salvo cuando las desarrolladoras (en el afán de vender) cometen la
imprudencia de prometer funcionalidades para determinadas fechas que,
en general, no se cumplen.
11.2. Los errores de los desarrollos terminados
En el estudio mencionado, Caper Jones exponía que el software
desarrollado en EE. UU., presentaba entre 3 y 5 errores por cada 100
instrucciones, una vez probado y puesto en funcionamiento. Esta
situación se volvía insostenible en los desarrollos in-house. Para los
usuarios, los problemas eran derivados de la incapacidad de los
desarrolladores y esto los inducía a pensar en que algo hecho fuera de
la organización sería mucho mejor.
En realidad, los desarrollos de los Sistemas ERP de hoy en día también
tienen un alto porcentaje de errores, pero su depuración y corrección es
mucho más rápida porque el sistema es usado en numerosas
organizaciones simultáneamente, cosa que no ocurre con un desarrollo
36
a medida (Fig.: 9).
Según Yourdon (1993, p. 125), un programador tenía sólo el 50% de
probabilidades de corregir con éxito un error de codificación, y este
promedio se reducía bruscamente si el programador debía modificar
más de 10 instrucciones. En los años 80, entre el 50% y el 80% del
trabajo que se hacía en los departamentos de sistemas se relacionaba
con la revisión, modificación o corrección de errores.
La dirección de las organizaciones de los años 80 percibía que los
sistemas encargados se demoraban más de lo previsto, que el producto
entregado tenía miles de errores (bugs), y tampoco podían tener la certeza de
saber que lo que el analista desarrollaba era lo que la organización
medianamente esperaba y, para colmo, cada mes el costo de personal para
mantener los sistemas desarrollados aumentaba. Ante este panorama no
parecía descabellado que la dirección hubiese preferido comprar paquetes ya
Fig.: 9; proceso de corrección de errores
37
desarrollados y adaptarse a sus limitaciones, antes que encarar desarrollos a
medida.
12. A medida de los usuarios y no de las organizaciones
Los desarrollos a medida se construían atendiendo más a las
necesidades de los usuarios que a las de la organización. En esta práctica
errónea, los analistas de sistemas han tenido una gran responsabilidad.
Edward Yourdon (1993, p. 46-47) dijo sobre el usuario: ―El participante más
importante en el juego de los sistemas es alguien que el analista conoce como
usuario. El usuario es aquel (o aquellos) para quien (quienes) se construye el
sistema. Es la persona a la que tendrá que entrevistar, a menudo con gran
detalle, a fin de conocer las características que deberá tener el nuevo sistema
para poder tener éxito‖. Y agregó: ―El usuario es el CLIENTE y, como en
muchas otras profesiones, el cliente siempre tiene la razón; sin importar lo
exigente, desagradable o irracional que pueda parecer‖.
La sumisión incondicional a los deseos del usuario ha sido uno de los
mayores errores cometidos por los analistas de sistemas. El cliente es la
organización para la que se trabaja y la responsabilidad ineludible de los
analistas de sistemas debe ser la de cuidar la continuidad de las
organizaciones y la salud de las mismas. Si las demandas del usuario pueden
afectar a la organización, hay que buscar la solución del problema, a pesar del
riesgo que se corre en la búsqueda de la misma. Dijo Peter Drucker (2002, p.
120)
respecto a las responsabilidades de la alta gerencia: ―El profesional debe
tener autonomía. No puede ser controlado, supervisado o dirigido por el cliente.
Debe ser independiente, sabiendo que a su conocimiento y a su juicio le ha
sido entregado el poder de decisión. Pero el fundamento de su autonomía, su
razón de ser, es que se ve a sí mismo comprometido con el interés público‖.
Una de las consecuencias de atender desmedidamente los pedidos de
los usuarios fue, que cuando el usuario que trabajaba en el desarrollo del
sistema cambiaba, el sistema automáticamente perdía vigencia. El nuevo
usuario advertía la existencia de un sistema a la medida de su antecesor y al
38
poco tiempo de ejercer sus funciones solicitaba bruscos cambios.
La dirección de las organizaciones no permanecía ajena a esta mala
praxis de los analistas de sistemas (también facilitada por usuarios que
pensaban más en ellos mismos que en la organización) y sufría los constantes
reclamos de los nuevos usuarios. Los Sistemas ERP aparecieron como una
buena opción para finalizar con este conflicto constante. Como dice su
definición, los Sistemas ERP son estándar, y no atienden particularidades o
caprichos de los usuarios.
13. De funciones a procesos
En el año 1993, la administración recibió un gran shock producido por la
aparición del libro Reingeniería de Hammer y Champy, fundamentalmente
porque cambió la forma de ver las organizaciones. Tan fuerte fue el impacto
que obligó a replantear los sistemas de información y el rol que ellos debían
cumplir en las empresas.
Para dichos autores, las organizaciones deberían orientarse a los
procesos y no a las funciones, como ocurría hasta ese momento. Pero para
que se entienda esta teoría primero debo explicar dos conceptos: función y
proceso.
13.1. Funciones
Según la explicación de Hammer y Champy (1994, p. 12-13), los
negocios tenían un estilo de trabajo que derivaba del modelo
organizacional de la fábrica de alfileres descripto por Adam Smith en La
riqueza de las naciones, publicado en 1776. Este filósofo y economista
se había dado cuenta de que la tecnología de la revolución industrial
había creado oportunidades sin precedentes para que los fabricantes
aumentaran la productividad, y así redujeran el costo de los bienes en
forma sustancial. En este modelo ideal, incorporó el concepto de que un
número de trabajadores especializados en tareas especificas, realizando
39
cada uno una tarea en la producción del alfiler, podían fabricar más
alfileres en un día que el mismo número de personas realizando cada
una un alfiler por completo. Smith decía ―Un hombre estira el alambre,
otro lo endereza, el tercero lo corta, el cuarto le saca punta, el quinto lo
pule por encima para recibir la cabeza; para hacer la cabeza se
requieren dos o tres operaciones distintas; ponérsela es un trabajo
especial, blanquear los alfileres es otro; hasta meterlos en el papel es
una industria en sí misma‖. Y explica que ―Estas diez personas podían
hacer entre todas, hasta cuarenta y ocho mil alfileres en un día; pero si
todas hubieran trabajado en forma separada e independiente, y sin que
ninguna hubiera sido educada en este particular negocio, ciertamente
una no habría podido hacer ni veinte, y acaso ni un solo alfiler en un
día‖.
Hammer y Champy (1994, p. 13) dicen ―Las aerolíneas de hoy, las
siderúrgicas, las firmas de contadores, las fábricas de fichas de
computador, etc., se han estructurado todas en torno a la idea central de
Smith: la división o especialización del trabajo y la consiguiente
fragmentación de la obra. Cuanto más grande sea la organización, más
especializado será el trabajador y mayor será el número de pasos en
que se fragmente la obra‖.
Este conjunto de tareas repetitivas, en las cuales cada individuo de la
organización se especializa, se denomina función. Luego agregan: ―La
conocida estructura piramidal de la mayor parte de las organizaciones se
adaptaba muy bien a un ambiente de alto crecimiento, porque era
escalable. Cuando la compañía quería crecer, le bastaba agregar
trabajadores en la base del organigrama, según se necesitaran, y luego
ir colocando los estratos administrativos de arriba‖.
13.2. Procesos
Hammer y Champy (1994, p. 37) definen al proceso como ―un conjunto
de actividades que recibe uno o más insumos y crea un producto de
40
valor para el cliente‖. Posteriormente sostienen: ―Bajo la influencia de la
idea de Adam Smith de dividir el trabajo en sus tareas más simples y
asignar cada una de éstas a un especialista, las compañías modernas y
sus administradores se concentran en tareas individuales de este
proceso – recibir el formulario de pedido, escoger los bienes en la
bodega, etc. – y tienden a perder de vista el objetivo grande, que no es
otro que poner los bienes en las manos del cliente que los pidió‖.
Los autores decían que la forma de organizar las empresas en funciones
ya no daba resultado; que habían cumplido su objetivo en una etapa en la que
lo importante para los negocios era crecer, una época en la que todo lo que se
producía se vendía.
En un mensaje que ellos señalan como central dicen (1994, p. 29): ―Ya
no es necesario ni deseable que las empresas organicen su trabajo en torno a
la división del trabajo de Adam Smith. Los oficios orientados a tareas son
obsoletos en el mundo actual de clientes, competencia y cambio. Lo que las
compañías tienen que hacer es organizarse en torno al proceso‖.
La preocupación por la integración de las funciones en las
organizaciones había sido planteada por importantes autores en años
anteriores. Por ejemplo, el famoso libro de Johnson, Kast y Rosenzweig,
titulado en ingles The Theory and Management of Systems, de 1967, señalaba
que la clásica departamentalización era un ejemplo de especialización
funcional que, unido al principio de alcance del control (cantidad de empleados
subordinados a un supervisor) que recomendaba un campo angosto de control,
generaban estructuras verticalmente alargadas, que creaban problemas para la
integración sistemática de actividades.
De acuerdo con Hammer y Champy, las organizaciones debían ser
replanteadas desde cero. Rehacerlas desde una hoja en blanco y diseñarlas
teniendo en cuenta el proceso en lugar de pensar en las funciones, daría
asombrosos resultados. Ya han transcurrido varios años desde estas
afirmaciones y hoy se puede decir que la idea de repensar las organizaciones
41
desde el papel en blanco no dio los resultados esperados. Dice Thomas
Davenport (2002, p. 164), quien fue uno de los consultores en administración
que más fervorosamente ha apoyado los proyectos de reingeniería en los años
90: ―Muchos proyectos de reingeniería abarcaron metas de cambio muy
ambiciosas en la fase de diseño pero durante la ejecución se abandonaron o se
diluyeron considerablemente‖. Y al analizar sus causas explica: ―No les
resultaba práctico construir sus propios sistemas, y los paquetes disponibles
aún no se habían explorado ampliamente porque no respaldaban diseños
específicos‖. El gran problema de pensar las empresas desde cero o del papel
en blanco, como gustaban decir los especialistas en reingeniería, era la
imposibilidad de construir todos los sistemas informáticos que dieran
posibilidad de vida al nuevo diseño empresarial (supuestamente orientado a
procesos).
14. La fragmentación de los procesos
De un párrafo del libro Reingeniería se extrae (1994, p. 30): ―Los que
toman parte en un proceso miran hacia adentro de su propio departamento y
hacia arriba, donde está su superior: pero nadie mira hacia fuera, donde está el
cliente. Los actuales problemas de rendimiento que experimentan las empresas
son la consecuencia inevitable de la fragmentación del proceso‖. En esta
fragmentación de procesos crecieron quienes diseñaron sistemas hasta los 90:
raramente se involucraba más de un sector. Lo típico era desarrollar el sistema
de remuneraciones, el de facturación, el de cuentas a pagar, el sistema
contable, etc. Todos los proyectos enfocaban el sector o la función. Los
motivos por los cuáles las cosas eran así, además de lo explicado por Hammer
y Champy, fueron los siguientes:
14.1. Limitaciones técnicas: en los comienzos, la tecnología de
hardware permitía una cantidad limitada de usuarios y una cantidad
limitada de datos on-line. Era inevitable seccionar los sistemas.
Para seccionar un sistema en subsistemas, lo aconsejable es
efectuar la separación donde se minimice la relación entre los
42
elementos (Fig.: 10). Los vínculos por donde se efectúa el corte
pasan a ser output e input de los nuevos subsistemas.
Por efecto de la extrema separación funcional de los procesos del
negocio, las divisiones sectoriales eran los límites aparentes del
sistema a desarrollar. De esta manera, se contribuyó
fenomenalmente a destruir los procesos en funciones. Por ejemplo,
ocurría que desde el sistema de cuentas a pagar no se sabía qué
nota de pedido había dado origen a cada factura; o cuál había sido el
remito recibido en el almacén que había permitido el pago de la
factura; o sucedía que desde el sistema de ventas era incontrolable si
el producto comprometido en la nota de pedido del cliente tenía stock
suficiente debido a que el dato estaba en el sistema de producción,
etc.
14.2. Crecimiento en el tiempo: en el proceso de sistematización de
Fig.: 10; division de un sistema
43
las organizaciones, el tiempo y los recursos necesarios para
desarrollar cada sistema eran sumamente importantes. Para evitar
incurrir en un gasto elevado, los desarrollos se encolaban en el
tiempo. Por ejemplo: un año se desarrollaba el sistema de
Facturación y al siguiente el de Cuentas Corrientes. Cuanto más
tiempo transcurría entre un desarrollo y el otro, más diferencias
tecnológicas entre uno y otro había.
La calidad del desarrollo variaba mucho, en función de los recursos
utilizados en cada momento y de los vaivenes económicos del
negocio. Así se iba avanzando y año tras año, y la madeja se hacía
más y más grande. Los costos de mantenimiento crecían ferozmente.
La complejidad era inmanejable y la mayoría de los sistemas
obsoletos. Todo esto hizo que el desarrollo de sistemas in-house se
transformara en algo insostenible.
15. Los Sistemas ERP como integradores de funciones en procesos
Hasta fines de los años 90, la realidad de los sistemas de información de
las organizaciones fue caótica. Dicen Laudon y Laudon (2001, p. 233): ―La
tendencia de los sistemas fue crecer de forma independiente, sin seguir algún
plan maestro. Cada área funcional desarrolló sistemas aislados de los de otras
áreas funcionales.‖.
Los trabajos de reingeniería no dieron resultado, fundamentalmente por
la dificultad de desarrollar un sistema informático que soporte un diseño
específico y la imposibilidad de liberarse absolutamente de las ideas originales
de Adam Smith respecto de las bondades de la división del trabajo.
El fracaso total del principio de la ―hoja en blanco‖ obligó a la búsqueda
de una solución ajustada a las posibilidades. Así es como los Sistemas ERP
surgieron en forma de “solución integradora”.
Los Sistemas ERP abrieron una nueva posibilidad para que las
44
organizaciones integraran mejor los procesos y lograran un mayor nivel de
acoplamiento. Estos sistemas se caracterizan por tener una base de datos
común a toda la organización, el software ya pensado en una orientación a
procesos y una tecnología homogénea para todos ellos.
16. Los mejores en su clase
Existen muchos profesionales de sistemas que no entendían el valor de
la integración que aportan los Sistemas ERP y prefirieron desarrollar la política
informática denominada ―los mejores en su clase‖. Esta estrategia consistió en
incorporar a la organización distintos paquetes de software (el supuestamente
mejor en realizar cada función o proceso) y luego, internamente o con ayuda de
terceros, conectarlos para integrar los procesos. Seguir esta política fue
inconveniente debido a lo siguiente:
16.1. Es contraria a principios sistémicos
La política de los mejores en su clase, intrínsecamente, supone que es
posible optimizar un sistema optimizando los subsistemas componentes;
por eso busca obtener el mejor software para cada función o proceso
(subsistema) y no el mejor software para la organización (sistema total).
Un principio sistémico indica que, para optimizar un sistema, es
necesario suboptimizar los subsistemas que lo componen. Por ejemplo:
en una empresa industrial, el departamento de ventas debe vender lo
que la empresa puede producir, por lo cual debe suboptimizarse en
función de la producción posible. A su vez, producción no puede
producir todo su máximo potencial sino que debe producir en función de
lo que el departamento de ventas puede vender. Por lo tanto, para que
el sistema empresa se optimice, ventas y producción deben
suboptimizarse.
Me gusta el ejemplo de Goldratt (1993) para explicar este principio. Hay
que imaginarse un sistema simple como el de una cadena (Fig.: 11).
45
Fig.: 11
La meta o propósito del sistema cadena es transmitir fuerza de un lado
al otro. Para que la meta se cumpla, cada uno de los eslabones que
componen la cadena deberá soportar una determinada fuerza. Si el
sistema no logra la meta será porque alguno de sus eslabones superó
su capacidad, mientras que el resto aún no llegó al límite de sus
posibilidades. Exponiendo lo enunciado en términos sistémicos, se
puede decir que el sistema no logró su meta porque uno de sus
elementos superó su límite de capacidad, mientras que el resto de los
elementos se mantenían suboptimizados. La conclusión de Goldratt es
que todo sistema tiene una, y sólo una, restricción operativa. El sistema
cadena falló sólo en un elemento, que es el que deberá aumentar su
límite de capacidad para lograr la mejora del sistema total. Aumentar los
límites del resto de los elementos no ayudaría en nada al logro de la
meta. Ningún esfuerzo aplicado a los elementos del sistema que no
constituyen una restricción operativa producirá una mejora en el sistema.
En el ejemplo, la cadena siempre se romperá en un eslabón
determinado; si este se refuerza, el más débil será luego otro de los
eslabones, al que habrá que mejorar. Y así sucesivamente en un
proceso de mejora continua. La idea de esta teoría es bastante
contraintuitiva, ya que significa que cuando un sistema logra la meta,
sólo un elemento está al borde de su límite de capacidad, mientras que
el resto permanecerá suboptimizado.
16.2. Interfaces complejas
El concepto de interfaz es un poco ambiguo. En general, se denomina
interfaz a un proceso mediante el cual intercambian datos dos
aplicaciones de software que no han sido diseñadas íntegramente y que,
46
esencialmente, no comparten los datos. Es común que cada aplicación
involucre distinta tecnología, tanto de hardware como de software. Por
ejemplo: la figura 12 muestra una interfaz entre un sistema de
liquidación de sueldos y jornales y un sistema contable. En una muy
sencilla síntesis, esta interfaz consiste en acumular los valores por
conceptos de liquidación (sueldo bruto, asignación familiar, obra social,
etc.) de cada empleado y asignar una cuenta contable al total por
concepto. Para esta tarea, la interfaz debe contar con un juego de datos
propios que le suministren la información necesaria. En el ejemplo
podría tratarse de una relación entre concepto de liquidación y cuenta
contable.
En la mejor de las situaciones para la filosofía del mejor en su clase, que
es cuando todos los sistemas se ejecutan en la misma tecnología de
hardware y de DBMS, el menor esfuerzo que deberá hacerse es:
a) Programar las interfaces, ya que muy difícilmente sean resueltas
por salidas estándar del sistema.
b) Mantener actualizada la base de datos del módulo de interfaz
atendiendo a los cambios que se puedan producir en los datos de
Fig.: 12; interfaz
47
cualquiera de los dos sistemas en cuestión (una nueva cuenta o
un nuevo concepto de liquidación, etc.).
c) Actualizar el módulo ante cualquier cambio en la versión de los
sistemas vinculados por la interfaz.
d) Administrar el proceso. Esto es: a qué día-hora se ejecuta, antes
de qué y cuál proceso, quién lo ejecuta, revisar los posibles
errores del proceso, etc.
Si no se está ante el mejor de los casos; es decir, que los sistemas a
vincular no están soportados dentro de la misma tecnología de hardware
o de software, se deberá:
a) Decidir en qué tecnología mantener la interfaz y, de acuerdo con
esto, quiénes son los especialistas que la mantendrán.
b) Mantener sistemas de comunicación para enlazar técnicamente
las dos aplicaciones, con todos los posibles inconvenientes que
puedan producirse (algunos tan patéticos como que, por ejemplo,
cuando se corra la interfaz uno de los equipos esté apagado o
fuera de servicio).
c) Personal especializado en las diferentes tecnologías.
d) Atender a los proveedores de cada Tecnología.
16.3. Se incentiva la propiedad sobre el sistema y la lucha entre
proveedores
Al incorporarse sistemas atados a las funciones, lo que ocurre es que,
generalmente, estas funciones también están atadas a un funcionario.
En muchos casos, y porque muchas veces se les descuenta el gasto de
su presupuesto, se consideran dueños y señores del sistema,
creyéndose con derechos absolutos sobre este. Cuando cosas así
ocurren, las consecuencias son terribles para la organización. Se pierde
un tiempo precioso en discusiones estériles, se acentúa la división de los
procesos, se desgasta la relación con los proveedores, y se disminuye la
calidad de la información.
48
17. Propuestas existentes para la selección de Sistemas ERP
Del relevamiento efectuado sobre gran parte de la información existente
sobre Sistemas ERP (en español y en ingles), se ha observado que casi todos
los libros y papers que tratan el tema hacen referencia a la importancia del
proceso de selección. Pero en general no se detienen en detalles de este
proceso y se dedican, con mucha intensidad, a los aspectos vinculados a la
implementación. No obstante esto, se pueden destacar algunos trabajos que
han desarrollado el tema con bastante profundidad.
17.1. Según Murrell G. Shields
Shields dice (2001, p. 67-92): ―Escoger el paquete adecuado para
permitir mejoras de procesos de negocio es una decisión importante
para un organización. Hay cientos de proveedores que le dirán que su
paquete es el mejor para su situación‖.
Shields sostiene la necesidad de realizar un rápido proceso de
selección para alcanzar velozmente los beneficios del software a ser
implementado.
Este autor considera muy importante que el paquete contenga las
siguientes características generales:
a) Sea cercano a la cultura de la organización.
b) Contenga las funcionalidades de la industria.
c) Flexibilidad para acomodarse a las necesidades del
ambiente.
d) Interoperabilidad con otros sistemas.
e) Existencia de proveedores de hospedaje (en inglés
hosting) para soportar la implementación.
f) El paquete debe ser completo, estable y tener buen
49
servicio de soporte.
g) Debe existir una versión pre-configurada.
h) El paquete debe incluir aceleradores de implementación
como ser materiales de capacitación, procedimientos de
usuarios, textos de ayuda, servicios de conversión de
datos, modelos de procesos, planes de trabajo,
presentaciones y listas de verificación.
Considera que un proyecto de selección de software implica la
selección de dos cosas: por un lado, un paquete de software que será
utilizado para permitir cambios en los procesos y mejoras en el negocio,
y por el otro, un socio de negocios (el proveedor del paquete) que
deberá apoyar y mejorar el producto en el futuro.
Con respecto al proveedor del producto considera importante
evaluar:
a) Capacidad económica-financiera
b) La estrategia de desarrollo de productos y el desempeño
del vendedor
c) ¿Cuál es su visión y estrategia para mejorar el producto en
los próximos dos o tres años?
d) ¿Qué módulos se están desarrollando nuevos?
e) ¿Qué nuevas tecnologías está el proveedor utilizando?
f) ¿Cuánta gente y cuánto dinero se gastan en investigación
y desarrollo (I + D) cada año para poner en práctica estos
cambios?
g) ¿Qué funcionalidad específica está siendo desarrollado
para satisfacer las necesidades de estas industrias?
h) ¿Con qué frecuencia el proveedor sale con nuevas
versiones del producto y cuál ha sido su historia en el
cumplimiento?
i) Evaluar la capacidad que tiene el proveedor para brindar
soporte a la instalación
50
j) Evaluar la aptitud y actitud del personal que el proveedor
ocupe en el proceso de selección
Plantea tres diferentes enfoque o formas para realizar la
selección:
a) Requisitos detallados
b) Requisitos claves
c) Prueba de conceptos
a) Requisitos detallados
En primer lugar se toma conocimiento del universo de posibles
productos a ser seleccionados (una lista de entre 10 y 20
candidatos). A esta lista se le envía una Solicitud de Información
(en ingles Request for Informatión o RFI) donde se solicita a los
posibles proveedores la información necesaria para poder
efectuar comparaciones.
Mientras los proveedores contestan el RFI el equipo de selección
analiza exhaustivamente las capacidades del actual sistema. Que
se identifiquen problemas y releven requisitos de los actuales
usuarios. Muchas organizaciones, en esta etapa, suelen realizar
un diagrama de flujo (en inglés flowcharts) de los procesos
vigentes. Se aclara que puede demorarse mucho tiempo en esta
tarea, pero que el resultado del trabajo puede ser usada para que
los proveedores comprendan mejor la empresa, para preparar la
demostración y como un medio de comunicación entre los
miembros del equipo de selección.
El siguiente paso es elaborar una detallada lista de
funcionalidades y de requisitos técnicos para el nuevo sistema.
Esta larga lista surgirá de las entrevistas con los usuarios del
51
sistema. No sería de extrañar que este trabajo alcance entre 50 y
60 páginas de extensión.
Los requisitos se envían a los proveedores en forma de Solicitud
de Propuesta (en inglés Request for Proposal o RFP. Este RFP
se envía a una lista menor de proveedores que la que recibió el
RFI (en este punto, el autor no aclara como se efectúa la
reducción). Además de enviarles el RFP se les da la oportunidad
de una reunión para aclarar duda y conocer más acabadamente
la organización.
Otras de las tareas del equipo de selección es la de desarrollar
los criterios de selección asignándole ponderaciones a los
diferentes ítems a ser relevados.
Una vez recibidas las respuestas del RFP se procederá a
confeccionar un tanteador (en inglés scorer) con la finalidad de
asignarle un peso a cada producto.
En las demostraciones de los productos, que pueden demorar
hasta tres días, se verificará si el producto cumple con las
especificaciones detalladas en el RFP.
b) Requisitos clave
Shields considera a éste un enfoque más racional. En este se
trata de no poner atención en todas aquellas funcionalidades que
se considera que todos los productos hacen igual de bien y
propone concentrarse en aquellas que no todos los paquetes
hacen igual de bien. Y en el impacto que estas diferencias
tendrán en la resolución de los problemas y el aprovechamiento
de las oportunidades. El esfuerzo del equipo de selección debe
centrarse en cuales son las funcionalidades que irán en un lugar o
en el otro.
52
Se propone que para cada requerimiento clave se desarrolle un
procedimiento con la solución requerida por el negocio, para
luego verificar si el software puede llevar adelante este
procedimiento.
Los requisitos claves deben ser trasportados al RFI para que
luego en la demostración se constate como se cumplen en la
práctica.
Por último, estos requisitos serán los utilizados para efectuar la
selección. Una vez seleccionado el paquete final, es buen
efectuar un chequeo respecto del resto de las funcionalidades a
los efectos de no encontrarse con ninguna sorpresa posterior. La
diferencia con el método anterior radica que en la selección no se
involucra el total de funcionalidades que impedirían una rápida
resolución del problema.
c) Prueba de conceptos
Este es el más rápido de los tres enfoques. Se utiliza cuando la
organización considera que ya sabe cual es el software que
necesita y simplemente requiere una confirmación antes de firmar
el contrato con el proveedor.
El equipo de selección se tomará un razonable tiempo para
verificar si las funcionalidades necesarias están contempladas por
el producto a los efectos de no encontrarse con una gran
sorpresa.
Shields considera que el enfoque a utilizar depende de múltiples
factores como pueden ser el conocimiento previo que se tenga de los
distintos productos existentes en el mercado, de la necesidad de obtener
una respuesta rápida, de la cultura organizacional, etc.
53
Señala que es importante concebir el proceso de selección de un
Sistema ERP como un proyecto con un objetivo formal y un calendario
definido. No debe ser tratado como una actividad ad-hoc.
17.1.1 El grupo de selección
Se formara con gente dedicada a tiempo completo y parcial
proveniente de toda la organización, con los conocedores de las
funciones claves, con representantes del área de sistemas y con
usuarios claves del sistema a ser implementado.
Los roles a ser cumplidos en el equipo de selección son de
sponsor, miembro del Comité de Dirección (en inglés Steering
Committe), gerente de proyecto, consultores, representantes
funcionales, usuarios claves y especialistas en sistemas.
El Comité de Dirección estará compuesto por la alta gerencia
afectada por la implementación a realizarse. Los representantes
funcionales son los miembros del Comité de Dirección y los
usuarios claves son personas que conocen profundamente las
funciones claves.
17.2 Según Stephen Harwood
Stephen Harwood (2003, p. 69-87) afirma que elegir un Sistema
ERP es fundamentalmente un elección del proveedor de software, ya
que se deberá convivir con él por toda su vida útil. Los costos que
ocasionarían una mala relación serían altísimos para la compañía.
Con respecto a realizar un análisis de costo, Harwood afirma que
es un dilema establecer una justificación económica de un proyecto de
incorporación de un Sistema ERP. Entre otras cosas escribe: ―Si bien los
beneficios tangibles de la reducción de los stock pueden ser
cuantificados sin dificultad, el incremento de ingresos resultante de la
54
mayor eficacia de las operaciones será difícil. Por otra parte, la
cuantificación de cualquier beneficio inmaterial será difícil‖.
Este autor propone elaborar una definición de requerimiento
mediante procedimientos largos y detallados de los procesos
involucrados.
El proceso de selección de un proveedor de un sistema ERP esta
compuesto por cuatro etapas:
a) Reconocer ―quiénes están ahí fuera‖ (localizar posibles
proveedores)
b) Generar una pequeña lista
c) Reducir la lista a quienes se consideran adecuados
d) Selección final
Una persona deberá programar estas cuatro tareas para un
adecuado desarrollo de las actividades.
17.2.1. Reconocer quiénes están ahí fuera
Esta etapa es relativamente sencilla ya que consiste en buscar en
el mercado, por intermedio de revistas especializadas, revistas de
negocios y la Web fundamentalmente, los actuales vendedores de
Sistemas ERP, Harwood aclara que pueden localizarse hasta
cientos de proveedores.
17.2.2. Generar una pequeña lista
Ahora se deberá reducir la primera lista a unos 10 o 15 posibles
candidatos. Para reducir la lista, se contrasta a los proveedores
con una corta lista de criterios entre los que se pueden incluir:
a) Presencia geográfica
b) Orientación a la industria
55
c) Especiales requisitos funcionales
d) Implementaciones realizadas durante los últimos tres
años
e) Tamaño de las organizaciones asistidas y del
proveedor
f) Rentabilidad del proveedor
g) Impresiones iniciales
17.2.3. Reducir la lista a quienes se consideran adecuados
En esta etapa se efectúa una nueva reducción de los proveedores
(3 o 4) en función de una lista de criterios más amplia como por
ejemplo:
a) Funcionalidades
b) Facilidades para su implementación
c) Costo
d) Credibilidad del producto y del proveedor
e) Soporte
f) Reputación
g) Formas en las respuestas
h) Futuro esperado del proveedor y el producto
17.2.4. Selección final
En este punto el autor aclara que en la elección final debe
intervenir la mayor cantidad de gente posible, para que luego
nadie diga ―yo no seleccioné este sistema‖.
Propuso tomar la lista de criterios de selección utilizada para
seleccionar los candidatos finalistas, crear un score asignándole
un peso a cada criterio utilizado. Pero nada dijo respecto a como
elaborar una decisión con múltiples decisores.
17.3. Según Jacques Verville y Alannah Halingten
56
Verville y Halingten (2003, p. 585-594) dicen que: ―la adquisición
de un Sistema ERP es compleja, enredada, exigente e intensiva‖.
Desarrollaron un modelo de seis etapas para la selección y
compra de un Sistema ERP. La propuesta fue elaborada en función de
un detenido estudio sobre como cuatro empresas realizaron esta tarea.
Las seis etapas o procesos de este modelo al que denominaron
MERPAP son (ver fig.: 13):
Planeamiento
Búsqueda de información
Selección de alternativas (elaborar una pequeña lista de
proveedores)
Evaluación
Elección
Negociación
Verville y Halingten
Fig.: 13 MERPAP: Las líneas punteadas indican el flujo de información. Las líneas continuas muestran la
secuencia de ida y vuelta de las actividades
La estructura es la siguiente: (1) Se inicia con la planificación, (2)
se finaliza con la negociación, (3) MERPAP es un modelo no lineal, (4)
varios de los procesos se ejecutan concurrentemente, (5) algunos de los
57
procesos están incrustados, (6) todos los procesos, con la excepción de
la elección, son iterativos, (7) todos los procesos, con la excepción de la
elección, son recursivos y (8) cada proceso es causal y genera un
resultado (entregable) que es utilizado por el siguiente proceso.
17.4. Según Navnnet Bhushan y Kanwal Rai
Bhushan y Rai (2004, p.51-70) afirman que las empresas deben
preocuparse por la tarea de evaluar software y a sus respectivos
vendedores debido a los siguientes motivos:
a) Existe un gran número de posibles vendedores y paquetes de
software
b) Complejas y múltiples tecnologías y arquitecturas
c) La decisión tiene un alto impacto económico
d) Las tendencias de los negocios y las tecnologías son difíciles
de predecir
e) Los equipos que intervienen en la decisión son grandes y
cruzan todas las funciones de la organización
f) La forma tradicional de evaluar, basada en unas pocas
funcionalidades y el costo, no es adecuada
Estos autores consideran que el problema fundamental de la
selección de un Sistema ERP se presenta en el proceso de Toma de
Decisión con Criterios Múltiples (en inglés Multi Criteria Decision Making
o MCDM) en el que intervienen varios decisores (en inglés Group
Decision Making o GDM). Afirman que ―cuando las reglas del juego
están bien establecidas, cuando el entorno en el que se opera es
predecible, cuando la oposición se sabe, cuando los actores se
comportan de una manera determinista, cuando los costos varían dentro
de una banda pequeña y estrecha, y cuando las relaciones lineales son
la norma, uno puede tratar de tomar decisiones mediante las técnicas de
optimización estándar. Sin embargo, cuando los beneficios de las
acciones son impredecibles, cuando las relaciones entre las variables
58
puede ser no sólo no lineales y estocásticas sino también realidad
desconocida, el principio de optimización para la toma de decisiones no
ayuda mucho‖.
Consideran que el proceso de toma de decisiones se compone de
las siguientes actividades:
a) Organizar múltiples criterios
b) Evaluación los criterios
c) Evaluar las alternativas sobre la base de los criterios
evaluados
d) Elaborar un ranking de las alternativas
e) Incorporación de las sentencias de varios expertos
Proponen evaluar el Sistema ERP y los vendedores utilizando el
modelo matemático denominado: Proceso Analítico Jerárquico (en inglés
Analytic Hierarchy Process o AHP) creado por el matemático Thomas L.
Saaty en 1980. Consideran que este modelo es simple y fácil de utilizar y
se adapta a la estructura de pensamiento humano, además de permitir
compatibilizar las opiniones de múltiples decisores.
La toma de decisión, especialmente la toma de decisión
estratégica, implica la participación de múltiples agentes. En la mayoría
de las organizaciones estas decisiones se toman colectivamente, con
independencia de si la organización es publica o privada, nacional o
internacionales, y/o pequeñas, medias o grandes. La toma de decisión
es raramente efectuada por una persona aislada. Este modelo evita el
conflicto, largas discusiones y tiende a despersonalizar y objetivar la
decisión final.
Este modelo consiste, esencialmente, en definir el problema y
descomponerlo en sub problemas más comprensibles y evaluables.
Luego, establecer un valor a cada solución posible, en función de la
respuesta que se espera que brinde al problema; para por ultimo, hacer
un ranking de las soluciones. Por lo tanto es un modelo que pertenece al
59
conjunto de los MCDM.
El proceso:
17.4.1. Organizar criterios múltiples
La punta de la pirámide de la jerarquía de criterios se plantea
como la solución del problema, los siguientes niveles se
conforman de diferentes criterios desde los cuales evaluar una
alternativa. Por ejemplo, al evaluar la compra de una podadora de
césped, el objetivo puede definirse como: cortar el césped a una
altura determinada, y en un tiempo determinado. Para lograr este
cometido pueden existir muchas cantidades de cortadoras de
césped que cumplen más o menos con el objetivo. La jerarquía de
criterios puede consistir en evaluar las posibles cortadoras de
césped desde sus características técnicas y desde su
maniobrabilidad (ver fig.: 14).
Fig.: 14 Autor: BHUSHAN y RAI
17.4.2. Evaluar las alternativas sobre la base de los criterios
considerados
Este proceso consiste en valorar cada alternativa, dentro de cada
criterio, desde una comparación de a pares. Por ejemplo, la
alternativa X1 con la Alternativa X2 en función del criterio 1, luego
compara la alternativa X1 con la Alternativa X3 y por último la
alternativa X2 con la alternativa X3. El siguiente paso es efectuar
Johnson, R., Kast, F. y Rosenzweig, J.: The Theory and Management of
Systems (McGraw-Hill, 1967).
Jones, T.: Programming Productivity (McGraw-Hill, 1986).
Kaplan, R. y Norton, D.: Cuadro de mando integral (Gestión, 1997).
Kofman, F.: Metamanagement (Gránica, 2001).
Kuhn, T., La estructura de las revoluciones científicas (Fondo de la Cultura Económica, 1971).
Lardent, A.: Sistemas de información para la gestión empresaria: planeamiento,
tecnología y calidad (Pearson Education, 2001).
Laudon, K. y Laudon, J.: Sistemas de información gerencial (Prentice Hall,
2002).
Liang, S. y Lien, C.: Selecting the Optimal ERP Software by Combining the ISO
9126 Standard and Fuzzy AHP Approach (Contemporary Management
Reserch, Vol. 3, Nro. 1, 2007).
Mabert, V.: Enterprise Resource Planning Survey of US Manufacturing Firms
(Ashok Soni, 2000).
Magariños de Morentin, J., El mensaje publicitario (Edicial, 1991). Markus, M. y Tanis, C.: The Enterprise System Experience From Adoption to
Success (Working Paper, 2000).
Mintzberg, H., Diseño de organizaciones eficientes (El Ateneo, 1989).
Muñiz, L., ERP: guía práctica para la selección e implantación: ERP: enterprise resource planning o sistema de planificación de recursos empresariales (Ediciones Gestión, 2004).
Murdick, R. y Ross, J.: Sistemas de información basados en computadoras
para la administración moderna (Ed. Diana, 1977).
O’Brien J. y Marakas G.: Sistemas de Información Gerencial (McGraw Hill,
séptima edición 2007).
O’Grady, W.: Assessing Benefits from ERP Systems Use (Paper-University of